---
title: 'Fury FLX1: GPS und Standortbestimmungen reparieren'
url: 'https://wedema.de/de/wissen/problemloesungen/fury-flx1-gps-standort'
markdown: 'https://wedema.de/de/wissen/problemloesungen/fury-flx1-gps-standort.md'
lang: de
date: '2026-10-06'
description: '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 da…'
taxonomy:
  category:
    - Problemloesung
  tag:
    - FuriOS
    - 'Fury FLX1'
    - Fury
    - GPS
    - GNSS
    - GeoClue
    - MediaTek
    - Linux
  device:
    - 'Fury FLX1'
---

# Fury FLX1: GPS und Standortbestimmung wiederherstellen

Beim Fury FLX1 funktionierte die Standortbestimmung nicht mehr zuverlässig. Die Anwendung [DrivePulse](https://github.com/misc-de/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.

```bash
gsettings get org.gnome.system.location enabled
```

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

```bash
gsettings set org.gnome.system.location enabled true
```

und anschließend GeaoClue neu starten.

```bash
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:

```bash
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äß:

```bash
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.

---

## Navigation

- Parent: [Problemlösungen](https://wedema.de/de/wissen/problemloesungen.md)
- Next: [Microsoft Surface Go 2 – Hardwarezustand prüfen](https://wedema.de/de/wissen/problemloesungen/microsoft-surface-go-2-hardwarezustand-pruefen.md)