This week, I'm leading the Mobility Metro this week in Cincinnati. During one of the labs, I had the opportunity to start looking at querying the GPS on my BlackJack II. And then this evening, I had time to dig in more. This is very cool stuff. Here's what I've done so far.
Connect my BlackJack II device to Visual Studio 2008
There's probably some cool way to do this, but to unlock my device enough for VS to connect, there are a couple of not well documented steps. Note, this is specific to Windows Standard (i.e. Smartphone). These devices usually come with a more locked down setup.
Now, we need a way to talk to the GPS.
Querying the GPS
So, (the official way that Microsoft employees start informative statements), I need a GPS API that I can access from the .NET Compact Framework. How do I get there? If you looked at .NET Compact Framework 2.0 or 3.5, you would be disappointed. One of the features touted in WM5 launch days was the new GPS Intermediate Driver. This driver has several special capabilities, including allowing multiple applications to talk to GPS simultaneously (or, I should really say listen simultaneously). The problem with this GPS setup is that there is no managed GPS classes. That's a problem, because there's a lot happening in this GPS API in Windows Mobile.
So, refer to the Day 2 module in the Mobility Metro lab, and what does it say: "MANAGED GPS". That's right. Where is this Managed GPS stuff at?
The WM6 SDK has a managed code sample, in the C:\Program Files (x86)\Windows Mobile 6 SDK\Samples\Smartphone\CS, called GPS. Originally, this showed up in the WM5 SDK. Anyway, this is a C# solution, named GPS, and comes with two projects, 1) GPS, a .NET CF application project, and 2) a child project that is the managed wrapper of the GPS Intermediate Driver interface. So, kudo's who designed the solution this way so that someone can easily re-use in other applications. The library is namespace'd as Microsoft.WindowsMobile,Samples.Location (note the namespace on the slide, which might make you believe this is in the .NET Compact Framework).
So, I open up the project, compile, deploy, and debug. Interesting stuff. I've got .NET code receiving GPS events on a device. Cooooool!!!!!
Now, there are a couple of issues to deal with. First, I get a random error out of a function - which happens to be without a Try/Catch block, so I'll have to look into that. It's sporadic so that even makes it more fun.
Second, you will need to utilize some patience waiting for the GPS chipset to find a set of satellites to start listening to. Once you get connected, you're fine as long as some app is talking to the satellites.
Third, there's a lot going on in the API. Fortunately, this sample does a good jump of showing a fairly rich implementation of working with the GPS driver. It's not for the faint of heart since there are plenty of marshaling attributes, P/Invokes to Win32 land like WaitForObject, calls to LocalAlloc and LocalFree (man, I love managed code), and working with Windows handles; however, they hide that pretty well from the UI code. It is interesting what the application does. In the wrapper, they create a background thread that receives the GPS events, basically reacting to position change events and satellite state change events. They nicely call Control.Invoke in order to do the UI updates on the main thread. Good stuff, mostly.
After looking at this application, I'm ready to start understanding what I can do with what is exposed to me in the managed wrapper. The display is a text windows showing a concatenated string of properties from a GPS_POSITION (native structure is converted to a .NET class), and only a few interesting properties are shown like Latitude and Longitude. But what are these other properties?
When I start looking at the GPS_POSITION properties exposed by the GPS Intermediate Driver (note in the slide above), I can see that I need some more understanding of GPS workings. One good source that is a sorta short read is the Wikipedia page for GPS. They have a little history, some inner-workings, some definitions that will fill in a few blanks in the GPS_POSITION structures, and resource links to bunches more. I had no idea that there were so many GPS satellites in the sky (30+, although you only need 3-4 for decent accuracy).
You can see some information about Assisted GPS (A-GPS), which is the ability to triangulate location based on cell towers, part of the E911 initiatives from the U.S. government. This capability is used in several mapping applications, like our Live Search for Mobile, which uses this to find the appropriate satellites faster.
Another interesting but useless fact: "Following the shooting down of Korean Air Lines Flight 007 in 1983, President Ronald Reagan issued a directive making the system available for free for civilian use as a common good..." I'm not a history buff, but sometimes I find some things that just grab my attention.
For me, the main thing in this reading was to get a little background understanding of the properties in the GPS structures. Example, what is a PRN, why does a satellite return "satellite time", etc.
My Additions to the GPS project
So, after looking what the sample did and noting some of the properties that would be useful to me that weren't used, I made a few changes to sample application:
Hope this helps you get started with adding location data to your applications. I'll have more posts on my potential usage of this in the future.
I'm certainly am glad to have a open platform that allows me to easily code a mobile application, easily deploy to a device, and enjoy it today.