Fury FLX1: GPS und Standortbestimmung wiederherstellen

Beim Fury FLX1 funktionierte die Standortbestimmung nicht mehr zuverlässig. Die Anwendung DrivePulse erhielt keine echte GPS-Position, sondern zeigte über längere Zeit einen falschen Standort in München an.

Nach einiger Fehlersuche ließ sich das Problem beheben. Besonders interessant war dabei, dass mehrere zunächst verdächtige Komponenten letztlich nicht die eigentliche Ursache waren.

Ausgangslage

Das Fury FLX1 lief mit FuriOS. WLAN war aktiv, die SIM-Karte dagegen inaktiv. Andromeda beziehungsweise Waydroid war während der Fehlersuche ausgeschaltet.

Das auffälligste Symptom:

  • DrivePulse meldete als Standort München
  • der tatsächliche Standort wurde nicht ermittelt
  • ein normaler GPS-Fix schien nicht zustande zu kommen

Zunächst war unklar, ob das Problem bei

  • GeoClue,
  • der Berechtigung der Anwendung,
  • der MediaTek-GNSS-Hardware,
  • A-GNSS,
  • oder den gespeicherten GPS-Hilfsdaten

lag.

GeoClue prüfen

Zunächst wurde kontrolliert, ob die systemweite Standortfunktion aktiviert ist.

gsettings get org.gnome.system.location enabled

Die Standortfunktion muss aktiviert sein, also auf true stehen. Wenn das nicht der Fall ist :

gsettings set org.gnome.system.location enabled true

und anschließend GeaoClue neu starten.

sudo systemctl restart geoclue.service

Während der Untersuchung zeigte sich zeitweise, dass GeoClue den Zugriff einer Anwendung beziehungsweise einer UID blockierte. Nach der Korrektur dieses Problems konnte DrivePulse GeoClue erreichen. Das allein reichte jedoch noch nicht für einen GPS-Fix.

GNSS-Hardware prüfen

Als nächstes musste geklärt werden, ob der eigentliche GPS-Hardwarepfad noch arbeitet. Dabei waren unter anderem die MediaTek-GNSS-Komponenten aktiv und die GPS-Interrupts nahmen während der Nutzung deutlich zu. Beobachtet wurden unter anderem: gps_da0 gps_nd0 gps_dma Außerdem waren GPS-Geräte beziehungsweise Schnittstellen wie /dev/gps_emi gpsdl0 gpsdl1 und die zugehörigen A-GPS-Sockets vorhanden. Damit ließ sich ein grundsätzlicher Defekt des GNSS-Hardwarepfades weitgehend ausschließen.

MediaTek-GNSS-Daten

Interessant wurde anschließend das Verzeichnis: /data/vendor/gps/ Dort liegen verschiedene vom MediaTek-GNSS-Stack verwendete Daten:

EPO.DAT QEPO*.DAT MTKNAV.DAT mtkgps.dat cache.dat

Während der Fehlersuche wurden diese Dateien beziehungsweise Teile davon neu erzeugt oder aktualisiert. Zur Beobachtung eignet sich beispielsweise:

while true; do
    date
    sudo ls -lah /data/vendor/gps/
    sleep 2
done

Dabei war zu erkennen, dass der GNSS-Stack tatsächlich auf die Dateien zugriff und neue beziehungsweise aktualisierte Daten schrieb.

Ein interessanter, aber erfolgloser Versuch

Testweise wurde außerdem `/data/vendor/gps/silentGnssLogging' angelegt. Sinngemäß:

sudo touch /data/vendor/gps/silentGnssLogging
sudo chown 1021:1021 /data/vendor/gps/silentGnssLogging
sudo chmod 660 /data/vendor/gps/silentGnssLogging

Die Datei überstand auch einen Neustart. Das erwartete zusätzliche GPS-Logging wurde dadurch allerdings nicht erzeugt. Es entstand insbesondere kein brauchbares gpsdebug.log. Dieser Schritt war daher für die Diagnose interessant, war aber nicht die Lösung des Problems.

A-GNSS und die inaktive SIM

In den Logs tauchten außerdem Fehler im Zusammenhang mit oFono beziehungsweise der nicht aktiven SIM-Karte auf. Das kann A-GNSS und damit einen schnelleren GPS-Fix beeinträchtigen. Es erklärt jedoch nicht vollständig, warum überhaupt keine normale Satellitenposition zustande kommen sollte. Ein GNSS-Empfänger muss grundsätzlich auch ohne Mobilfunkverbindung eine Position bestimmen können. Die fehlende Mobilfunkverbindung wurde deshalb nicht als eigentliche Ursache angesehen.

Was schließlich zum Erfolg führte

Im Verlauf der Arbeiten wurden die MediaTek-GNSS-Komponenten neu initialisiert und die GPS-Hilfs- und Navigationsdaten unter /data/vendor/gps/ neu beziehungsweise aktuell erzeugt.

Danach änderte sich das Verhalten deutlich: DrivePulse zeigte nicht mehr den bisherigen Standort München an, sondern erstmals den tatsächlichen Standort. Ein anschließender Neustart des Fury FLX1 war besonders wichtig für die Kontrolle: Auch danach funktionierte GPS weiterhin korrekt. Damit war klar, dass es sich nicht nur um einen kurzfristigen Effekt innerhalb der laufenden Sitzung handelte. Ergebnis Nach der Reparatur:

  • wird der tatsächliche Standort wieder ermittelt
  • DrivePulse erhält eine korrekte Position
  • der GNSS-Hardwarepfad arbeitet
  • GeoClue kann auf die Standortdaten zugreifen
  • die Funktion bleibt auch nach einem Neustart erhalten Fazit Der Fall war etwas ungewöhnlich, weil mehrere Ebenen der Standortbestimmung gleichzeitig untersucht werden mussten. Besonders hilfreich war die Trennung in:
    1. Anwendung und GeoClue
    2. Berechtigungen
    3. MediaTek-GNSS-Dienste
    4. Hardware und Interrupts
    5. gespeicherte EPO-, QEPO- und Navigationsdaten Ein einzelner eindeutig reproduzierbarer Konfigurationsschalter ließ sich am Ende nicht als alleinige Ursache identifizieren. Der entscheidende Zustand entstand nach der Neuinitialisierung des MediaTek-GNSS-Stacks und der Aktualisierung beziehungsweise Neuerzeugung der GNSS-Daten. Dass die Funktion anschließend auch einen kompletten Neustart überstand, bestätigte den Erfolg.