Get Creative with GPS and Intel's Ultra Mobile PC

by Rich Winterton


Introduction

What if you were able to keep track of where you have been, let people know where you are, and figure out the best way to get where you are going? Being aware of your position and location as well as letting other know where you are may make a big difference in a variety of situations. It may make the difference between meeting up with friends or just missing them, finding a nearby business or traveling twice as far as you needed to, or in many cases just making your days more efficient. Ultra Mobile PCs (UMPCs) soon will provide building blocks such as Global Positioning System (GPS) capability. This paper explains how UMPCs with a little creativity may help redefine position, location and context awareness for many applications and also describes a few examples how applications can be creative and provide users with a unique and personalized experience. First let’s define a few terms: In this paper position awareness is defined as latitude and longitude coordinates. Location and context awareness is defined as something specific software applications do with the positional information to make it meaningful in terms of features visible to the user or that add functionality. This paper describes a few examples how applications can be creative and provide users with a really unique and personalized experience


Ultra Mobile PCs with Intel® Processors

In order to provide a good user experience with context and location awareness, a sound understanding of the hardware and its operating environment is essential. The intent of this paper is to make application developers aware of UMPC capabilities and provide a basic understanding of position, location and context awareness, and not go into great detail on how to get information from the UMPC. UMPCs will be introduced with GPS capability in the first half of 2007. These UMPCs will also include Wireless Local Area Network (WLAN) and Wireless Wide Area Network (WWAN) capabilities. All of these capabilities will be running on a familiar platform environment, Intel ISA, with a familiar OS (Microsoft Windows* or Linux*) that developers and users are very familiar and comfortable with. Understanding the UMPC platform and building blocks is important to provide a better user experience, but before we go into describing some examples of context location aware features, first we will explain how to determine your "position" and "environment". How does and application get GPS information from the hardware? When are GPS signals available? When is network connectivity available? Can we get to an internet site to help the application translate a position to a specific location? These questions are very critical in providing dynamic and useful information to the user. More importantly how can we use all of this information to our advantage?


Position Information

Receiving GPS information directly from a GPS device is currently the only way to get a position. Getting a latitude and longitude (position) is easy if you are in a place that a GPS signal may be received. However, in my experience it is the rare exception that a GPS satellite signal is available inside a building. That being said applications need to have the capability to get access to the positional information from a variety of sources. Assuming a GPS coordinates are available, manually entered or stored in a database, these coordinates can be used to provide context aware and location based decisions. The decision process of where to get the positional information may be as simple as described and shown.

When a GPS signal is available a latitude and longitude may be determined directly from a GPS device. If a signal isn't present latitude and longitude may be obtained by several other methods. An application can use both the internet and pre-installed information to get positional information. If the device has access to the internet, internet data is available to associate information such as a specific IP address to a specific latitude and longitude. Or, a manual method of determining a longitude or latitude could be entered by associating postal address to a latitude and longitude and storing the information locally on the system. Other offline capabilities exist in preinstalled software. For example, Microsoft provides a Common Object Model (COM) interface for MapPoint* to get latitude and longitude from locations on a map. Position information may not always come from the same place given the location and context the device is located. This is why it is so important to know the context in which the device is operating in. The application needs to be aware of its environment. For example, does it have a GPS signal available? Is there a network connection available? Is there other software installed that can help when "live" position information is not available?

How to determine an operating environment can be a whole topic in itself, so we will concentrate on live data streaming from a GPS device. Live GPS services provide information in several formats. These formats are all fairly similar and are usually defined either by the manufacturer or by the National Marine Electronics Association (NMEA). The standard format, defined by NMEA GPS devices, is supported by most all of the GPS hardware vendors. The NMEA standard is fairly simple, which is great for hardware and software vendors. It makes it easier to implement and easier to be cross hardware and software compatible. For example, a NMEA GPS position stream is shown and described below:

As you can see, GPS strings are fairly easy to parse since they are represented in a comma separated variable (CSV) format. The first variable defines the device format description, in this case Global Positioning System Fix Data, $GPGGA. The second variable is the UTC time. The next variables are the latitude and longitude readings from the device itself. So how do you know the readings are accurate or valid, a non 0 in the next field will identify if the information is valid. This is just an example of the possible information available and it is fairly simple to parse given the fix format information. Now we will briefly describe how to get latitude and longitude information from a GPS device.

