Compartilhar via

Global Navigation Satellite System (GNSS) Test Guidance

  • Artigo

This article provides global positioning system (GPS) implementation guidelines to ensure a high-quality, competitive GPS experience in computers that run Windows 8 and Windows 8.1. The guidelines in this article apply to original equipment manufacturers (OEMs), independent hardware vendors (IHVs), and other Microsoft partners (such as software vendors). This article focuses on testing the integration of global navigation satellite system (GNSS) devices into a Windows 8 system.

Testing of areas other than GPS is out of the scope of this document. Fully exercising the operating system components or the GNSS device is out of the scope of this document. It is assumed that the IHVs and OEMs thoroughly test their GNSS device both independently and integrated into the system. Interoperability testing is limited to the components that interact with the location platform and devices. This testing should include successful completion of the Windows Hardware Certification Kit (Windows HCK) tests, this test plan, pre-operator trial tests, and internal tests that are developed specifically for the GNSS driver and GNSS receiver.

Note  

In this article, the term GPS is used interchangeably with GNSS. Unless it is otherwise stated, GPS refers to satellite positioning as a location provider solution, instead of as the GPS satellite system that is deployed by the United States government.

 

Clear sky conditions are defined as GPS/GNSS satellites that receive signals without obstruction from above or from the surrounding environment down to an elevation mask of 5 degrees above the horizon. All signal levels must be consistent with unobstructed signal levels at the ground and not lower than -131 dBm.

This information applies to the following operating systems:

  • Windows 8

  • Windows 8.1

In this article:

  • Requirements from Partners

  • Reporting and results communication

  • Test equipment

  • Functionality tests

  • Assisted GPS tests

  • Power consumption tests

  • Power management tests

  • Antenna performance tests

  • Interoperability tests

  • Drive tests

  • Simulator tests

  • GPS acceptance test matrix

Requirements from Partners

To receive certification, Microsoft partners must meet the following requirements:

  • To enable Assisted GPS (A-GPS) testing and the ability to cold-start a device, GNSS Drivers must support the SENSOR_PROPERTY_CLEAR_ASSISTANCE_DATA property. To enable turning on and turning off National Marine Electronics Association (NMEA) sentences in data reports, the GNSS Driver must support SENSOR_PROPERTY_TURN_ON_OFF_NMEA. By default, NMEA lines are not included in data reports. This requirement is explicitly described here:

    //{e1e962f4-6e65-45f7-9c36-d487b7b1bd34}DEFINE_GUID(SENSOR_PROPERTY_TEST_GUID, 0XE1E962F4, 0X6E65, 0X45F7, 0X9C, 0X36, 0XD4, 0X87, 0XB7, 0XB1, 0XBD, 0X34);DEFINE_PROPERTYKEY(SENSOR_PROPERTY_CLEAR_ASSISTANCE_DATA, 0XE1E962F4, 0X6E65, 0X45F7, 0X9C, 0X36, 0XD4, 0X87, 0XB7, 0XB1, 0XBD, 0X34, 2); //[VT_UI4]

    DEFINE_PROPERTYKEY(SENSOR_PROPERTY_TURN_ON_OFF_NMEA, 0XE1E962F4, 0X6E65, 0X45F7, 0X9C, 0X36, 0XD4, 0X87, 0XB7, 0XB1, 0XBD, 0X34, 3); //[VT_UI4]

    #define GNSS_CLEAR_ALL_ASSISTANCE_DATA 0x00000001

    SENSOR_PROPERTY_ CLEAR_ASSISTANCE_DATA (PID = 2)

    VT_UI4. Write. Clear the assistance data. Setting a value of GNSS_CLEAR_ALL_ASSISTANCE_DATA signals the driver to clear all assistance data, including time, almanac, ephemeris and last position.Windows HCK tests can set this value to clear the assistance data before a cold start test, before A-GPS tests, or independently before running simulator tests where time and location is simulated. If A-GPS capabilities (for example, SUPL, LTO) are supported, the driver can try to utilize the capabilities after this operation by using the network connection. However, the device should be in a state where no assistance data is saved in the device or on the system. Any assistance data elements are downloaded again.

    SENSOR_PROPERTY_TURN_ON_OFF_NMEA (PID = 3)

    VT_UI4. Read/Write. If set to TRUE, NMEA sentence is included in data reports. If set to False, NMEA sentence is not included in data reports. Windows HCK tests can use this property to instruct the device to start or stop including NMEA data in data reports.

     

  • In addition to required Windows Hardware Certification Kit (Windows HCK) tests, optional Windows HCK Device.Input Tests must run and pass for non-ARM System on Chip (SoC) systems. (These tests are already mandatory for ARM systems).

  • OEMs and IHVs must run and document the tests that are specified in the GPS acceptance test matrix before they can submit a system, device, or driver to Microsoft.

  • IHVs should review failures as reported at https://sysdev.microsoft.com that are caused by their GPS drivers, and fix all high-impact failures.

  • Antenna requirements from OEMs must include the items that are listed in Antenna performance tests.

  • The SENSOR_DATA_TYPE_NMEA_SENTENCE property must be supported on systems to verify dynamic navigation accuracy and antenna quality.

  • No dependency on third-party services or Win32 applications can accompany the GPS solution. Third-party Win32 applications are subject to signing requirements on SoC systems and are therefore not allowed.

  • USB connected GPS devices must support selective suspend.

  • GPS on mobile broadband modules must update by using Unified Extensible Firmware Interface (UEFI), and a standalone GPS must update by using a driver.

  • When GPS and mobile broadband exist on the same physical chip, the GPS device should be exposed as part of a USB composite device and it should have its own USB interface.

