"Enough is enough, I’m sick of these dodgy Pocket PC GPS tools, time to write my own". Hmm, I did wonder why there seemed to be so many dodgy GPS tools out there and now I know why. First, a bit of history…
When GPS first hit the Pocket PC it was a "simple" matter of attaching a GPS device to the COMM port and off you went. The trouble is that COMM ports are tricky little things and it’s very easy to get things wrong. One of the classic problems is that opening a port means no one else can access it. Worse still, if you crash big time and don’t release that resource, well I think everyone with a Pocket PC is all to familiar with the reset button.
So along came Window Mobile 5 which introduced a nice GPS abstraction. Basically a a bit of software that grabs the GPS port and then becomes a proxy to all the other applications wanting GPS data. That way any number of applications can receive GPS data, great.
Ok, so how do I use this? Armed with my .Net Compact Framework, Visual Studio 2005 and my trusty (?) N560 I went to work…except I didn’t, I couldn’t find the library for the GPS API. Ah, it’s not .net, oh great, time to get PInvoke out then. Luckly just as I was dusting off my interop gloves I discovered a sample in the Compact SDK written in C# and nicely encapsulating calls such as GPSOpenDevice and GPSGetPosition into a nice GPS class. It also converts all that odd GPS text into nice Position, Satellite, etc classes. I built it and deployed it to the PDA (that was very easy in VS2005) and…not a lot. It all seemed to say the right things, "Device ON" but I noticed that the GPS was not on. So the software was sitting there waiting for data but the GPS devices was most certainly off. So it seems that the software is talking to the abstract layer ok, but the device layer is not talking to the device. I wrote a quick COMM test using the SerialDevice classes (found in .net 2.0) and opened COM8. This started the GPS device and a few event handlers later I was getting GPS text stuff. So all that lovely abstraction layer just doesn’t seem to work and I’m going to have go back to parsing the GPS text just like all the other poor developers before me.
"Only now at the end do I understand".
[Edit] or so I thought…
Asking around someone pointed me to an MSDN page about registry entries and the GPS Driver layer. This page comes up a lot on Pocket PC forums because some devices have chosen to hide the GPS Control Panel and you can unhide(?) it by a quick change of the registry. However, I decided to have a look around the registry and see if there was anything useful. Once in there I realised that the driver doesn’t actually enumerate the device looking for a GPS it simply has the port saved in the registry. Then I realised that on the GPS Control there was this strange drop down that said GPS Device Port. I thought that was telling me the port it exposed but actually it is asking me to tell it the port it should be reading from. Once I changed that to COM8 my software leapt into life, hurray! Interestingly all the software that comes with the PDA all use the port method to access the GPS and are blocked when my, now well behaved, software runs. I wonder if this is why so many people have trouble with N560, GPS and Navigation software?
IT Bytes 