We have seen examples of what a GPS stream may look like and how to parse strings, how do you actually read the GPS de vice to get the position strings? Unfortunately there isn't a guaranteed way to read all GPS devices, but most devices support the NMEA's defined standard to use RS-232 communications as the standard communications protocol for devices and receivers. On PCs and some other devices, RS-232 devices are represented as a "serial port or COM ports" that you can read by opening up a file and the device name being the COM string COM1 or COM2 (or others).

HANDLE
hFile = ::CreateFile(lpszDevice, GENERIC_READ | GENERIC_WRITE, 0, 0,
OPEN_EXISTING, 0, 0);

 

After you have opened up the file you need to define the protocol and set up the COM device.

BOOL SetupComm(HANDLE hFile, DWORD dwInQueue, DWORD dwOutQueue);

 

After setting up the COM port the next step is to set up the timeout values. This is important to make sure that if the GPS device stops sending information or disconnects the application does not hang waiting for information on the COM port.

BOOL SetCommTimeouts(HANDLE hFile, LPCOMMTIMEOUTS lpCommTimeouts);

 

The next step is actually reading the data. This is pretty straight forward since it is mapped into a file IO API.

BOOL ReadFile(HANDLE
hFile, LPVOID lpBuffer, 
DWORD nNumberOfBytesToRead, 
LPDWORD
lpNumberOfBytesRead, 
LPOVERLAPPED lpOverlapped);

 

So, we are now at the point we can really do something fun. Now that the application can read the GPS devices via the serial communications protocol and the application has parsed the CSV strings, let’s look at some interesting ways to use this information to make a difference for the end user.


Location Awareness

What is location awareness? For this paper, the definition is the ability to determine a position (whether in the past, present or future), and associate the position and tailor it to meaningful and useful information; whether it be a street map, satellite image or even a personal photo or song as we will later explain.


Places of Interest

Let’s go over some concrete examples. The first obvious example is a mashup. Mashups are combine data from different sources. There are many examples on the internet that use such sources as Google, Yahoo! and Windows Live* with other applications or internet services. Many of the mashup services and applications provide a simple and lightweight API that makes it relatively easy to design to. Their intent is to have other applications use their APIs making them available to the public with the hope that it will proliferate new and creative ways to use their data and services. Let's ask the question, "What would I like to do with a UMPC"

Here is an application the author decided to write to test out some ideas. This application has three property sheets in a simple dialog window. The first property sheet allows the user to configure the application options and displays the current position. This allows the user to give a position a “User Friendly Name”. If a GPS signal is available, the latitude and longitude will show up in the GPS Device Group as well. The user can decide to manually add the location with a friendly name by clicking on the ‘Add’ button. The ‘Add’ button would bring up another dialog box similar to the one shown. The User Friendly Name can be filled in and the latitude and longitude is automatically populated if the GPS signal if it is available. The current time is also automatically populated.

 

 

 

 

 

When the user clicks on the 'Add' button in the Position dialog box an entry in the "Location File" is created. The location file is a simple XML file that is used to identify a specific position to a location. In this case the Location File is named iLocations.xml and is shown in the figure. This XML file has four tag types right now and is still under design. The first tag is the <name> tag. This is the "User Friendly Name" provided in the Position dialog box. Next is a <latlng> tag. This tag has the lat (latitude) and lng (longitude) of the position. The next tag is the <time> tag that contains a string from the utc time. Also is an optional <image> tag. We will explain the use of this tag later. Now back to the Position Location Context Information property sheet. The Options group allows the user to change the location xml file. This file can be used to record position to location information in any granularity the user would like since the implementation is a simple XML file. Since this file created and modified by the Options group and Position dialog box it may contain curren t or future place a person may be at. The XML file will be updated at a rate specified by the update rate in the Options group if a GPS signal is available. The use of the email account field will be described later. Now that we have discussed the configuration of the application and what the location file is, let's see how we can use it.

As discussed earlier, mashups have become a very interesting and useful technique on the internet for sharing and using information from different providers and different services. This paper will show how to use the information in this application and use Google Maps* APIs to present meaningful information to the user. Although Google Map APIs are used in this example there are several other mapping APIs available.

Let’s look at the second property sheet in this sample application, the "Where am I?" tab. This tab shows the user the current XML, location file that may be used by the Google Map APIs. This property page has three buttons providing the user three different features. The first button is "Map it!" This button calls "WinExec" as shown here.

 

 

 

 

 

 

 

 

iRet = WinExec(CmdLine.c_str(), SW_SHOW);

 