Reporting and results communication

Microsoft will communicate all issues to partners using bugs. The bugs will contain Windows HCK logs, traces, driver logs, crash dumps, and any relevant performance results and baseline performance comparison data.

Test equipment

The following test equipment is used to perform the tests that are described in this article:

  • Spirent GSS6700 GNSS Simulator

  • Faraday cage

  • RF shielding box

  • Mobile Broadband SIM

  • Reference Devices: Garmin Montana; Windows Tablets that have GPs devices that are certified by using Microsoft Signature.

  • External antennas

Functionality tests

Windows HCK tests that apply to GNSS devices are the first set of tests to verify the basic functionality of GPS devices. Windows HCK contains tests for GPS Sensors, Radio Manager, Device Fundamentals, System Fundamentals Power Management, and USB Hardware Certification tests (for USB connected devices) that apply to GNSS devices.

Sensor category, type, properties and data fields

Description: The device should report correct sensor category and type, support mandatory properties and data fields, and report accurate data. In addition to the mandatory sensor properties that are verified in the Windows HCK, managed program systems must support the SENSOR_DATA_TYPE_NMEA_SENTENCE property.

Run Steps: Query sensor category, type, properties, and data fields the Device Under Test (DUT) reports. Confirm the accuracy of the reported data. You can use the Sensor Diagnostics Tool (SDT) in the Windows Driver Kit (WDK) to test these items.

Expected Result: Mandatory fields must be supported and report accurate data.

State transitions

Description: The device should report changes in sensor state, as documented in Writing a location sensor driver.

  • Data reports must be reported only after a device reaches SENSOR_STATE_READY or SENSOR_STATE_INITIALIZING.

  • A device should not report data if it does not have latitude and longitude information.

  • A GPS sensor must start in the SENSOR_STATE_INITIALIZING state before it obtains a location fix.

  • A GPS sensor should continue to acquire a location fix and must stay in the SENSOR_STATE_INITIALIZING state until the request is cancelled by the operating system.

  • A GPS sensor must go into the SENSOR_STATE_INITIALIZING state when it loses the signal and no longer has data. It should go back to into the SENSOR_STATE_READY state when it reacquires a location fix.

