Windows CE Networking Team WebLog

Windows CE Networking - from NDIS to TCP to SOAP to VOIP and everything in between.

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]

Published Monday, August 14, 2006 8:39 AM by cenet
Filed under:

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Nino.Mobile said:

Software / Hardware SOTI Pocket Controller Professional v5.07 is out Pocket PC Thoughts is reporting
September 4, 2006 9:17 PM
 

Geraint said:

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
October 6, 2006 9:25 AM
 

cenet said:

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

October 9, 2006 3:22 PM
 

Anil said:

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.

January 17, 2007 12:20 PM
 

cenet said:

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

January 17, 2007 5:34 PM
 

Windows CE Networking Team WebLog Getting position of a Windows | Insomnia Cure said:

June 8, 2009 6:40 PM
 

Windows CE Networking Team WebLog Getting position of a Windows | internet marketing tools said:

June 16, 2009 12:30 AM
 

Windows CE Networking Team WebLog Getting position of a Windows | debt consolidator said:

June 19, 2009 11:38 AM

Leave a Comment

(required) 
(optional)
(required) 
Submit

© 2009 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Microsoft
Page view tracker