GPS-Erfassung optimieren: Early-Exit statt 30s stur warten #8

New issue

Open

opened 2026-04-17 01:29:29 +02:00 by moritz · 0 comments

moritz commented

2026-04-17 01:29:29 +02:00

Owner

Problem

Aktuell wartet GpsService stur 30s und picht den Fix mit der besten Quality. Das ist suboptimal:

Der GPS-Chip hat intern einen Kalman-Filter, der alle Satellitendaten kontinuierlich fusioniert — jeder Position.getInfo()-Aufruf liefert den aktuellen, bereits gefilterten Fix
Sobald Quality.GOOD (4) erreicht ist, wird's durch weiteres Warten nicht mehr besser (kein höheres Enum verfügbar)
Der spätere Fix ist durch den Chip-Filter eh ≥ dem früheren → "best of"-Logik bringt wenig
Zum Vergleich: Handys brauchen nur 5s, weil sie A-GPS nutzen (Almanach/Ephemeriden via Mobilfunk statt 30-60s Satelliten-Download beim Cold-Start)

Gängige Praxis

Early-Exit bei Quality.GOOD — sobald erreicht, Fix speichern und abbrechen
30s als harter Timeout für Worst-Case
Nur letzten Fix verwenden statt "best of seen"

Zusätzliche Optimierungen (optional)

GPS vor App-Start aktivieren: Position.enableLocationEvents schon in AppBase.onStart() starten, damit der Chip Zeit zum Aufwärmen hat bevor der User ein Ereignis triggert. Vorteil: gefühlt sofortiger Fix. Nachteil: höherer Akkuverbrauch.
Last-Known-Fix als Vorab-Wert: sofort Vorab-Koordinaten zeigen (grau), dann auf besseren Fix warten
EPO-Daten: fr265 synct EPO-Daten automatisch via Garmin Connect (Bluetooth) — nichts zu tun auf App-Ebene, aber User sollte Handy gekoppelt haben

Kontext

Verwandt mit #5 (GPS-Dauer einstellbar) und #11 (Genauigkeit anzeigen + manueller Stop). Wenn dieses Issue umgesetzt ist, wird #5 weniger relevant (Early-Exit ersetzt in vielen Fällen die manuelle Dauer-Einstellung).

Imported from GitHub #14

## Problem Aktuell wartet `GpsService` stur 30s und picht den Fix mit der besten `Quality`. Das ist suboptimal: 1. Der GPS-Chip hat intern einen Kalman-Filter, der alle Satellitendaten kontinuierlich fusioniert — jeder `Position.getInfo()`-Aufruf liefert den aktuellen, bereits gefilterten Fix 2. Sobald `Quality.GOOD` (4) erreicht ist, wird's durch weiteres Warten **nicht mehr besser** (kein höheres Enum verfügbar) 3. Der spätere Fix ist durch den Chip-Filter eh ≥ dem früheren → "best of"-Logik bringt wenig 4. Zum Vergleich: Handys brauchen nur 5s, weil sie A-GPS nutzen (Almanach/Ephemeriden via Mobilfunk statt 30-60s Satelliten-Download beim Cold-Start) ## Gängige Praxis 1. **Early-Exit bei `Quality.GOOD`** — sobald erreicht, Fix speichern und abbrechen 2. **30s als harter Timeout** für Worst-Case 3. **Nur letzten Fix verwenden** statt "best of seen" ## Zusätzliche Optimierungen (optional) - **GPS vor App-Start aktivieren**: `Position.enableLocationEvents` schon in `AppBase.onStart()` starten, damit der Chip Zeit zum Aufwärmen hat bevor der User ein Ereignis triggert. Vorteil: gefühlt sofortiger Fix. Nachteil: höherer Akkuverbrauch. - **Last-Known-Fix als Vorab-Wert**: sofort Vorab-Koordinaten zeigen (grau), dann auf besseren Fix warten - **EPO-Daten**: fr265 synct EPO-Daten automatisch via Garmin Connect (Bluetooth) — nichts zu tun auf App-Ebene, aber User sollte Handy gekoppelt haben ## Kontext Verwandt mit #5 (GPS-Dauer einstellbar) und #11 (Genauigkeit anzeigen + manueller Stop). Wenn dieses Issue umgesetzt ist, wird #5 weniger relevant (Early-Exit ersetzt in vielen Fällen die manuelle Dauer-Einstellung). --- *Imported from [GitHub #14](https://github.com/EiSiMo/Einsatzprotokoll/issues/14)*

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: moritz/einsatzprotokoll#8

No description provided.

Rows
Columns