Run Steps: You must monitor state transitions and data events while you disable and re-enable the device. Move into an area that has no GPS signal (for example, a Faraday cage), wait for at least one minute, and return the device to an area that has coverage.

Expected Result: The device should report sensor state transitions (for example, from SENSOR_STATE_INITIALIZING to SENSOR_STATE_READY), and data reports should be reported only after reaching these states. Data is only reported if latitude and longitude information is available. The device should start in the SENSOR_STATE_INITIALIZING state and should not move into the SENSOR_STATE_READY state until after it gets a location fix and has a valid error radius. When the device is moved out of a GPS signal coverage area, the device should go into the SENSOR_STATE_INITIALIZING state, and it should revert to SENSOR_STATE_READY when it is returned to a coverage area.

Latitude and longitude accuracy

Description: The device should provide accurate latitude and longitude values in the specified error radius.

Run Steps: During static testing and in-vehicle testing, device data is compared to latitude and longitude data that reference GPS, survey markers, and a simulator report.

Expected Result: The difference between the latitude and longitude values that the device reports and the reference GPS reports must be inside the error radius.

Speed data

Description: The device should report speed data in knots when the device is moving.

Run Steps: Monitor the speed data that the device reports during simulated in-vehicle or drive tests.

Expected Result: The device should report speed data that is accurate within ±15% of the speed data that a reference GPS or simulator reports.

Heading data

Description: The device should report headings in degrees that are relative to true north when the device is moving.

Run Steps: Monitor the heading data that is reported by the device during simulated in-vehicle tests, manual walking tests, and drive tests.

Expected Result: The device should report heading data, which should be within ±15% of the heading data that a reference GPS or simulator reports.

Other sensor properties

Description: If other sensor properties are supported by the device, the properties should report valid data and accurate values.

Run Steps: Monitor properties that the device supports and verify that they provide valid data within acceptable accuracy ranges.

Expected Result: If a device supports a particular sensor property, the device should report accurate values within ±20% of the values that a reference GPS or simulator reports.

Assisted GPS tests

Within a few seconds of initial power-up, a GPS device should use A-GPS to return an approximated location. When the GPS uses A-GPS, the sensor should provide location data, which can be from several hundred meters to six figure numbers. When the GPS radio can obtain multiple satellite locks, the error radius should decrease to a value of 3 to 30 meters.

A-GPS

Description: A-GPS should help to obtain a faster Time to First Fix (TTFF) that has higher accuracy.

Run Steps: Cold-start the GPS device. Monitor latitude, longitude and error radius data fields by using the SDT.

You should run the tests under the following conditions:

  • Clear-sky conditions (simulated or actual)

  • Subscribed for data events

  • Report interval of one second

  • Wi-Fi or cellular baseband is present and enabled

Expected Result: The device should return a position from A-GPS as soon as possible, and should report an associated error radius. The higher error radius (for example, 300 meters if Wi-Fi is available) should decrease to 3 to 30 meters as the device acquires multiple satellite locks. GPS should report a position within 15 seconds that is based on assistance data.

Position injection

A GPS driver can use data from its triangulation sensors to speed up TTFF by using the Sensor API (ISensorManager). If a driver is used, the following tests apply:

  • Connection time

    Description: A GPS driver should close the connection to other sensors immediately after it gets a position. It should timeout after 15 seconds and it should close the connection to the Sensor API if it does not get a position.

    Run Steps: Monitor the traces from the Sensor API for the active client counts for all sensors in the system. Cold-start the GPS device and monitor the changes on the active client counts for other sensors in the system.

    Expected Result: If active client counts for other sensors are incremented, they should return to their previously recorded values after 15 seconds.

  • Connection type

    Description: GPS drivers should not instantiate ILocation to get data from other location sensors. They can use the Sensor API to open a connection for instance triangulation sensors (SENSOR_TYPE_LOCATION_TRIANGULATION). A GPS driver should not get data from location sensors of the same type. For example, a GPS sensor should not use data from other sensors with type GPS to get a faster location fix.

    Run Steps: Discover the sensor type that the device is reporting; for example, SENSOR_TYPE_LOCATION_GPS. Disable all sensors except for sensors of the same type as the device. Monitor the traces from the Sensor API for the active client counts for enabled sensors in the system. Cold-start the GPS device. Monitor the changes on the active client counts for sensors in the system.

    Expected Result: The device should not increment active client counts for sensors of the same type.

