GPS Intermediate Driver Power Management

Article
11/18/2015

A version of this page is also available for

4/8/2010

GPS hardware is a large consumer of power in target devices. It is common for GPS hardware to use as much power as the device display.

Hardware driver developers can use various techniques to manage GPS power usage, depending on:

The type of driver supporting the GPS device (V2, V1 or COMM)
The type of driver client applications are written to (V2, V1 or COMM)

The Role of GPSID in Power Management

The GPS Intermediate Driver (GPSID) communicates with the hardware driver, which has actual control over the hardware.

GPSID does not directly power up or power down the GPS device.

All Drivers

Minimizing TTFF

Minimizing Time To First Fix (TTFF, or "Startup time") using a combination of driver and client application code may conserve battery power. For more information, see Shortening GPS Fix Time in Implementing GPS Intermediate Driver Hardware IOCTLs.

Cached Fixes

Cached fixes are location fix data stored by the GPSID with a timestamp of when the fix was obtained. Power is conserved by reusing a recent fix, instead of requesting a new fix. Client applications request Cached Fixes by calling GPSGetPosition with hGPSDevice = null and dwMaximumAge > 0. For example:

GPS_POSITION pGPSPosition;
pGPSPosition.dwVersion    = GPS_VERSION_1;
pGPSPosition.dwSize       = sizeof(pGPSPosition);
DWORD error = GPSGetPosition( gpsHandle, &pGPSPosition, 1000, 0);

If GPSID does not have a cached fix within the requested parameters, the dwValidFields of &GPSPosition contains zeroes.

Use Case: Weather: A client application displays the next day's weather. The display is low priority, and should be bypassed when the mobile device is running on batteries. The client application uses this technique to retrieve the most recently available cached fix. If the priority of the weather report is higher, such as when the user requests a refresh of the data, the client application can request a new location fix from GPSID.

All Poll Drivers

POLL Driver V1

V1 drivers open the GPS hardware as soon as a client application makes an open request.

POLL Driver V2

Deferring Hardware Initialization

V2 drivers can defer opening the GPS hardware until there is at least one active request. An active request is a handle which has an associated GPSSetDeviceParam: GPS_START_FIX call, or an associated GPSSetDeviceParam: GPS_QUERY_FIX call.

To enable this behavior, a client application calls GPSOpenDevice with dwFlags = GPS_OPEN_NO_HARDWARE_INIT.

GPS_QUERY_FIX vs. GPS_START_FIX

V2 drivers are provided with a new interface: GPS_QUERY_FIX. This interface provides applications with a way to inform the driver that a single fix is required, and no further fixes are required in the near future. Therefore, the driver can choose to power down the GPS hardware after providing the fix.

Definitions:

GPS_START_FIX	Signals the driver that location fixes are required at repeated short intervals. These location fixes are required to continue until GPS_STOP_FIX is issued.
GPS_QUERY_FIX	Signals the driver that a single location fix is needed now. No data is available as to when the next fix might be required.

In response to GPS_START_FIX, the driver (and ultimately the hardware) is expected to produce location fix data at regular intervals, typically once per second. This requires that the hardware be continuously powered.

The GPS_QUERY_FIX parameter of the IOCTL_GPS_SET_DEVICE_PARAMETER call adds the ability to request a one-time location fix from the driver. After the location fix is obtained, the driver then has the opportunity to power down the hardware.

Some use cases are:

Use Case: Auto Navigation: A user is driving an automobile to a city and requires navigational assistance. The automobile is traveling at speeds of 5mph to 50mph. GPS_START_FIX would be used to provide frequent periodic position updates. The minimum update rate will be 1 second updates at 5mph, providing about 36 fixes per short city block. This is a very usable rate for driving navigation. Mobile devices are typically powered by the automobile, and power savings is not a critical issue.

Use Case: Mountaineering: A user is climbing a mountain and travelling at speeds from .1mph to 2mph. The mobile device is powered by batteries, and power savings is a highly critical issue. The user refers to the mobile device for location fixes in 5 to 15-minute intervals by pressing a button on the mobile device. The button triggers a call to GPS_QUERY_FIX, which the driver uses to power up, obtain a fix, and power down the GPS hardware.

COMM Driver

There are two ways to implement a COMM driver to interface with GPSID:

1. Use the default serial driver.

2. Write a custom serial driver.

If you use the default serial driver, power management is limited to manual controls that the device user manipulates. Therefore, power optimization is limited to whatever logic is embedded in the hardware.

When writing a custom serial driver, you can choose to optimize power using any or all of the following:

Power up the GPS when either a CreateFile and/or ReadFile is issued to your driver.
Power down the GPS when CloseHandle is issued against the CreateFile handle of your driver.
Support the IOCTLs IOCTL_SERVICE_START and IOCTL_SERVICE_STOP.
With these interfaces implemented, GPSID will help you optimize power by:

Keeping track of how many client applications are using GPS data. When the client count transitions from zero to one, GPSID issues a CreateFile against the COMM driver, and starts an infinite loop of ReadFile calls. When the client count transitions from one to zero, GPSID stops the ReadFile call loop and issues a CloseHandle against the COMM driver. The client count is calculated as count(GPSOpenDevice) + count(CreateFile) - count(GPSCloseDevice) - count(CloseHandle).
Passing IOCTLs from client applications to your driver. So you can change the power state in response to IOCTLs like IOCTL_SERVICE_START and IOCTL_SERVICE_STOP. This is most helpful when you have written the client application. Note that these are not the IOCTLs described in Controlling GPS Intermediate Driver Execution.

Partager via