Why you can’t send IOCTLs, COMM settings, or WriteData() to GPSID multiplexer?


When I implemented GPSID to abstract out GPS hardware via a nice set of API's, I thought when people heard about it they would all say how smart I was.  Unfortunately I didn't get that.  Instead it was "You're a bonehead, you're going to break back-compat.  You didn't break back-compat did you, you bonehead?"  Even the marketing guys got on me.


The concern was that GPS is almost always exposed over serial or virtual serial ports (it's changing a bit with A-GPS, but that's another story).  Serial ports usually don't do multiplexing, so if GPSID grabbed the real GPS hardware driver then it would block other legacy apps from getting at it.


Ignoring the blow to my self-esteem to have even a marketing guy think I was a bonehead, the answer is no -- I didn't break backward compat with old applications to my knowledge and for the most part.  I avoided breaking back-compat by having GPSID act as a multiplexer and be the virtual serial driver legacy apps could talk to.  This makes UI tricky but long term it'll be much better.


Still, my statement above about no BC breaks is pretty qualified so I should expand:


"To my knowledge" -- There was a newsgroup thread with some folks complaining about setting up GPSID to talk to their GPS device, but they were having problems accessing GPS in the first place and I never heard back from the regarding some questions I asked.  Beyond that I've heard no complaints, which means of course no one is using it or people are using it and it's working.  I hope the latter.  If you have problems, please let me know via a newsgroup (for various reasons I hate having conversations on the blog forum).


The "for the most part" is the more interesting part of this, as I know there are a few areas where I favored stability over back-compat.  Let's say that you have a GPS chip that's happily generating a NMEA stream, which is the standard and is the only thing GPSID knows how to parse.  Let's say now that some random app sends some random, proprietary data via WriteFile() (using GPSID multiplexer) and asks the chip to go into some weird format that only the app and the GPS chip have ever heard of.  In the past that app didn't affect anything else since it owned the GPS serial port, but now it would break all other apps on the system relying on GPSID. 


Similarly, imagine that the app could send some weird DeviceIOControl() to the chip to cause similar weirdness.  Or suppose that the app called SetupComm(), SetCommTimeouts(), or SetCommState() to mess with the baud-rate or such.  GPSID itself maintains these for the GPS device and GPSID's settings are registry configurable, so having the app mess with it through one of these API's just invites problems.


So for that reason, if you do DeviceIoControl() or WriteFile() with the handle being the GPSID multiplexer, GPSID will reject it unless you are a trusted application (in which case I'll defer to letting trusted apps be gods).  I will always block the SetupComm/SetCommTimeouts/SetCommState API calls from going through to the underlying driver.  This is just one of those hard calls between backcompat and doing the right thing for the rest of the system.


Of course if you're writing new applications targeting Windows Mobile 5 or above, please please please use GPSOpenDevice and friends!  Not only will you not have to deal with these multiplexer limitations, you'll be the beneficiary of me enforcing them -- it could be your application's access to GPS that I'm stopping from getting screwed up by somebody else!


[Author: John Spaith]

Comments (8)

  1. For what it’s worth, I don’t think you’re a bonehead. I’ve been bugging people at Microsoft to implement this for years. Sorta. I wanted to see GPS API’s in Windows (or CE, whatever) rather than a virtual serial port and basically be to GPS what TAPI is to phones and modems. Get people OUT of the habit of reading NMEA directly and start using abstraction layers like GPS.NET.

    People hate change, but change is necessary.

  2. cenet says:

    Thanks Josh – usually we get feedback of the different variety (e.g. defending ourselves from being boneheads) so nice to hear this.

    John

  3. Geraint says:

    Hi John,

    This is a positive move in the right direction.

    I am commenting from the point of view of a GPS chip manufacturer. The big problem with the NMEA interface for GPS is that it does not contain any sensible GPS position fix quality information. All it has is either “Valid / InValid” or “No Fix / 2D Fix / 3D Fix”.

    What’s the definition of Valid ?? For some applications, a position within a few hundred metres is great and would be considered “Valid”. Whereas, for an automotive navigation system with real-time guidance instructions, anything worse than say 30-50m is too in-accurate and should be considered as “InValid”.

    Whenever, we provide a proprietary API interface to customers (ie not via NMEA) we always provide Estimated Accuracy information in terms of an RMS value in metres. We then leave it up to the end user application to look at these estimated accuracy figures and decide if the position data is good enough for what they are trying to do.

    There is a NMEA sentence that provides Estimated accuracies, but for some reason most manufacturers do not output it.

    $GPGST – GPS Pseudorange Error Statistics
    $GPGST,
    UTC Time (HHMMSS.sss format),
    Pseudorange Measurement RMS fit (metres),
    Estimated Horizontal RMS Accuracy Semi-Major Axis (metres),
    Estimated Horizontal RMS Accuracy Semi-Minor Axis (metres),
    Bearing of the Semi-Major axis (degrees),
    Estimated Northing RMS Accuracy (metres),
    Estimated Easting RMS Accuracy (metres),
    Estimated Vertical RMS Accuracy (metres),
    *checksum

    PLEASE add these $GPGST estimated accuracy figures to your GPS Intermediate Driver interface in the GPS_POSITION and IOCTL_GPS_DRIVER_GET_LOCATION_V2.

    This will make the whole interface much much better, and will mean that multiple applications can access the data via the GPS ID API’s and some will get a valid fix and others will not depending on what they need the position for.

    I am sure if you, as Microsoft, support the $GPGST estimated accuracy fields, then the GPS manufacturers will start to output this data.

  4. cenet says:

    Geraint – thank you for this very detailed feedback and for the feedback on the other post.  I actually am looking into the estimated accuracy field, though the structure that the guys in research came up with is a bit different than the $GPGST fields which I wasn’t aware of until now.  Is it OK if the GPS_POSITION2 structure would have error accuracy of some form and I’d force the GPS chip to do a poll-driver and do IOCTL_GPS_DRIVER_GET_LOCATION?  Not all Microsoft groups have equal weight in the market so I don’t know if I could count on WinCE supporting $GPGST to get manufacturers to do it (if we were Vista it’d be a different story of course :)).  However I think that people targeting GPS for CE specifically (aka not just a serial interface but doing the extra driver) are going to want to use a IOCTL_GPS_DRIVER_GET_LOCATION (which is supported in CE 6.0 now) rather than generating NMEA.

    If you (or any other GPS chip manufacturer for that matter) ever have feedback on GPS position structures or how GPSID works, feel free to contact me directly at JSPAITH at microsoft com.  Please note I don’t know if you guys have an NDA with MS or not, so I don’t want to know any super-secret info from your part but I do appreciate feedback.

    John

  5. Stephen says:

    As an application developer my problem with going with something "new" is that we now need

    to drop support for "old" devices. NMEA via serial works now because it supports the full range

    of CE devices. The problem with abstraction layers is that it is uncertain if they are going to

    change in new revs of the OS.

  6. cenet says:

    Stephen – GPSID is part of Win32 now on WinCE, which means that if I break back-compat then someone will come to my office and break me :(.  On any OS there’s always the danger of BC problems for any API of course, but GPSID doesn’t get some sort of free pass.

    The fact GPSID isn’t available on the PocketPC2003 devices or older and won’t ever be is a shame since it does mean apps that target both have to be NMEA based still (I literally just sent an email to an MS dev discussing this), but at some point the number of 2003 devices out there&still being dev’d for will go down so GPSID eventually will be a given.

    John

  7. Tami says:

    Hello John,

    I’ve read somewhere that managed API to GPS is planned. Do you have some information as to the possible time-frame? When can we expect it? Thanks a lot.

    Tami

  8. cenet says:

    Tami – actually it’s available already in the SDK Samples someplace, and a number of folks are using it already with really good success.  I don’t know where exactly it lives in SDK.  Check out http://blogs.msdn.com/cenet/archive/2006/02/10/windows-ce-gpsid-its-c-wrapper-and-device-emulator-interaction-issues.aspx for the names of fcns in it (and caveats in using it) if that helps find.

    John

Skip to main content