Robustness

Driver Verifier, WDF Verifier, and Application Verifier are enabled for the location platform and the GPS device stack to test the reliability of GPS support in the system.

Driver Verifier is part of the Windows operating system. It can be started from a command prompt that has administrative privileges by using the following settings:

Verifier /standard /driver wudfpf.sys Wdf01000.sys Wdfldr.sys wudfrd.sys <any kernel mode driver >, <dependent kernel mode drivers >

Where <any kernel mode driver> is the driver to be verified, and <dependent kernel mode drivers> are the kernel mode drivers on which the GPS driver depends; for example, wmbclass.sys.

For more information about Driver Verifier, see About Driver Verifier.

WDF Verifier is enabled by default for all WDF drivers. The WdfVerifier.exe tool in the WDK can be used to control the verbosity of logging, debugger settings, and more. For more information about WDF Verifier, see WDF Verifier Control Application.

Application Verifier (appverif.exe) is available in Windows HCK and the Windows 8.1 SDK. A minimum of basic settings is required.

Driver Verifier, WDF Verifier and Application Verifier

Description: Enable Application Verifier and Driver Verifier at the beginning of testing.

Run Steps: Enable Driver Verifier on all kernel mode drivers in the driver package (if any) and enable any kernel mode drivers on which the GPS driver depends. Enable Application Verifier for %windir%\system32\WUDFHost.exe and other user-mode binaries on which the GPS driver depends (for example, wwanapi.dll).

Expected Result: No verifier failures.

Telemetry data

Description: Monitor telemetry data from site https://sysdev.microsoft.com for the GPS driver.

Run Steps: Monitor telemetry data from https://sysdev.microsoft.com for the GPS driver. Identify, investigate, and fix the driver failures.

Expected Result: The device must report all telemetry failures; you should triage, investigate, and fix the primary problems.

GPS stress tests

A combination of the following operations is simultaneously performed on the GPS device during simulator testing, walk testing, and drive testing:

  • Enable Driver Verifier

  • Enable Application Verifier

  • Repeated Windows HCK test runs (GPS Sensor, Radio Manager, System Power Management)

  • Radio management operations

  • Connected Standby

  • GPS device disable/re-enable

  • Windows Location Provider disable/re-enable

  • Mobile Broadband device disable/re-enable

  • Wi-Fi device disable/re-enable

  • Turn off Mobile Broadband radio

  • Turn off Wi-Fi Radio

  • Large download over Mobile Broadband connection

  • Large download over Wi-Fi connection

  • Bluetooth activity

Perform a basic verification test before the stress testing. It is expected that the same verification test passes both before and after the stress tests, and that no failures are observed.

Performance

GPS device performance is tested for cold-start TTFF, hot-start TTFF, acquisition sensitivity, tracking sensitivity, re-acquisition time, static navigation accuracy, and dynamic navigation accuracy.

A GNNS simulator that has an OTA connection can be used for performance testing.

Cold-start TTFF

Description: Cold-start TTFF should be achieved in less than 45 seconds for 90% of the time. Cold-start is described as the following condition:

  • Time is unknown

  • Current ephemeris is unknown

  • Position is unknown

Run Steps: You can use the SDT to clear the GPS assistance data before you start the cold-start test. Ensure that the cold-start conditions described above are met. Monitor the TTFF under clear sky conditions (actual or simulated).

Expected Result: The device should use the GNSS device to get a location fix within 45 seconds for 90% of the time.

Acquisition sensitivity

Description: The device should obtain a location fix at -150 dBm or lower power levels.

