GNSS_DRIVERCOMMAND_TYPE-Aufzählung (gnssdriver.h)

Diese Enumeration gibt den Typ des Treiberbefehls oder der Konfiguration für den in der GNSS_DRIVERCOMMAND_PARAM Struktur bereitgestellten GNSS-Treiber an.

Syntax

typedef enum {
  GNSS_SetLocationServiceEnabled,
  GNSS_SetLocationNIRequestAllowed,
  GNSS_ForceSatelliteSystem,
  GNSS_ForceOperationMode,
  GNSS_ResetEngine,
  GNSS_ClearAgnssData,
  GNSS_SetSuplVersion,
  GNSS_SetNMEALogging,
  GNSS_SetUplServerAccessInterval,
  GNSS_SetNiTimeoutInterval,
  GNSS_ResetGeofencesTracking,
  GNSS_SetSuplVersion2,
  GNSS_CustomCommand
} GNSS_DRIVERCOMMAND_TYPE;

Konstanten

GNSS_SetLocationServiceEnabled Informiert den Treiber darüber, ob der Standort auf dem Gerät aktiviert ist. Dieser Befehl wird jedes Mal ausgegeben, wenn der Standortdienst auf dem Gerät aktiviert/deaktiviert ist. Die zugehörigen Befehlsdaten sind eine BOOL-. Nach Empfang dieses Befehls auf FALSE muss der GNSS-Treiber und das GNSS-Gerät folgende Aktionen ausführen: – Beenden Sie alle laufenden Standortsitzungen jeglicher Art und von einer beliebigen HLOS-Anwendung (wenn mehrere Anwendungen unterstützt werden). - Wenn das GNSS-Gerät oder der Treiber Vorgänge im Hintergrund ausführt, z. B. Geofence-Nachverfolgung, Aktualisierung von Unterstützungsdaten usw., sollten sie ebenfalls beendet werden. Der GNSS-Adapter beendet alle entladenen Vorgänge, wenn der Standort deaktiviert ist. Im Verhältnis zu Standortanforderungen des Mobilfunkanbieters: - Standortanforderungen des Mobilfunkanbieters für Notfallstandort, zur Erfüllung der CALEA-Anforderungen usw. sollten unabhängig vom Standortwechselstatus weiterhin bedient werden. Diese Anforderungen werden davon ausgegangen, dass das Kennzeichen für den Datenschutz außer Kraft gesetzt oder/und um den Zeitpunkt des Anrufs durch den Benutzer initiiert wird. - Andere vom Netzwerk initiierte Standortanforderungen sollten den befehl GNSS_SetLocationNIRequestAllowed berücksichtigen, wenn dieses Verhalten vom Mobilfunkanbieter benötigt und vom GNSS-Treiber implementiert wird. Wenn das HLOS beispielsweise eine neue Standortanforderung initiieren muss, damit der Benutzer das Gerät remote finden kann, sendet der GNSS-Adapter einen Befehl, um die GNSS_SetLocationServiceEnabled auf TRUE festzulegen, die Fixsitzung zu initiieren, und wenn die Ergebnisse empfangen werden, sendet er einen anderen Befehl, um die GNSS_SetLocationServiceEnabled auf FALSE festzulegen: - GNSS_SetLocationServiceEnabled auf TRUE=1-> Aktiviert festgelegt - GNSS_SetLocationServiceEnabled auf FALSE=0-> Deaktiviert festgelegt Sofern dieser Befehl nicht vom GNSS-Adapter ausgegeben wird, muss der Treiber davon ausgehen, dass der Standortdienst auf dem System deaktiviert ist.
GNSS_SetLocationNIRequestAllowed Informiert den Treiber, wenn es erlaubt ist, vom Netzwerk initiierte Standortanforderungen aus dem mobilfunknetz zu unterhalten. Der Befehl muss nur bei Bedarf vom Mobilfunkanbieter unterstützt werden. Ab Windows 10 ist Microsoft keinem Mobilfunkanbieter bekannt, der dies mehr erfordert, aber dies bleibt weiterhin, um Blockierungsprobleme während der Kommerzialisierung zu vermeiden. Wenn der Befehl nicht implementiert ist, sollte der GNSS-Treiber einfach sein Standardverhalten beibehalten. Die zugehörigen Befehlsdaten sind eine BOOL-: - GNSS_SetLocationNIRequestAllowed auf TRUE=1-> Zulassen festgelegt - GNSS_SetLocationNIRequestAllowed auf FALSE=0-> NotAllow festgelegt Sofern dieser Befehl nicht explizit vom GNSS-Adapter ausgestellt wird, muss der Treiber davon ausgehen, dass die NI-Anforderungen auf dem System aktiviert sind. Der GNSS-Adapter verwaltet einen systemweiten Zustand, der angibt, ob NI-Anforderungen zulässig sind. Dieser Zustand wird durch den Standortmasterschalter (die Einstellung, die der Benutzer aktivieren oder deaktivieren kann) und eine vom Mobilfunkanbieter konfigurierte Einstellung bestimmt, um anzugeben, ob NI-Anforderungen vom Standortmasterschalter abhängig sind oder nicht. Der GNSS-Adapter wertet den Wert dieser beiden Einstellungen aus und gibt dem GNSS-Treiber an, wenn NI-Anforderungen zulässig sind oder nicht. Die Standortanforderungen für Notdienste oder für CALEA (z. B. der Fall der einstellung der Außerkraftsetzung des Datenschutzes) müssen unabhängig vom Wert dieser Einstellung bereitgestellt werden.
GNSS_ForceSatelliteSystem Dieser Befehl bewirkt, dass der GNSS-Treiber das angegebene Satellitensystem(n) verwendet, um Korrekturen zu erhalten. Der Parameter ist ein DWORD- mit den folgenden Werten: - GNSS_SATELLITE_ANY (0x00) - GNSS_SATELLITE_GPS (0x01) - GNSS_SATELLITE_GLONASS (0x02) - GNSS_SATELLITE_BEIDOU (0x04) - GNSS_SATELLITE_GALILEO (0x08) 0x10-0xFF sind reserviert. Dies wird voraussichtlich nur für Testzwecke verwendet. Einige Mobilfunkanbieter erfordern Überprüfungen mithilfe eines einzelnen Satellitensystems.
GNSS_ForceOperationMode Dieser Befehl bewirkt, dass der GNSS-Treiber den angegebenen Betriebsmodus verwendet. Der Parameter ist ein DWORD- mit den folgenden Werten: - GNSS_OPERMODE_ANY (0x00) - GNSS_OPERMODE_MSA (0x01) - GNSS_OPERMODE_MSB (0x02) - GNSS_OPERMODE_MSS (0x04) - GNSS_OPERMODE_CELLID (0x08) - GNSS_OPERMODE_AFLT (0x10) - GNSS_OPERMODE_OTDOA (0x20) 0x40-0xFF sind reserviert. Dieser Befehl wird für zwei Zwecke verwendet: – So konfigurieren Sie den Betriebsmodus im Falle der SUPL-Konfiguration. Es wird erwartet, dass Mobilfunkanbieter das Gerät nur so konfigurieren, dass es im Microsoft-basierten Modus funktioniert, mit dem der SUPL-Dienst Hilfedaten (GNSS_OPERMODE_MSB) oder im eigenständigen Modus (GNSS_OPERMODE_MSS) abruft, in dem das GNSS-Gerät wirklich eigenständig arbeiten kann oder Unterstützung aus anderen Quellen als dem SUPL-Dienst verwendet. Der eigenständige Modus entspricht tatsächlich dem Standardmodus (GNSS_OPERMODE_ANY). – So konfigurieren Sie verschiedene Betriebsmodi für Testzwecke. Dies würde hauptsächlich von Mobilfunkanbietern oder OEMs zu Validierungszwecken verwendet. Das Festlegen der SUPL-GNSS_ForceOperationMode auf GNSS_OPERMODE_MSS ist ein Hinweis auf das GNSS-System, dass keine Interaktion mit dem SUPL-Server für AGNSS-Daten möglich ist.
GNSS_ResetEngine Dieser Befehl löscht den Zustand des GNSS-Moduls. Nachdem dieser Befehl ausgegeben wurde, ist das Modul bereit für einen Kaltstart-Fix: - Alle Unterstützungsdaten werden gelöscht. - Der Almanac wird beibehalten. - Die Konfigurationsparameter des GNSS-Moduls bleiben erhalten. Dieser Befehl sollte nur aufgerufen werden, wenn keine aktive Fixsitzung vorhanden ist. Dieser Befehl wird in der Regel zum rekursiven Testen der GNSS-Zeit verwendet, um den Kaltstart zuerst zu beheben.
GNSS_ClearAgnssData Mit diesem Befehl werden die AGNSS-Hilfsdaten aus dem GNSS-Motor gelöscht. Dies wird hauptsächlich zum Testen verwendet, um sicherzustellen, dass der Treiber Unterstützungsdaten anfordert, wenn ein Fix angefordert wird. Die zugeordneten Befehlsdaten enthalten die spezifische GNSS_AGNSS_REQUEST_TYPE Enumeration, um das zu löschende bestimmte Datenelement anzugeben: - Wenn GNSS_AGNSS_TimeInjection angegeben ist, wird der Zeitverweis im GNSS-Modul gelöscht. Dies kann dazu führen, dass das GNSS-Modul die Zeiteinfügung erneut anfordert. - Wird GNSS_AGNSS_PositionInjection angegeben, wird der grobe Positionsbezug im GNSS-Modul gelöscht. Dies kann dazu führen, dass das GNSS-Modul erneut grobe Positionseinspritzung anfordert. - Wenn GNSS_AGNSS_BlobInjection angegeben ist, werden sowohl ephemeris, die von den Satelliten erworben wurden, als auch alle injizierten Unterstützungsblobs im BLOB-Modul gelöscht. Dies kann dazu führen, dass das GNSS-Modul erneut ein Unterstützungs-Blob anfordert. Es wird dringend empfohlen, diesen Befehl für Testzwecke zu unterstützen, auch wenn die Unterstützungsdaten nicht von der Betriebssystemstandortplattform abgerufen werden.
GNSS_SetSuplVersion Mit diesem Befehl wird die SUPL-Version festgelegt, die vom Mobilfunkanbieter unterstützt werden soll. Die Befehlsdaten enthalten einen Wert der GNSS_SUPL_VERSION Struktur, die sowohl die Haupt- als auch die neben-SUPL-Versionen enthält, die vom Mobilfunkanbieter angegeben werden. Der SUPL-Client sollte die SUPL-Version verwenden, wie in den OMA SUPL-Standards angegeben, die wie folgt zusammengefasst werden: - Bei vom Netzwerk initiierten Szenarien trägt die SUPL INIT-Nachricht von der H-SLP oder E-SLP an das SET die beabsichtigte SUPL-Haupt- und Nebenversion M1.m1 (normalerweise die höchste Version, die vom SLP unterstützt wird) im Versionsparameter. Die SUPL INIT-Nachricht enthält auch die mindeste SUPL-Hauptversionsnummer M2, für die die Fortsetzung der Sitzung durch das SET im Minimalversionsparameter möglich ist. Der Wert von M2 hängt vom vorgesehenen SUPL-Dienst ab , z. B. für einen einzelnen Standort fix M2 kann eins sein; für ausgelöste Position M2 kann zwei sein. Eine SUPL-Sitzung kann zwischen dem SLP und dem SET durchgeführt werden, solange das SET eine SUPL-Hauptversion zwischen M2 und M1 verwendet. Das SET setzt die SUPL-Sitzung normal fort, wenn sie eine Hauptversion M von SUPL zwischen M2 und M1 unterstützt (z. B. M2 ≤ M ≤ M1) – und gibt diese Hauptversion und eine unterstützte Nebenversion m in der nächsten Nachricht an (z. B. implizit im Versionsparameter der Nachricht). - Für SET initiierte SUPL-Sitzungen trägt die ursprüngliche SUPL-Nachricht vom SET die unterstützte SUPL-Haupt- und Nebenversion M1.m1 (implizit im Versionsparameter). H-SLP setzt die Sitzung fort, wenn sie die gleiche Hauptversion M1 unterstützt und andernfalls ein SUPL-END sendet und die Sitzung beendet.
GNSS_SetNMEALogging Mit diesem Befehl wird der Status für die NMEA-Protokollierung festgelegt. Dieser Befehl bewirkt, dass der GNSS-Treiber die Datenkorrekturinformationen über NMEA-Zeichenfolgen startet/beendet. Der GNSS-Treiber muss weiterhin Korrekturen in der GNSS_FIXDATA Struktur bereitstellen. Der Parameter ist ein DWORD- mit den folgenden Werten: - GNSS_NMEALOGGING_NONE (0x00) - GNSS_NMEALOGGING_ALL (0xFF) Der Standardwert für diesen Befehl ist keine NMEA-Protokollierung (GNSS_NMEALOGGING_NONE). Dieser Befehl sollte nicht über den Systemneustart hinweg beibehalten werden. Dieser Befehl wurde eingeführt, um OEM-Tests zu unterstützen. Dieser Befehl wird nicht vom Standortframework oder von Microsoft-Testtools verwendet.
GNSS_SetUplServerAccessInterval Mit diesem Befehl wird die Mindestzeit zwischen Anforderungen an den Server festgelegt, um eine Dienstüberladung zu verhindern. Das Zeitintervall wird in Sekunden angegeben. Mobilfunkanbieter können diesen Konfigurationsdienstanbieter verwenden, um diese Einstellung zu optimieren, falls sie sie benötigen. Wenn dieser Parameter nicht unterstützt wird, wenn er ignoriert werden kann, aber die SUPL-Konfigurationsbefehle dürfen nicht fehlschlagen.
GNSS_SetNiTimeoutInterval Mit diesem Befehl wird festgelegt, wie viel Zeit das Gerät auf die Eingabe eines Benutzers warten muss, bevor es auf die NI-Anforderung reagiert, die die Standardaktion ausführt. Das Zeitintervall wird in Sekunden angegeben und der Standardwert beträgt 35 Sekunden. Dieses Timeout ist 5 Sekunden größer als das timeout, das vom Betriebssystem verwendet wird, um auf die Antwort des Benutzers zu warten, und es ist einfach ein fehlersicherer Fall, wenn das Betriebssystem nicht reagiert. Dieser Befehl gilt nur für vom Netzwerk initiierte Anforderungen, in denen die Überprüfung des Benutzers angefordert wird. Mobilfunkanbieter können den Konfigurationsdienstanbieter verwenden, um den Standardwert vom Betriebssystem außer Kraft zu setzen. In diesem Fall sollten die oben angegebenen Standardwerte durch die vom Mobilfunkanbieter bereitgestellten Werte ersetzt werden.
GNSS_ResetGeofencesTracking Mit diesem Befehl wird der Geofence-Tracking-Vorgang zurückgesetzt. Der GNSS-Treiber muss alle Geofence-Elemente aus dem GNSS-Modul löschen, die Geofence-Überwachung beenden und die Überwachung für Signalbedingungen beenden. Der Geofence-Tracking-Vorgang beginnt wie gewohnt nur, wenn der HLOS einen oder mehrere neue Geofences erstellt.
GNSS_SetSuplVersion2 Mit diesem Befehl wird die SUPL 2-Version für den GNSS-Treiber festgelegt.
GNSS_CustomCommand Bereich für benutzerdefinierte IHV-spezifische GNSS-Befehle: 0x0100 – 0x01FF.

Anforderungen

Anforderung	Wert
Header-	gnssdriver.h