Getting position of a Windows Mobile 5 device on the cheap


Let's say that you have an application where if it had the position of the device it would be cool, but if it didn't have the position it's not really a big deal.  Imagine a home screen plugin for instance where it would be an added bonus to display the next day's weather, but not critical.  In this case what you want to do is ask for the device's position if the device happens to know it already but not turn a GPS unit and drain the battery just for a pri3 scenario.


GPSID supports this functionality.  If you call GPSOpenDevice() that tells GPSID to start up the underlying GPS device, if there is one, which potentially causes the battery drain.  However if you just call GPSGetPosition and pass in a NULL HANDLE for the hGPSDevice and don't call GPSOpenDevice, it will only try to get a cached position.  If one's available cool, if not life goes on.  Obviously this won't help if you're doing a navigation app since you need to turn the GPS unit on no matter what.


This feature is already doc'd here, but as I've been asked how to do this a few times I'm guessing no one reads the docs :(.  At a minimum I hope that even if you're not using location enabled apps now because you don't want to deal with a battery drain, this blog has given you some ideas.


http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mobilesdk5/html/wce51lrfGPSGetLocation.asp


[Author: John Spaith]

Comments (8)
  1. Nino.Mobile says:

    Software / Hardware SOTI Pocket Controller Professional v5.07 is out Pocket PC Thoughts is reporting

  2. Geraint says:

    Hi John,
    The on-line documentation states that to save power the GPS will only be turned on when a call is made to GPSOpenDevice() and then turned off on the when all “opens” are “closed”.
    I’m looking at it from a GPS chip manufacturer’s point of view and its not clear to me how you actually turn the GPS hardware on and off.
    Do we have to provide a driver that is permanently running listening for some form of input from the GPS ID ?
    Do we have to provide a driver that is permanently monitoring the registry key “CurrentDriver” and if we see our key then we turn our hardware on, and if the key changes we turn the hardware off ?
    Please could you explain in more detail what you expect the GPS manufacturer to do in this respect.
    Thanks

  3. cenet says:

    Geraint, basically the way that I turn a driver on and off is that I CreateFile() on it to start and then CloseHandle when I’m done.  You’ll need a driver permanently loaded in the background even when I’m not using you, though you don’t have to have any threads or anything active in your driver when I’m not using you.  To get ontifications from GPSID, when it calls CreateFile() the kernel will map the call to your driver’s xxx_Open() and when I call CloseHandle() it’ll map to your xxx_Close().  You have the theoretical problem that another app could also call CreateFile() on your driver, so you can do ref counting if you want to support them or alternately just fail any but the first call.  If you’re on a Windows Mobile platform you can make yourself as trusted only driver so you can be pretty sure random stuff won’t be messing with you.

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnce50/html/implement_network_service.asp?frame=true has some background about writing a service in services.exe, a bunch (but not all!) also applies to device driver writing.

    You don’t have to monitor the "CurrentDriver" key at all — GPSID takes care of all this.  If someone changes the value on me, what’ll happen is that on the next time I startup the GPS hardware a different driver will get the xxx_Open() call.

    I’m very happy you’re actively integrating GPSID with your GPS chip – having the OEM tie closely with GPSID so there’s a good app development & end user experience is why I created did GPSID in the 1st place.

    John

  4. Anil says:

    Hi John,

    I just noticed that GPSID calls CreateFile() only once, no matter how many applications call GPSOpenDevice(). So, if I have a hardware specific driver, say "GPD1" (with necessary mux registry settings), and an App calls CreateFile (with "GPD1" parameter) to get data using raw interface and already another App has used GPSOpenDevice(), not yet done GPSCloseDevice(), doesn’t it go via the GPSID multiplexer and hence not result in GPD1_Open() ? Mainly I’m trying to see if there is a scenario where I have to really do a reference count for the application calls.

    Thanks.

  5. cenet says:

    You’re correct, I only do CreateFile() once no matter how many apps do GPSOpenDevice() — the reference counting is totally done at GPSID’s layer.  1st app using GPSID we do CreateFile on GPS device, when the # of apps using GPSID goes to 0 we close GPS device.

    In your setup, is "GPD1" the underlying GPS driver or is it the MUX that GPSID is doing for it?  The GPS driver and GPSID MUX’r have to have different registrations (like "GPD1:" for mux and "GPS4:" for real GPS driver, for instance).  I take it you’re writing a GPS driver here, Anil?  The one area where you would be worried about ref counting is if an application called CreateFile("Anil’s Driver") before any app called GPSOpenDevice() or CreateFile("GPS Multiplexer").  In this case that app could block GPSID based apps from accessing your data if you only let one app call your driver at same time.  So if you’re paranoid, you can either do a multiplexer at your level along with ref counting.  If you have faith in apps being behaved, then you don’t need that — you should probably just hard-code it so that if more than 1 guy calls CreateFile() on your driver then you fail, but nothing harder.  A bunch of existing GPS technologies, like Bluetooth GPS, have the same problem where an app can effectively Denial of Service GPSID if it doesn’t behave.  You can protect against this to an extent by in your xxx_Open() by doing <if (PSLGetCallerTrust() != OEM_CERTIFY_TRUST) {fail open;}> -> this would keep untrusted apps from opening your driver, and since gpsid.dll is in device.exe it’ll always be trusted.

    I’m happy to help you with this if you have more questions, but it may be easier if we continue this discussion one one of the newsgroups (http://blogs.msdn.com/cenet/archive/2005/12/05/500181.aspx).  I check newsgroups everyday and it’s easier for me to track them than it is using this blog software.

    John

Comments are closed.

Skip to main content