Run Steps: Under simulated lab conditions, by using a direct radio frequency (RF) connection when antenna connector is accessible, expose device to low power levels up to -150 dBm.

Expected Result: The device should acquire a fix at -150 dBm.

Tracking sensitivity

Description: The device should maintain a location fix at -155 dBm or lower power levels.

Run Steps: Under simulated lab conditions, by using a direct RF connection when an antenna connector is accessible, reduce the power level to -155 dBm after the device obtains a location fix.

Expected Result: The device should maintain a location fix -155 dBm.

Reacquisition time

Description: The device should be able to reacquire a location fix in 2 seconds. Clear sky conditions are assumed when a signal is available.

Run Steps: Under simulated lab conditions, after the device obtains a location fix, reduce the power level enough to force the device to lose the fix. Then increase power levels and monitor the reacquisition time. Alternatively, you can drive through a tunnel during drive testing.

Expected Result: The device should reacquire a location fix in 2 seconds.

Static navigation accuracy

Description: The device should report accurate latitude, longitude, and altitude (if supported).

Run Steps: Compare the accuracy of longitude, latitude and altitude (if available), to the location from a trusted data source. Trusted data sources can be survey markers, GNSS simulators, or a Microsoft Signature-certified Windows tablet that has GPS.

Expected Result: The DUT should report horizontal accuracy of 15 meters and vertical accuracy of 30 meters for 95% of the time.

Dynamic navigation accuracy

Description: When the DUT is mobile, the DUT should accurately report latitude, longitude and altitude if supported.

Run Steps: During simulated or actual device/walk testing, compare the accuracy of longitude, latitude and altitude (if available), to the location from trusted data source. Trusted data sources can be survey markers, GNSS simulators, or a Microsoft Signature-certified Windows tablet that has GPS.

Expected Result: Device should report horizontal accuracy of 15 meters and vertical accuracy of 100 meters.

Power consumption tests

The following diagram illustrates how a driver can use WDF idle detection StopIdle/ResumeIdle methods to move between D-States.  The test cases in this section confirm that the driver is going to the correct state at the appropriate time.

<Art placeholder for Fig1_ Fig1_stopidle_resumeidle>

Figure 1. StopIdle/ResumeIdle

USB selective suspend

This test applies to USB connected devices only. A GPS device for which no clients subscribe for a report interval of 8 seconds or less should participate on selective suspend when all devices on the bus are ready to go into a Suspend state.

Device Manager and Event Tracing for Windows (ETW) events are used to monitor the USB bus state transitions.

Average sleep power consumption

GPS device should have a sleep average power consumption of less than 1mW, including any bus connection interfaces. If this is not the case, the device must support removing power completely from the GPS device when in D3 (D3-Cold).

D3-Cold

Devices that support D3cold should not degrade the TTFF performance for more than 6 seconds. For example, if a device can get a location fix in 2 seconds under hot-start conditions, it should be able to get a fix in 8 seconds or less when it resumes from D3cold. If device cannot meet this requirement, the driver should limit D3cold state transitions to when GPS Radio is disabled.

For more information about D3cold, see Supporting D3cold in a Driver.

Power management tests

Connected Standby

Connected Standby testing includes Windows HCK PowerState tests and Device Fundamentals tests with IO cover test scenarios.

Resume in no coverage area

Description: Put the system into the Connected Standby state when there are active clients. Resume in a no-coverage area. The device should try to acquire a location fix and enter the SENSOR_STATE_INITIALIZING state.

Run Steps: When active clients are connected, put the device into Connected Standby. Wake from Connected Standby in an area that does not have a GPS signal.

Expected Result: The device should acquire a location fix and go into the SENSOR_STATE_INITIALIZING state.

Antenna performance tests

Performance tests that use an OTA connection

It is common to performance-test GNSS receivers in a lab environment over a cabled RF connection, thereby bypassing the GPS antenna and its associated circuitry. Device performance and issues in GPS antenna and its circuitry can cause poor user experience in location-based service applications. To discover these issues, you should test managed system devices for GPS performance by using an OTA test methodology.