The key is the CmdLine parameters. In the Map It example the parameter contains, "iexplore.exe http://127.0.0.1/gmaploc.html". This will launch Microsoft's browser to display a local HTML file served by the local web server as designated by the loopback address of 127.0.0.1. The gmaploc.html uses Google Map APIs and javascripts to parse the XML and render the HTML page. The portion of the java script that parses the XML location file is shown below:

GDownloadUrl("http://127.0.0.1/ilocations.xml", function(data, responseCode){
var xml = GXml.parse(data);
	var markers = 
xml.documentElement.getElementsByTagName("latlng");
	var names = xml.documentElement.getElementsByTagName("name");
	var times = xml.documentElement.getElementsByTagName("time");
	for (var i = 0; i < markers.length; i++){
		var point = new
		GLatLng(parseFloat(markers[i].getAttribute("lat")),
		parseFloat(markers[i].getAttribute("lng")));
		var info = names[i].getAttribute("id") + ", " +
		times[i].getAttribute("utc");
		map.addOverlay(createMarker(point, i, info));
		}}
);

 

The end result is a map with tags at the locations specified in the XML locations file similar to the one shown. The pins on the map show the places the user was at or will be at depending on what the map is to represent. The nice thing about this is that the data is coming dynamically from the GPS device on a mobile platform.

The "Find It" button may be used as well to determine information about a specific location. When the location of interest is highlighted in the "Where am I?" property sheet in this case "Cougar Stadium" is highlighted. The Find It button when clicked will render a new HTML page with the center of the map being Cougar Stadium and information associated with the search string tagged. In this example the search string was "pizza" resulting in pizza places near the stadium.

 

 

 

 

 

 

The information about where the user has been is kept on your local machine, which is nice for future reference. What if you decided you wanted to let someone know where you were going to be on a specific day. All you would have to do is create a location file with the tags and the times you were going to be at specific places. You could then type in the email addresses into the E-Mail Address box and click the Send It button, sending the location XML file to who ever you wanted to let know. This is a simple way of notifying people where you will be. There are several cellular carries that provide a service that will beep a cell phone when it detects if a friend is nearby. By updating the location XML file and sending to friends this information is even more flexible since it can show a friend where you are going to be.


Adding Value

This paper has discussed the UMPC GPS capabilities, and shown some interesting features such as a search/locate mashups and a current/future find me capability, but nothing that is really unique. One of the major goals of this paper is to get you to think about something that would make people say, "Now that is really cool". With that in mind here is one more idea. The property sheet that we haven’t discussed in our sample application yet is the "Really Find My Photo’s" tab. Many people own digital cameras now days. When using cameras that require film people would be more conservative in the number of pictures they take. But with digital cameras the number of pictures people take is only limited to the storage space. As a result people are taking a lot more pictures. As a result people often wonder, "Now where was that picture taken?" There are some cameras that have GPS capabilities to "tag" the photo with latitude and longitude information but they are very high-end cameras. Even the low-end and mainstream digital cameras tag the photo with a time stamp. If you have an Ultra Mobile PC, you can download the photos to it after the photos are taken. The sample application will parse the jpg files which store the .jpg information in the EXIF (exchangeable image file format) and associate the timestamp with the time the UMPC’s GPS latitude and longitude information for the specific location in the XML location file. The application can then enter the "User Friendly Name" in the EXIF location field to be referenced by other devices as well. This give the user a simple yet very powerful way to organize and manage their photos not only on a UMPC, but since the UMPC tags the information with the location information it can then go to other computers. This is all part of helping people manage their digital content in a better, unique way.


Other Information

*The Intel® Mobile Platform SDK is a building block for software developers writing mobile applications. It enables applications to easily get information about system components such as power levels, network connectivity, bandwidth consumption, processor features and activity, display resolution, physical and logical disk usage and display settings to give a few examples. Once the application is aware of the state of these system components, it can adjust to give the user the best experience possible. For example, when running on battery, move into a power saving mode by scaling back features. When on AC power, move into a performance mode. The API provided by the SDK goes above the capabilities of the operating system by providing not only a functional API but an event-based API avoiding the need for applications to needlessly poll for system information. For example, when a system is reconnected to a network, wired or wireless, the application receives an event indicating that it has been reconnected and it is time to sync data with the back-end server. The v1.2 release of the SDK will provide applications with location information through GPS devices, network information or proximity information such as WiFi networks.

 


Para obter informações mais completas sobre otimizações do compilador, consulte nosso aviso de otimização.
Categorias: