The Power Of Location Is Changing How Business Is Done! Learn More Here!

Location Based Services

Subscribe to Location Based Services: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Location Based Services: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

LBS Authors: Liz McMillan, RealWire News Distribution, Kevin Benedict, Shelly Palmer

Related Topics: Location Based Services

LBS: Article

Location-Based Services

.NET knows where you are

If you follow the mobile space, you know that one of the hot topics right now is location-based services (LBS). LBS allows you to build applications that adapt to users' locations and situations. Without requiring your users to enter ZIP codes or addresses, you can filter data and provide the information that is most relevant to them. Location information plays a key part in applications such as asset tracking and sales or workforce automation. Being able to automatically determine location removes the burden from the end user of determining where the application is being used and allows the application to alter its behavior as the user travels.

Location-based services can derive location in many ways: time difference of arrival (TDOA), enhanced observed time difference (E-OTD), or global positioning system(GPS). TDOA requires that multiple base stations triangulate the position of the wireless device by listening to hand-over access bursts. E-OTD places the burden on the handset instead of the base stations. The handset listens to bursts from multiple base stations and measures the observed time differences between the signals. These measurements are used to triangulate the position of the device. The final technique involves the use of a global positioning system. Handsets that use these techniques include an integrated GPS receiver that can be queried by the network to determine the location of the handset. The advantage of this last technique is that, in many cases, the local GPS may also be leveraged by applications running on the device.

What Is GPS?
So the government spent the last 30 years putting nearly 30 atomic clocks into the sky. Why is this important to me? Because they are the backbone of the GPS system that nearly all location systems utilize in some fashion. Although the technology and magnitude are very impressive, GPS is based on one simple thing: triangulation. Given enough points and distance to them, users can determine their current locations. In two-dimensional space, this requires three points. In three-dimensional space, this requires four points, but you can take other known values and rule out one point of intersection, allowing for triangulation around the Earth to take place with three satellites. The distance is determined by calculating the time it takes a signal to get from the satellite to a handheld receiver (approximately 12,000 miles).

With the basic geometry under control, there are several other aspects of GPS that are of interest. One of the first problems that a GPS device has is determining what satellites are available on the horizon. Without any knowledge of its current location or previous locations and time, the device must start searching for a satellite. This is known as a cold start. The process involves searching all known satellites (on a frequency of 1575.42 MHz) and trying to acquire a lock on one. Once a receiver has locked onto one satellite, it receives the almanac and ephemeris. The almanac contains the latest information about every satellite that's in the sky. The ephemeris data contains the information specific to that satellite as well as its time and location.

A receiver then continues to acquire and download information from at least two other satellites. Once a receiver has locked on to three satellites, it can begin providing rudimentary location information. Typically, it needs four satellites to give actual location, calculation verification, altitude, and velocity.

GPS is designed with two frequencies, L1 and L2. L1 is the consumer-grade frequency that, until the year 2000, was intentionally inaccurate through a process called selective availability. This involved adding a random bias to the time aspect of the signal, creating a distance that's slightly off. With this removed, many receivers claim an accuracy of 10 meters (radius). This can be further refined through the addition of a differential signal or D-GPS.

Differential GPS information can come from many known sources. The differential signal contains update or difference data between what satellites are currently reporting and what they should be reporting. One well-known D-GPS system set up for aviation is WAAS (Wide Area Augmentation System). There are several others ranging from the Coast Guard to private services. A user can provide his/her own differential information by setting up a highly accurate receiver at a known location and then broadcasting the information deltas.

GPS data is susceptible to several errors, ranging from environmental issues to equipment. The most common or largest (in terms of time delay) is typically atmospheric. The ionosphere and troposphere can refract the GPS signal and alter its arrival time. The second largest source of error is typically ephemeris. The ephemeris error is essentially a satellite being out of orbit. The government is constantly tracking and updating accurate location information for every satellite, but based on certain Earth model calculations and real-time errors, this information may not be exact for your current location. By having a constant known fixed source providing location contextual differential information, you can diminish nearly all GPS errors.