Antenna testing includes the following requirements for certification:

  • Systems that have GPS support must pass testing according to the Cellular Telecommunications & Internet Association (CTIA) Test Plan for Mobile Station Over-the-Air Performance, Method of Measurement for Radiated Radio Frequency (RF) Power and Receiver Performance v3.0+ for A-GPS. For more information about CTIA tests, see CTIA Certification Tests. In addition, Total Isotropic Sensitivity (TIS), Upper Hemisphere Isotropic Sensitivity (UHIS) and Partial Isotropic GPS Sensitivity (PIGS), must be measured; OEMs must post measurement results to Microsoft for review. These requirements apply to systems that have Mobile Broadband support.

  • The system must have TIS and UHIS free space of -140 dBm or better for GPS. For systems that have Mobile Broadband support, the measurements must follow the test methodology and test parameters that are defined in the Antenna Performance for execution guidelines for Wi-Fi-only systems section of the CTIA 3.x test plan.

  • The average gain of the GPS antenna must be better than -6dBi.

  • Performance must not drop below the minimal acceptable standard when the device is held in a common handheld position. The device must maintain over-the-air (OTA) acquisition sensitivity at -140 dBm and OTA tracking sensitivity of -145 dBm when the system is held in common positions.

  • The device must maintain OTA acquisition sensitivity at -140 dBm and OTA tracking sensitivity of -145 dBm when the keyboard or docking station is closed.

  • You must perform antenna and radiated sensitivity testing when the GPS antenna is in the expected positions in the device.

  • The intended GPS production antenna must be in its intended location for Engineering Verification (EV) systems. The antenna location must be finalized for Design Verification (DV) systems.

  • OEMs should run antenna performance and radiated sensitivity tests and understand the failures on EV units. The tests must pass prior to DV units.

RF Sensitivity Testing for Wi-Fi-only systems

A GPS IHV can provide NMEA logging and plotting tools and documentation.

Compare Signal-to-Noise Ratio (SNR) on the test device and on a reference device that has good GPS RF sensitivity at the same location under the same conditions. Enable IHV NMEA logs and take the devices for walk/drive testing for 15+ minutes under a clear sky. Analyze the logs by using the NMEA Plotting tool that the IHV provides. Compare average signal strength of the devices.

Note  

If you do not have the NMEA Plotting tool from an IHV, you can use Microsoft® Bing

 

Human interference tests

Antenna positioning should take human interference into account. When the system is held in common states, GPS should not lose a location fix, should not increase the error radius more than 30%, and should maintain OTA acquisition sensitivity at -140 dBm and OTA tracking sensitivity of -145 dBm.

Commonly used states for slates:

  • Hands on the sides, landscape orientation

  • Hand on bottom, landscape orientation

  • Hands on the sides, portrait orientation (start on left)

  • Hands on the bottom, portrait orientation (start on left)

  • Hands on the sides, portrait orientation (start on right)

  • Hands on the bottom, portrait orientation (start on right)

Human interference impact on acquisition and tracking sensitivity

Description: The device acquisition and tracking sensitivity should not cause performance to drop below the minimal acceptable standard when the device is held at specified handgrips.

Run Steps: Hold the device in common handheld positions. Check acquisition sensitivity and tracking sensitivity.

Expected Result: Tracking and acquisition sensitivity should not be impacted when the device is held in certain positions. The device should maintain OTA acquisition sensitivity at -140 dBm and OTA tracking sensitivity of -145 dBm.

Interoperability tests

Mobile Broadband, Wi-Fi, and GPS interoperability

Description: Disabling mobile broadband or Wi-Fi device should not prevent GPS from functioning. Turning MB or Wi-Fi radio off should not prevent GPS from getting a location fix.

