Windows CE GPSID, its C# wrapper, and device emulator interaction issues
GPSID (the GPS abstraction APIs introduced in Windows Mobile 5) has a few known issues (aka bugs). This is rather complicated due to versioning issues and also because of a C# wrapper library for the API's that work around the bug, which may or may not exist on certain platforms.
The base issue is that when GPSID shipped to our OEMs in Windows Mobile 5, it returned longitude and latitude in a very bad format. (Raw from the NMEA stream and not in reasonable degrees). It was possible to compute a reasonable representation of lat/long from what GPSID returned, but it was not reasonable to have every ISV in the world do this. So before our OEMs shipped any devices (it takes a few months for them to get ready) we released a fix to GPSID so it returned reasonable values and it was put on all actual PocketPC + SmartPhone devices. This should have been the end of the story. Unfortunately there are other factors here.
Another MS developer created a C# wrapper library for GPSID that just P/Invoked the GPSID API's. He dealt with the bad values that GPSID was returning pre-fix and converted them to be reasonable for the app. Unfortunately, the C# APIs were not fixed to remove this workaround when GPSID was fixed. So currently they are doing a conversion of the correct lat/long values, which means they're returning bogus data now.
Further complicating this is that while the GPSID fix made it to PocketPC + SmartPhone ROMs, it did not make it to the device emulator. So that means on the emulator the C# piece actually does work correctly because it's still fixing valid data, but using the C APIs will give invalid results.
Summary:
GPSID with C APIs:
Emulator
STATUS: Will not work (GPSID bug not fixed)
WORKAROUND: Call GetDegreesFromAngular() (see below) on lat + long values.
PocketPC/SmartPhone (real device)
STATUS: Will work (GPSID bug was fixed)
WORKAROUND: Not needed
GPSID with C# APIs:
Emulator
STATUS: Will work (GPSID bug not fixed, C# work around for issue in place)
WORKAROUND: Not needed
PocketPC/SmartPhone (real device)
STATUS: Will not work (C# API working around a bug that no longer exists)
WORKAROUND: Remove the C# code (it was shipped as source) that does the unneeded conversion.
We're very likely to get the C# wrapper fixed in a future release. Fixing GPSID on the emulator is under investigation. You can tell if underlying GPSID is fixed simply by making sure that the lat/long values it returns are what they're supposed to be for whatever the GPS driver is telling it.
As promised above, the conversion function you need ONLY on emulator and using C API lat/long (note I haven't tested this as I'm describing below but it should work)
DOUBLE GetDegreesFromAngular(DOUBLE dbl) {
dbl /= 100;
int i = (int) dbl;
DOUBLE frac = (dbl - (double)i) * (100.0 / 60.0);
return ((double)i + frac);
}
I apologize for all the problems this caused. The fault here is totally mine, and not the C# developer. Thanks to Christopher E Piggott of Rochester Institute of Technology and Trapulo "of Italy" (sorry I don't know your real name) for bringing all the C# + emulator issues to my attention and testing out some theories I had.
[Author: John Spaith]
Comments
- Anonymous
February 12, 2006
Good post.
What would happen if I went to my Axim, grabbed GPSID.dll, and copied it to the device emulator? - Anonymous
February 13, 2006
For copying GPSID.dll to device emulator, I believe that would work. There's one way to find out :). You'll need to get the original GPSID out of the device emulator "ROM" for your new one. I've never used device emulator so I'm not sure how you'd go about doing that; in the worst case you'd just need to find any gpsid.dll instance in the device registry and replace with say "mygpsid.dll" and reboot (make sure your device emulator flushes registry between reboots, don't know if it would or no).
John - Anonymous
April 14, 2006
Hi John,
Great job on the intermediate driver! Being able to share the GPS device is a common request from my customers and I'm glad to be able to help them thanks to you. I have some C# code for configuring the Intermediate Driver from managed code, which I'd be happy to pass along for anyone interested.
I'm also interested in trying to hook the intermediate driver up to our "GPS.NET" product's GPS device emulator namespace. The idea is to have our virtual GPS device classes feed raw NMEA-0183 data into the Intermediate Driver as a way to use the PDA when no GPS signal is present, or for developers who wish to write test cases against varying models of virtual GPS devices. Is it possible to control the feed of raw NMEA data into the driver?
Thanks very much,
Jon Person - Anonymous
May 10, 2006
Jon -- sorry for the delay in responding, our blog software doesn't notify us of new posts.
For your question, there are a few ways you can solve this. One is to create the NMEA file itself and have GPSID itself read from the file directly (rather than a COM port). This is doc'd in MSDN and I believe has been good enough for most folks, it's called the "file driver" or something along those lines in main GPSID documentation.
It's also possible to hook into another driver to get absolute control over what GPSID gets (the file driver reads like 80 bytes at a time always and you can't change the data file without stopping + starting GPSID by comparison). This is harder though. What you'd need to do is to create a device driver that is a virtual serial driver, then have GPSID consume the data from "COM4:" or whatever. I have a services.exe white paper on MSDN that explains how to write a network service, this is kind of similiar even though you'd need to be in device.exe instead. The "GPS.Net" makes me think though that this is a C# app you have today, which isn't something device.exe can run, so you'd need the device driver from scratch (based on my naive reading).
John Spaith - Anonymous
May 15, 2006
Hi John,
I cannot find the gpsid.dll in the WIndows directory on my device, an Orange M600. Do you know what needs to be done to get this dll working on my device? I guess Orange have removed it from the ROM, but is it possible to install again?
Thanks. - Anonymous
May 18, 2006
The comment has been removed - Anonymous
May 29, 2006
John,
1) Yes this is a WM5 device with AKU 2 (Build 14847.2.0.0)
2) I have selected the Show All Files option in File Explorer and can see coredll.dll
3) Could you point me in the right direction to put the driver back? This is for my personal use so I'm not interested in distributing to other users.
Thanks in advance.
Chris - Anonymous
June 04, 2006
I have been developing for the MIO A201 (GPS/PDA) and for the MIO A701 (GPS/PDA/Phone), using C.
Curiously, the GPS ID on the A701 (later model) returns the Lat/Long in the raw format, whereas the 201 provides the expected values.
This seems inconsistent with what you reported - could it be that the 701 has an older GPSAPI loaded?
Would I be able to replace it with the one from the 201?
Ken - Anonymous
June 13, 2006
To answer Chris's question about getting the GPSID driver back on -- wow, I really don't know if it's possible to do (cleanly). You'd also need GPS registry settings. I would recommend going to the newsgroups on this one. The way that OEMs actually decide which binaries to put onto images isn't something I'm all that familiar with. - Anonymous
June 14, 2006
I think you should try to just plunk the .DLL on and see what happens, then tell us :-) - Anonymous
June 18, 2006
Answering Ken Adam. I have the same problem with Mio A701, I have open a incident with MIO, but still no answer. I think might be a problem with Ephemeris tool they install on the device... John is aware of this problem to. Does anybody knows if the problem also happens with Eten G500? - Anonymous
August 03, 2006
Hi John,
could you be a bit more specific on the "bogus values"? What do you mean with "You can tell if underlying GPSID is fixed simply by making sure that the lat/long values it returns are what they're supposed to be for whatever the GPS driver is telling it."?
Could you give some margin of error? How muchg do the bogus values differ from the error-free values? Degrees? minutes? seconds? Could you give an example?
Thanks, Mike - Anonymous
August 14, 2006
Mike - please see documentation about the exact format returned. The legit values (fixed GPSID) for say Redmond WA, USA will be like 47.44, -122... whereas the bogus values (broken) I think was like 4700..., -12700.
[John] - Anonymous
August 23, 2006
I would like to write some data to my GPS device via the GPSID and also watch for some specific NMEA commands that are not normal GPS related data.
Can anyone point me to some examples of using the ReadFile and WriteFile in a C# application so I can read raw NMEA and also write commands to the hardware?
Thanks - Anonymous
August 23, 2006
GPSGuru - first I should warn you that if you want to Write to a GPS device, your application needs to be trusted (at least on smart-phone, this isn't the case on PocketPC SKU's). GPSID sits on top of the GPS driver and because I can have multiple applications running at the same time I'm afraid that one of them may send some funky NMEA command that will mess up the state for the other apps on the device.
As far as the sample code, I would probably point you to a CE Newsgroup (http://blogs.msdn.com/cenet/archive/2005/12/05/500181.aspx, but the dot-net compact framework group is probably better). Because we have to moderate the comments on this blog (%90 would be really gross spam otherwise), that introduces a turnaround delay that makes having good conversations in the blog comments very difficult.
John Spaith - Anonymous
August 30, 2006
Regarding your cowboy decision to deliver altered data, to suite your own personal preferences...
Do you not understand Standards?
Do you not understand Boundaries? - Anonymous
August 31, 2006
There's a very big difference between altering data and changing its format. The data as returned from NMEA streams directly is not in a format that any application developer wants to use. Rather than make everyone of them do this math formula themselves, I perform do this re-formatting at my layer. You can deterministically get back to the raw NMEA stream data from my lat/long data if you wanted to. Though this bug has not won me any friends, everyone else who has given me feedback has indicated they wanted the data in the format I'm currently returning it in.
The point of this post and descriptions of problems folks were seeing was not because of the reformat, but because of miscommunication on my part with some of the internal MS teams doing very early development work on GPSID where I wasn't doing the reformatting.
John - Anonymous
December 06, 2006
The comment has been removed - Anonymous
December 07, 2006
The comment has been removed - Anonymous
August 31, 2007
The comment has been removed - Anonymous
September 20, 2007
The comment has been removed - Anonymous
September 28, 2007
I have a problem with GPSID and COM4 on WM5 phone with built in GPS.I have been using the C# example to receive data from the GPSID for a year or so now.When my progam is running, all is fine. Then a user starts up TomTom (or another variant) which accesses Com4 (the virtual port). All is fine.However - when a user then stops TomTom, my C# program using the GPSID stops receiving data from the GPS. The GPS is built into the phone hardware (HTC3300 and Mio A701 exibit this behaviour).Starting TomTom again makes the GPS feed to my C# program from the GPSID driver resume.Why does COM4 operations seem to make the GPSID feed to a C# routine falter? - Anonymous
October 01, 2007
Hi - I have been using the WM5 sample kit with C# for a year or so now.The GPSID works fine for me on a HTC p3300 and Mio A701 via the GPSID driver (with a fix to sort out the Degrees thing).If I start my app, then start tomtom, tomtom works fine on com4: and my GPSID c# program continues to work.However, if I then stop tomtom on com4: (the virtual port), my C# program stops receiving GPS data. Closing the virtual port seems to halt the GPSID driver on "proper" GPSID C# programs.If I start tomtom again, my C# program also starts receiving data.Is this a "feature" of the virtual port - the GPSID seems to think that even though the C# GPSID program started first and is still running, when the last user of the virtual port closes, the GPSID driver shutsdown.I now have some bemused users on my tail. Can anyone shed some light on this behaviour?Thanks - Anonymous
October 16, 2007
First my apologies for long delay here. For followups, one of newsgroups on http://blogs.msdn.com/cenet/archive/2005/12/05/500181.aspx is probably best way to go.For this issue, I'm wondering is it just the TomTom GPS device or if it's the ohers as well you see this? It's definitely not a design feature of GPSID to close up the underlying driver in this case -- we keep a global GPSApplication ref count and virtual port and the GPSAPI both add that, and add/deref independantly of each other. So... I'm wondering maybe if the app is sending some sort of weird string to the underlying GPS driver that it's not liking? When an app using virtual comm port closes & there's another app using API, we don't even signal to underlying GPS driver anything (the ref count is purely internal) so I'm really not clear what could be up here.John - Anonymous
October 26, 2007
The comment has been removed - Anonymous
October 29, 2007
The comment has been removed - Anonymous
November 13, 2007
The error 87 thing is something we're investigating, as discussed in newsgroup microsoft.public.pocketpc.developer, "WM5 to WM6 GPSID Problem on HTC P3300". We're in the process now of getting hardware. (As a heads up I'm on vacation starting tomorrow so you may not hear from me personally, but there's a new engineer coming on GPSID anyway.)