What Is NMEA?
NMEA is the National Marine Electronics Association that created a standard for the electrical interface and data protocol for communications between marine instruments. It was originally invented to provide the maritime industry with a way to interface an autopilot with a GPS. NMEA-0183 is the standard that governs most GPS communications. It specifies that data is sent at 4800 baud as printable ASCII text in the form of "sentences." A sentence starts with a $ character, a two-letter "talker id," a three-letter "sentence id" followed by a number of comma-separated data fields, and terminates with a carriage return/line feed. Fields can be of variable length, so parsing on the commas is the recommended method for splitting up the sentences. Missing fields are left blank but retain their comma delimitation. The talker ID typically denotes the type of equipment sending the message. For a GPS, the talker ID is typically GP. The supported sentence IDs vary among device manufacturers. Most GPS manufacturers support either the GLL or GGA sentence types. GLL is a geographic location including latitude and longitude. GGA is global positioning system fix data and includes latitude, longitude, fix quality, number of satellites being tracked, horizontal dilution of position, and altitude. Because this is just an ASCII text protocol like HTTP, it is relatively simple to write a control that interfaces with the GPS. The main difference is that this protocol must communicate over a serial connection instead of TCP/IP.

If you look at the source code, you will realize that we used OpenNETCF as the framework for the samples. The main reason for this is that we needed a managed implementation for communicating with the serial interface on our device. .NET Compact Framework 1.1 does not provide such an implementation, but OpenNETCF available from provides an excellent serial implementation along with implementations of many other features missing from the .NET Compact Framework. You may be wondering if OpenNETCF also provides a Bluetooth implementation for those of you out there with Bluetooth GPS devices. It turns out this isn't necessary. Most Bluetooth GPS devices use a Bluetooth serial profile that surfaces the device as though it was just another serial port.

How Do I Communicate with the GPS?
The first step is opening the serial port you are going to use to communicate with the GPS. Listing 1 shows the code required to initialize the port.

This sets up the serial implementation to raise the serialPort_ DataReceived event handler as each character comes in. This will allow you to gather up the characters waiting for a carriage return/line feed termination. At this point, you will parse the sentence and determine if you can do anything with it. The code in Listing 2 shows how to handle the incoming data. You first grab the data from the serial port. This gives you a single byte to examine. If the byte is 13 (a carriage return), you will then grab what is in your buffer and parse it as a sentence. If the byte is anything other than 10 (a line feed), you append it to your buffer. Finally, you'll note that you bracket all of this code with a conditional called bIgnoreStartup. This is done because the GPS device is always sending data. It is very possible for you to open the serial port and start receiving data mid-sentence. This flag allows you to ignore any data until the first sentence occurs. This is the check in the else clause for a byte containing 36 (a $ character), which signifies the start of a new sentence.

Once you have a complete sentence, you need to parse it and then raise an event to indicate you received positioning data. To parse, you first figure out what the sentence ID is and then do parsing using specialized parsers for each sentence type. Listing 3 shows how to break up the initial sentence and then use a switch to fire the sentence off to the specialized parsers.

The sentence parsers are implemented as the constructors of your EventArg structures in the samples. You pass the sentence into the constructor and it is parsed into the event args structure. Listing 4 shows how this is done for the GLL fix type.

This is then used as the event args for the event that is raised out of your component to indicate a new fix. Check out the sample for a fully functional application that should talk to most GPS devices that support the GLL and GGA sentence IDs.

The Future
With a $100 investment, you can now very accurately determine a location anywhere on the planet. By bringing this information into traditional applications, users can receive powerful contextual information. It's only a matter of time before location information is expected in all forms of communication and daily life.

More Stories By Paul Harris

Paul Harris is Senior Business Intelligence consultant at Saphere Limited ( Saphere offers business intelligence, corporate performance management, data integration, OLAP reporting and balanced score carding for the enterprise.

More Stories By Chris Kinsman

Chris Kinsman is the founder of Vergent Software and formerly the VP of technology for, a Web site that provides information for developers. He has extensive experience with .NET, Web farms, clustering, data access, and scalability. Chris just finished writing Visual Basic.NET Developer's Guide to ASP.NET, ADO.NET and XML and C# Developer's Guide to ASP.NET, ADO.NET and XML. He has spoken at a variety of conferences including VSLive and Microsoft TechEd, and is the track chair for ASPLive.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.