Run Steps:

  • Disable Mobile Broadband and confirm that GPS can still get a location fix. Re-enable Mobile Broadband.

    Note  

    GPS devices that use device services is an exception; these devices should first go into SENSOR_STATE_INITIALIZING state and, after 30 seconds, should go into the SENSOR_STATE_NOT_AVAILABLE state when Mobile Broadband is disabled

     

  • Disable Wi-Fi and confirm that GPS can still get a location fix.

  • Turn off Mobile Broadband Radio and confirm that GPS can still get a location fix.

  • Turn off Wi-Fi Radio and confirm that GPS can still get a location fix.

  • Remove the Mobile Broadband SIM and confirm that GPS can get a location fix.

Expected Result: For Mobile Broadband or Wi-Fi devices, radio and SIM state should not prevent GPS from functioning.

Mobile Broadband, Wi-Fi, Bluetooth, Near Field Communication (NFC), and camera interference

Radios and other devices such as system cameras can interfere with the GPS. GPS devices commonly share the same module with Mobile Broadband, Wi-Fi and Bluetooth. GPS functionality should not be impacted by these devices.

Description: Simultaneous usage of Mobile Broadband, Wi-Fi, Bluetooth, and camera should not degrade the performance and functionality of the GPS device, or vice versa.

Execution Steps: Run basic functionality tests with Mobile Broadband, Wi-Fi, Bluetooth, and camera on and actively in use.

  • Perform a large download over a Mobile Broadband connection while using GPS. Monitor sensor state, error radius and signal strength and the event logs from SDT.

  • Perform a large download over a Wi-Fi connection while using GPS. Monitor sensor state, error radius and signal strength and the event logs from SDT.

  • Perform a Bluetooth file transfer while using GPS. Monitor sensor state, error radius and signal strength and the event logs from SDT.

  • Perform a Wi-Fi scan while using GPS. Monitor sensor state, error radius and signal strength and the event logs from SDT.

  • Perform a Mobile Broadband scan while using GPS. Monitor sensor state, error radius and signal strength and the event logs from SDT.

  • Perform a Bluetooth scan while using GPS. Monitor sensor state, error radius and signal strength and the event logs from SDT.

  • Record video while using GPS. Monitor sensor state, error radius and signal strength and the event logs from SDT.

  • Watch a movie over the Internet while using GPS. Monitor sensor state, error radius and signal strength and the event logs from SDT.

  • Perform an NFC data transfer (for example, transfer photos) for 5 minutes. Monitor sensor state, error radius and signal strength and the event logs from SDT.

Expected Result: GPS should function normally during the time that these devices are being used. Usage of these devices should not impact sensor state, error radius and signal strength negatively.

Drive tests

Manual drive testing occurs when the system is taken on a drive by using a predefined route that includes tunnels and areas with different multipath impact. During the drive, the system GPS data is captured by a test application and is compared to a reference GPS. At no time should the location that the system reports be +/- the error radius outside the location reported by the reference GPS. The average error radius should be <= 30 meters.

Drive testing exercises real life conditions such as dynamic navigation accuracy, reacquisition after going through a tunnel, impact of multi-path signals, and atmospheric conditions.

The following functionality tests are run during drive testing:

  • State transitions are monitored and compared to reference GPS.

  • Latitude, longitude and altitude (if available) are monitored and compared to reference GPS. A visual map representation is used for easy comparison.

  • Speed and heading data are monitored and compared to reference GPS.

  • Acquisition time and reacquisition time after driving through tunnels are measured and compared to reference GPS.

  • Tracking sensitivity is monitored in multipath impact areas. Data report frequency and any interruptions on the data reports are monitored.

  • Dynamic navigation accuracy is monitored and compared to reference GPS by using visual map representations.

  • Device Plug and Play (PnP) and radio manager state transitions are performed during dynamic navigation.

  • Report intervals are monitored and compared to reference GPS.

Simulator tests

A GNSS simulator (Spirent GSS6700) is used to achieve controlled lab conditions. It replays same test scenarios for repetition, simulates satellite states, various locations, and time such as south of equator and 2 years later, simulates in vehicle navigation, atmospheric conditions, multi-path signals, and error conditions. The standard Spirent GSS6700 simulator test scenarios are run.

An OTA RF connection tests the system together with original antenna and shielding. Direct connection can also be used when an antenna connector is accessible for receiver testing. Simulator testing focuses on common simulator scenarios, including GNSS receiver performance characteristics and the following scenarios:

  • Cold-start TTFF

  • Hot-start TTFF

  • Acquisition sensitivity

  • Re-acquisition sensitivity

  • Tracking sensitivity

  • Static position accuracy

  • Dynamic position accuracy

  • Multipath

  • GPS and Globalnaya navigatsionnaya sputnikovaya sistema (GLONASS)

GPS acceptance test matrix

  • OS build tests run on:

  • Windows HCK version:

  • Platform firmware version:

  • Platform tests run on:

Test level Test description Verification results Comments

Basic (Level 1)

Driver must be signed with the IHV certificate

Basic (Level 1)

Driver must be installed by using device manager/ Deployment Image Servicing and Management (DISM)

Basic (Level 1)

GPS.Test Descriptions.Robustness.Driver Verifier, WDF Verifier and Application Verifier

Basic (Level 1)

Location Sensor WHCK tests: Device.Input.Sensor.*System tests for Location Sensors: System.Client.Sensor.*

Basic (Level 1)

Radio Management WHCK tests: System.Client.RadioManagement.*

Basic (Level 1)

In addition to required WHCK tests, Optional WHCK tests under Location Sensor WHCK tests: Device.Input.Sensor.* and System.Client.Sensor.* must run and pass for non-ARM SoC systems

Basic (Level 1)

Device Fundamentals WHCK tests: Device.DevFund.*

Basic (Level 1)

USB WHCK tests (USB connected devices only): Device.Connectivity.UsbDevices.*

Basic (Level 1)

GPS.Test Descriptions.Functionality.Sensor category, type, properties and data fields

Basic (Level 1)

GPS.Test Descriptions.Functionality.State Transitions

Basic (Level 1)

GPS.Test Descriptions.Functionality.Accuracy of Latitude and Longitude

Basic (Level 1)

GPS.Test Descriptions.Functionality.Speed Data

Basic (Level 1)

GPS.Test Descriptions.Functionality.Heading Data

Basic (Level 1)

GPS.Test Descriptions.Assisted GPS.A-GPS

Basic (Level 1)

GPS.Test Descriptions.Assisted GPS.Position Injection. Connection Type

Basic (Level 1)

GPS.Test Descriptions.Antenna Performance.OTA Connection. The device should get a location fix in clear sky outdoors as is without using external antennas or other modifications.

Basic (Level 1)

GPS.Test Descriptions.Interoperability.* (GPS can get a location fix when Mobile Broadband, Bluetooth, Wi-Fi, or camera is in active use)

Basic (Level 1)

GPS.Test Descriptions.Functionality.Other Sensor Properties

Basic (Level 1)

GPS.Test Descriptions.Assisted GPS.Position Injection. Connection Time

Basic (Level 1)

GPS.Test Descriptions.Antenna Performance.HumanInterference Tests. Device should get a location fix in clear sky outdoors as is without any external antennas or other modifications, while it is held in common handheld positions.

Stress (Level 2)

GPS.Test Descriptions.Robustness.*

Performance (Level 2)

GPS.Test Descriptions.Performance.*

Power (Level 1)

GPS.Test Descriptions.Power Consumption.*

Power (Level 1)

GPS.Test Descriptions.Power Management.*

Antenna Performance (Level 1 for OEM)

GPS.Test Descriptions.Antenna Performance.*

Drive Tests (Level 3)

GPS.Test Descriptions.Drive Tests.*

Simulator Tests (Level 4)

GPS.Test Descriptions.Simulator Tests.*

 

Windows Sensor and Location Platform

Location driver guidelines for power and performance

Writing a location sensor driver

Filtering data

Sensor Device Testing Prerequisites

 

 

Send comments about this topic to Microsoft