[CM11] GPS-Fix beschleunigen

  • 18 Antworten
  • Letztes Antwortdatum
D

dmasu

Fortgeschrittenes Mitglied
89
Ich möchte Euch gerne noch mal das get-gps-lto script aus dem ooo's-Anleitung AF-Wall+ eingerichtet habe, sind mir dort die a-GPS Anfragen an den SUPL.google.com Server aufgefallen und ich habe mich noch mal mit dem Thema auseinandergesetzt. Dabei bin ich auch darauf gestossen, dass Google die a-GPS-Anfragen zum Tracking nutzen kann:

GPS-Funktion allgemein

Eigentlich kann das GPS im Defy komplett autonom betrieben werden. Die GPS-Satelliten senden alle notwendigen Informationen zur Positionsbestimmung von sich aus. Dies geschieht mit einer Navigationsnachricht (aktuelle Position des Satellitens, GPS-Zeit, Detailierung seiner Umlaufbahndaten (Ephermis)) von 30sec Länge. Zusätzlich sendet jeder Satellit auch den sogenannten Almanach, die groben Umlaufbahndaten aller GPS-Satelliten, der ebenfalls notwendig zur Positionsbestimmung ist. Dies dauert allerdings 12,5min und bestimmt damit die Zeit zum ersten Fix (time to first fix - TTFF). Dieser sogenannte Factory Start dauert nach Herstellerangaben im Mittel 15min.

Nach der ersten Positionbestimmung werden der Almanach, die Postitonsdaten usw. vom GPS in LEARN_STORE.BIN und gpsdata.nvs unter /data/location gespeichert und stehen für die nächsten Positionsbestimmungen zur Verfügung. Allerdings sind die Bahndaten nur für einen begrenzten Zeitraum aktuell und je länger der letzte Fix her ist, desto mehr Daten müssen von den Satelliten nachgeladen werden. Man unterscheidet dann:

Hot Start - TTFF ca. 5sec
Warm Start - TTFF ca. 35sec
Cold Start - TTFF ca. 45sec

Beim Letzteren sind nur noch die Almanach Daten aktuell und es müssen vollständige Navigationsnachrichten von den Satelliten empfangen werden. Dies ist gewöhnlich der Fall, wenn die Positon um mehr als 100km geändert oder seit dem letztem Fix mehr als 4h vergangen sind. Die angegebenen Werte sind Mittelwerte. Befindet man sich in einer schlechten Empfangsposition (Wolken, Abschattung durch Gebäude) verlängern sich die Zeiten, z.T. erheblich.

Hilfsdaten für das GPS

Im nicht-autonomen Betrieb können wir die Positonbestimmung durch Beistellung von Hilfsdaten beschleunigen. Wir haben die Möglichkeit, a-GPS Anfragen unter Einstellungen-Standort mit der Wahl des Modus "Hohe Genauigkeit" zu erlauben. Oder wie im Wiki beschrieben, die LTO-Datei herunterzuladen.

Bei a-GPS wird bei einer Standortanfrage (unter zur Hilfenahme einer Grobpositionbestimmung mittels Funkzellen) von einem Internetserver der Almanach und detailiertere Bahndaten der in unserem Bereich befindlichen Satelliten abgefragt (SUPL-Anfrage). Das dauert wenige Sekunden und verkürzt die Positionsbestimmung auf die Zeit eines Warm Starts. Um die Vorteile geniessen zu können, müssen wir also entweder mobile Daten aktiviert haben (was ich nie wollte) oder vorrausschauend die a-GPS-Daten über W-LAN herunterladen. Ich habe das bisher so gemacht. Und weil ich nicht wusste, dass das unsere ROM auch von selber macht, dazu immer GPS-Status verwendet.

Die andere Möglichkeit ist die LTO-Datei herunterzuladen. Darin sind die Almanach-Daten enthalten und so verkürzt sich die Positionsbestimmung auf die eines Cold Starts. Nachteilig daran ist also nur, dass ich beim ersten Fix ca. 15sec länger warten muss als mit a-GPS-Daten. Für anschliessende Positionabfragen stehen in beiden Fällen die gespeicherten Daten aus LEARN_STORE.BIN und gpsdata.nvs zur Verfügung. Ich habe zudem das script aus dem Wiki unter zu Hilfenahme des Original-XDA-Threads an den Download der 30 Tage Version angepasst. Jetzt werde ich einmal im Monat die LTO-Datei herunter laden, anstatt das ich immer im Vorraus einmal im WLAN eine Standortabfrage machen muss.

Vor- und Nachteile a-GPS und LTO.dat

Ihr habt aber sowieso eine Datenflat? Dann ist das nur ein Problem für Euch im Ausland mit teuren Roaming Gebühren oder in abgelegenen Gebieten ohne Netz. In diesem Link findet sich aber noch ein wirklich guter Grund, die a-GPS-Abfrage unter Standort-Modus-Nur Gerät abzuschalten. Kurz zusammengefasst gehen die a-GPS-Anfragen an einen Google-Server und obwohl die Daten anonym und verschlüsselt sein sollten, werden die SIM-Card ID übertragen ohne das SSL-Certificate richtig anzuwenden. Zusammen mit der Grobpositionsbestimmung aus der Anfrage sehen paranoide Naturen darin eine hervorragende Möglichkeit für das sogenannte Tracking.

Ihr könnt den LTO-Download auch per Script automatisieren - Starbright hat die Idee im Dezember hier schon vorgestellt. :thumbup:
 
Zuletzt bearbeitet:
  • Danke
Reaktionen: hook69, Pizzapeter, Netbook und 8 andere
dmasu schrieb:
[...]Ihr könnt den LTO-Download auch per Script automatisieren - linolino scharrt schon mit den Hufen und starbright hat die Idee im Dezember hier schon vorgestellt.[...]

Sehr schöne, verständliche und detaillierte Beschreibung zum GPS von @dmasu.


Meine Ergänzung zur Automatisierung lto.dat:

ACHTUNG: Bitte für das Folgende nur die eigene, originale init.mapphone_umts.rc verwenden; meine ist z. B. aus der ramdisk der Nightly@2015-01-28

init.mapphone_umts.rc

in ca. Zeile 377 ergänzen mit (also folgende Zeilen dort einfügen)

Code:
# Manual download of long term orbit data
service gpslto /system/bin/logwrapper /system/bin/get-gps-lto
    oneshot
    disabled

on property:init.svc.p2p_supplicant=running
   start gpslto
Zusätzlich zur Änderung die Script-Datei get-gps-lto dann nach /system/bin/ kopieren und ausführbar machen (-rwxr-xr-x bzw. 755 - root:shell für owner:group setzen).

Neu starten.


Was bewirkt das jetzt?

Bei jedem Einschalten des W-LANs wird dadurch die lto.dat-Datei

  • entweder das erste Mal geholt (wenn nicht vorhanden)
  • oder, wenn veraltet, aktualisiert
  • oder, wenn noch nicht veraltet, gar nichts unternommen

Bei mir funktioniert das wunderbar (auch ohne Google Apps) und A-GPS/SUPL.
Ich benutze damit Nokias Here Maps (offline!), Öffi (AOSP-Version, ohne Google Maps) und zum Testen ab und zu GPS Status.

Tipps:
AFWall+ Firewall kann beim Starten des Phones nach der Aktivierung der W-LAN-Schnittstelle den Verkehr erstmal blockieren. - Dann kann das Script die lto.dat nicht holen. - Wenn die Firewall sich als aktiv meldet und man dann einmalig das W-LAN aus und wieder einschaltet, geht das aber wieder ohne Problem. - AFWall+ muss natürlich "0: root" in das Internet lassen (Das Script läuft als root user).

Manuell durch den Aufruf von get-gps-lto im Android Terminal kann man jederzeit testen bzw. überprüfen. - Die lto.dat-Datei kann auch erst gelöscht werden, um zu sehen, ob der Download funktioniert beim Einschalten des W-LANs. - Im CM Filemanager das Verzeichnis dann über das Menü aktualisieren.

Im Anhang zur Orientierung noch die komplette init.mapphone_umts.rc (als .txt.-Datei, wegen nicht erlaubter Dateierweiterung ".rc" der Upload-Funktion im Forum):
 

Anhänge

  • 2015-02-09@08-19-47.png
    2015-02-09@08-19-47.png
    19 KB · Aufrufe: 877
  • init.mapphone_umts.rc.txt
    14,6 KB · Aufrufe: 615
Zuletzt bearbeitet:
  • Danke
Reaktionen: hook69, dmasu, fairdroid und 2 andere
Wer keinen Linux-Rechner hat oder es gerne bequem haben möchte, kann sich seine ramdisk direkt auf dem Phone patchen, um in den Genuss der automatischen Aktualisierung der GPS/LTO-Daten für besseres GPS zu kommen.

Ablauf:

  • Die hier angehängte Datei auf die SD Card kopieren (evtl. in satfix o. ä. umbenennen = kürzer beim Tippen)
  • Dann Android Terminal Emulator öffnen
  • Folgende Befehle im Terminal eingeben
Code:
su
. /sdcard/ooo-gps-lto-patch.txt
reboot
WICHTIG: Zwischen dem Punkt und dem ersten Schrägstrich in der zweiten Befehlszeile ist ein Leerzeichen!

Tipps:

  • Das kann man bei jeder aktuellen Nightly machen, wenn man möchte.
  • Bei jedem (OTA-)Update auf eine neuere Nightly ist das zu wiederholen, da die ramdisk wieder die originale ist.
  • Man kann die angehängte Datei auch einmalig vor dem Einsatz in etwas Kürzeres umbenennen (z. B. gps oder satfix - seien Sie kreativ ...)
  • Der Patch benutzt aktuell die 30-Tage-Version. - Das kann man aber im Code der Datei auf die 7-Tage-Version ändern, wenn man möchte (Bitte dazu Notepad++ auf einem Windows-Rechner benutzen oder die Datei direkt auf dem Phone ändern.)
  • Bei mir geht (nach dem ersten Fix) der Sat-Fix schneller, wenn ich Einstellungen > Standort > Modus > Nur Gerät aktiviert lasse (10 - 35 sec).

Viel Spass und wie immer: bitte an das Backup denken ...
_
 

Anhänge

  • ooo-gps-lto-patch.txt
    4,7 KB · Aufrufe: 749
Zuletzt bearbeitet:
  • Danke
Reaktionen: ami8i, hook69, Pizzapeter und 9 andere
@ooo: Dein Patch ist Klasse. Ich hätte gerne noch ein paar mal Danke gedrückt :thumbsup:

@Cua: Vielleicht könntest Du den Patch dem WIKI-Artikel hinzufügen?
Bei mir ist die gpsconfig.xml übrigens ein wenig anders:
Code:
- lto_dat_file=/data/location/lto.dat
+ acLtoDir="/data/location/"
+ ltoFileName="lto.dat"
Tippfehler oder beides möglich?
 
  • Danke
Reaktionen: ooo
@dmasu - Merci, aber starbright hat es ja eigentlich im Dezember ausgelöst/angeschoben.

Wegen Aufnahme im Wiki:

Fight4Music hat bereits einen Link auf diesen Thread im Startposting unter dem Spoiler zu
"Probleme/Bugs/ToDo/weitere nützliche Thread"
im "CM11 KK 4.4.4 - Defy+ "Thread gesetzt.

@Cua
Allerdings ist die Info im Wiki damit nicht auffindbar (für Leute, die direkt ins Wiki springen).
Wie wäre es? - Einfach noch einen Link auf diesen Thread im Problemwiki-Posting setzen?
Vllt. weiter oben im Text, damit das Aktuellere zuerst gelesen wird?
Merci.
 
Zuletzt bearbeitet:
dmasu schrieb:
@ooo: Dein Patch ist Klasse. Ich hätte gerne noch ein paar mal Danke gedrückt :thumbsup:

Ja, unbedingte Zustimmung! Erster Fix zw. 6 und 20s (draussen /drinnen), das ist wirklich super, insbesondere, da ich GPS nur sehr selten mal einschalte, meine LTO-Daten also immer völlig veraltet sind und der erste Fix dann teilweise minutenlang dauert. Und die Anleitung ist so genau und gut, die kann wirklich jeder befolgen.

Mal ne Frage: soweit ich das verstanden habe, wird die Aktualisierung nur vorgenommen, wenn man sich im WLAN befindet.

a) wie groß ist die Datei, die da runtergezogen wird, wäre das eine große Belastung des Datenverbrauchs unter 2G/3G?

b) findet die Aktualisierung der Daten nach >5 Tagen (habe ich so eingestellt) immer statt, auch wenn GPS gar nicht eingeschaltet und von keiner App angefordert wird? Jeweils beim Booten - oder welcher Event prüft das?
 
Netbook schrieb:
Mal ne Frage: soweit ich das verstanden habe, wird die Aktualisierung nur vorgenommen, wenn man sich im WLAN befindet.
Ja, hast Du richtig verstanden.
Netbook schrieb:
a) wie groß ist die Datei, die da runtergezogen wird, wäre das eine große Belastung des Datenverbrauchs unter 2G/3G?

Die 30 Tage Datei lto2.dat hat bei mir 182kB, die 7 Tage Datei hat, glaube ich, irgendwas um die 70kB. Ich wollte Sie gerade nochmal runterladen, um das zu überprüfen, aber der Server hängt anscheinend (wahrscheinlich haben jetzt alle Trizillionen Defy-Besitzer das Script am Laufen ;-)). Im Original-XDA-Thread sind die Download-Links für den manuellen Download direkt verlinkt, da kannst Du es nochmal überprüfen, um den Datenverbrauch für Dich abzuschätzen.

Netbook schrieb:
b) findet die Aktualisierung der Daten nach >5 Tagen (habe ich so eingestellt) immer statt, auch wenn GPS gar nicht eingeschaltet und von keiner App angefordert wird? Jeweils beim Booten - oder welcher Event prüft das?

Der Download wird durch die Initialisierung der WLAN-Verbindung ausgelöst, unabhängig ob Standort aktiviert ist oder überhaupt eine App diesen abfragt. Das ist einer der Vorteile gegenüber a-GPS.
Code:
on property:init.svc.p2p_supplicant=running    
start gpslto
Es wird also nie ausgelöst, wenn Du WLAN immer an hast und Dein Defy auch nie ausschaltest ;-) (Siehe auch "Tipps:" von ooo im zweiten Post des Threads.)
Aber gute Frage an @ooo:
Wenn Du WLAN immer an hast, Dich aber aus dem Empfangsbereich heraus und wieder herein bewegst, wird dann das script bei Neu-Verbindung ausgelöst oder muss ich immer aktiv WLAN de- und aktivieren?

Edit:
Wenn Du mit mobilen Daten sparen willst, muss Du das get-gps-lto script auf die komprimierte 7 Tage Version (lto2.dat) umschreiben, folgender Link:
http://gllto.glpals.com/7day/v2/latest/lto2.dat
Laut starbright im Original-XDA-Script ist die Datei nur 39kB statt 65kB. Du kannst das get-gps-lto Script, also den lto-download, ja auch jederzeit selbst und unabhängig von Deiner Internetverbindung per Terminal Emulator auslösen.
 
Zuletzt bearbeitet:
Man muss scheinbar das W-LAN deaktivieren und dann wieder aktivieren.

Meine Beobachtung dazu:

Wenn ich W-LAN aktiviert habe und mit dem Gateway (also z. B. AP oder Router) verbunden bin, dann das Gateway (nicht das W-LAN des Phones) ausschalte (Simulation "Ich bewege mich aus dem Empfangsbereich heraus"), "merkt" das Phone das bei mir nach ca. 200 Sekunden (Puffer-Zeit für kurzfristige Störungen) und schaltet von sich aus die W-LAN-Verbindung ab (W-LAN-Symbol verschwindet aus der Notification Bar).

Schalte ich das Gateway danach wieder ein, dann dauert es nur wenige Sekunden, bis das Phone das merkt und sich wieder einbucht.

Allerdings wird in diesem Szenario der Service gpslto NICHT getriggert. - Warum das so ist, habe ich bis jetzt nicht herausgefunden (aber auch nicht gerade extra danach "gesucht" ...). - Interessant wäre in diesem Zustand der Wert der Property init.svc.p2p_supplicant ("running" oder "stopped"). - Evtl. bleibt er auf "running" und die Schnittstelle fällt nur in so eine Art Stromspar-/Suspend-Modus?

Wird im Phone dann in diesem (wieder verbundenen/aktiven) Zustand das W-LAN manuell ausgeschaltet und dann wieder eingeschaltet, wird der Service gpslto kurze Zeit später getriggert, wie erwartet.

Der Service gpslto führt dann die Datei /system/bin/get-gps-lto aus, die sich wiederum die lokale Datei /data/location/lto.dat anschaut:

  • Entweder Ergebnis 1:
    Datei ist nicht vorhanden (noch nie da gewesen, manuell im CM Filemanager gelöscht worden)?
    => Aktion: Ab ins Web und die neueste Datei holen
    _
  • Oder Ergebnis 2:
    Die Datei ist vorhanden UND das System-Datum minus dem Anlage-Datum der Datei ist größer als 28 (bzw. 5) Tage?
    => Aktion: Ab ins Web und die neueste Datei holen
    _
  • Oder Ergebnis 3:
    Die Datei ist vorhanden UND das System-Datum minus dem Anlage-Datum der Datei ist noch kleiner-gleich 28 (bzw. 5) Tage?
    _
    => Aktion: NICHT ins Web gehen, KEINE Datei holen, wieder "pennen" gehen
    _
    Also gibt es im letzten Fall während 28 (bzw. 5) Tagen überhaupt keinen Traffic, der evtl. bezahlt werden müsste. - Die Dateigrößen sind mit unter 200 kB (85 kB) pro Download absolut vernachlässigbar. Im W-LAN, sowieso. Die "Mobile Daten"-Schnittstelle wird ja überhaupt nicht benutzt. - Also würden bei der 5-Tage-Regel maximal 6 x 85 kB = ca. 0,5 MiB und bei der 28-Tage-Regel 0,2 MiB monatlich zusammenkommen, es sei denn, man ruft die get-gps-lto zusätzlich manuell in einer shell auf.
Wenn man die get-gps-lto als root im Terminal manuell ausführt, kann man durch die Meldungen in der Konsole sehr schön mitverfolgen, was da gerade passiert:

  • Ist die lto.dat Datei noch nicht alt genug, legt sich das Script gleich wieder schlafen und "sagt" das auch schön.
  • Wenn W-LAN aus ist (bzw. keine Internet-Verbindung besteht), dann erfolgt die nächsten 300 Sekunden alle 10 Sekunden (30 Mal) ein Versuch. - Danach ist wieder Sense, bis das W-LAN wieder eingeschaltet wird (Das sieht man dann aber nicht in der Konsole, weil das ja dann nicht dort wieder aufgerufen wurde, sondern über den Service-Trigger). - Auch das wird schön kommentiert mit Meldungen.
  • Ist das Internet da und die Datei zu alt, wird die Datei geholt - mit entsprechender Erfolgs-Meldung.
Wenn man das NICHT manuell macht, kann man das im logcat-Protokoll sehen, weil über den logwrapper die Meldungen dort dokumentiert werden (einfach im logcat nach "lto" suchen).

___
So Leute, jetzt muss ich nur noch einen zahlungskräftigen Verleger für mein Pamphlet hier finden. - Das wird vermutlich kein Bestseller, aber was soll's.
 
Zuletzt bearbeitet:
  • Danke
Reaktionen: dmasu
Danke für die prima Erläuterungen! Dann kann ich also ziemlich sicher sein, dass das bei mir immer funktioniert, denn ich nutze zum Stromsparen eine clevere App, die Wifi abschaltet bei ScreenOff und bei ScreenOn wieder einschaltet :)
 
ooo schrieb:
So Leute, jetzt muss ich nur noch einen zahlungskräftigen Verleger für mein Pamphlet hier finden. - Das wird vermutlich kein Bestseller, aber was soll's.

Du verdienst Dir hier leider nur ein Danke. Und erfreust uns mit detaillierter und verständlicher Erklärung in übersichtlichem Layout. Honigquast Lobpuddelei..:thumbsup:
 
Ich bin ganz gerührt (oder war's geschüttelt?) - Was tut man nicht alles, um arm und unbekannt zu bleiben (joke).

Ich habe gestern nochmal das Holen der lto.dat getestet:
W-LAN an: wird geholt
W-LAN an, Mobile Daten an: W-LAN holt sich die Datei - Android benutzt laut Standard immer W-LAN, wenn verfügbar
Nur Mobile Daten an: Datei wird nicht geholt

Anderes Thema, anderes technisches Detail:
Beobachtet wird ja die property init.svc.p2p_supplicant und deren Wert (running, stopped). - p2p ist aber nicht die wlan-Schnittstelle (wlan0), sondern die "Wifi Direct" Schnittstelle. Das ist etwas unsauber (Quarx/Motorola-Legacy-Code?), aber in der ROM ist keine explizite Property init.svc.wifi_supplicant, die man dafür verwenden könnte (Den Service dazu gibt es aber in der init...rc Datei). Da aber Wifi Direct (p2p) zusammen mit dem Abschalten des W-LANs (wlan0) gestoppt wird, erreichen wir das selbe Verhalten (indirekt).
 
  • Danke
Reaktionen: Netbook
Und warum nicht durch die von waydownsouth im Header des get-gps-lto-Scripts empfohlene WPA-Schnittstelle (init.svx.wpa_supplicant) triggern lassen?

Ich kann es natürlich ausprobieren, aber vielleicht hast Du Dir ja was dabei gedacht. Das erspart mir die Testerei...
 
Man sehe in der shell (Android Terminal) selbst nach:

Code:
su
getprop

#oder

su
getprop | grep -i init

#oder

su
getprop | grep -i supplicant
__
Erklärung:
Die von waydownsouth benutzte property existiert in unserer ROM nicht. - Der Mann hat das vor Jahren im Zusammenhang mit *seiner* damals aktuellen ROM geschrieben.
Mit den o. g. Kommandos findet man (alle) in unserer ROM existierenden Properties. - init.svc.wpa_supplicant ist NICHT da, kann also auch nicht ausgewertet/benutzt werden.
 
Zuletzt bearbeitet:
  • Danke
Reaktionen: Netbook und dmasu
@ooo: muss dir nochmal ein Lob aussprechen! Nach tagelanger nicht Nutzung (und GPS OFF): *indoor* der first fix mit 22s ist ein Superwert!
PS: GPS Status (früher: "Locus") braucht da gerne auch mal viele Minuten, GPS Test ist bei weitem das bessere Programm - jedenfalls bei mir.
 
Zuletzt bearbeitet:
Netbook schrieb:
PS: GPS Status (früher: "Locus") braucht da gerne auch mal viele Minuten, GPS Test ist bei weitem das bessere Programm - jedenfalls bei mir.

Hmm, es sollte eigentlich keinen Unterschied machen, mit welchem Programm das GPS verwendet wird. Das GPS ist eigentlich komplett selbstständig und die erwähnten Apps bieten nur eine Anzeige-Oberfläche. (Darum heißt das eine ja auch GPS Test.) Wenn alle Einstellungen gleich sind, sollte das Selbe bei raus kommen.

Sind die Einstellungen verschieden, gibt es natürlich Unterschiede. Wenn man unter Standort - Modus - Nur Gerät auswählt, stellt man nur die Geräte-interne SUPL-Anfrage für die a-GPS Daten ab. Mit den genannten Apps GPS Status und GPS Test kann man diese Abfrage aber auch unabhängig von dieser Einstellung durchführen (manuell oder automatisiert). @netbook: Hast Du das vielleicht bei GPS Test noch an? Dann wäre es kein Wunder, das er den Fix schneller macht.

Wenn man Pech hat, und die a-GPS-Anfrage durch Standort - Modus - Hohe Genauigkeit Geräte-intern einstellt und zeitgleich auch die Abfrage durch eine der Apps ausführen lässt, kann dieses "doppelgemoppel" sogar zu schlechterer Performance führen...

Ich finde aber auch die Durchführung eines aussagefähigen Tests für die GPS-Performance nicht einfach. Die Hilfsdaten zur Positionsbestimmung werden tatsächlich nicht nur in LEARN_STORE.BIN und gpsdata.nvs unter /data/location gespeichert, sondern auch in einem internen Speicher des GPS Moduls. Genau so wie die lto.dat. Ich weiß nicht, wie flüchtig der ist, d.h. ob ich für das komplette Zurücksetzen der Hilfsdaten nur die Dateien in /data/location löschen und Aus-Ein-Schalten muss. Mein Eindruck ist, dass das nicht ausreicht. Ich konnte nach der ersten Standortbestimmung mit lto.dat keinen factory start mit TTFF > 12,5 min mehr provozieren. Ist aber eh rein akademisches Interesse, wichtiger ist es auch für mich, dass der Fix fix geht ;-)

Wie ist das jetzt eigentlich bei den "neueren" Nightlies mit dem Standort ein/ausschalten in der Schnellzugriffsleiste und den Schnelleinstellungen? Ich kann in der 2309 nicht festlegen, zwischen welchen Modi er toggeln soll. Geht das bei Euch? Und ist das verlässlich oder buggy?
Nachdem ich jetzt in den Standort-Einstellungen den Modus Nur Gerät ausgewählt habe, dann aber bitte nicht in den Einstellungen, sondern über die Schnellzugriffsleiste den Standort ausgestellt habe, schaltet er nur noch zwischen Aus und An (Nur Gerät) um. Schalte ich den Standort aber in den Einstellungen wieder aus, toggelt er bei tippen aufs Standortsymbol in der Schnellzugriffsleiste/-einstellungen munter (und ziemlich wahllos) zwischen den Modi hin und her.:confused2:
 
  • Danke
Reaktionen: linolino
Alle haben recht :)

Wie teste ich?

Nur Gerät ohne "Hilfsmittel":
W-LAN aus, danach Flug-Modus an, GPS auf "Nur Gerät" und ausschalten, A-GPS-Daten mit (z. B.) GPS Status löschen, lto.dat löschen, evtl. andere Dateien in /data/location löschen.
Dann Reboot, GPS einschalten und eine (beliebige) GPS App öffnen.

Nur Gerät, vorher lto.dat geholt:
Vorbereitung wie oben, aber dann aktuelle lto.dat via Rechner downloaden und über USB auf das Phone schieben und nach /data/loction kopieren.
Dann Reboot, GPS einschalten und eine (beliebige) GPS App öffnen.

Die Ergebnisse (gleiche Randbedingungen, gleicher Ort, gleiche Zeit etc.) sind auch bei mir total unterschiedlich und nicht konsistent.

Dezidierte Apps, wie z. B. GPS Status (deaktiviertes A-GPS, Internet) sind bei mir *irgendwie* schneller beim TTFF, warum weiß ich nicht; vllt. schnellere/bessere Algorithmen für die Bewertung der vom GPS-Chip empfangenen Daten? - K. A. - Die Frage hier für mich lautet: Wer sagt dem System, dass ein Sat Fix existiert? - Der GPS-Chip oder die jeweilige App?
Fange ich mit z. B. Öffi an (immer: GPS > Nur Gerät), dauert es "ewig" (30-45 Minuten) oder es erfolgt kein First Fix, GPS-Status ist hier schneller.

Die lto.dat bringt aber auf jeden Fall etwas. - Evtl. bilde ich es mir nur ein, aber: die 30-Tage-Datei (v2-lto) sorgt m. M. n. für einen schnelleren Fix als die 7-Tage-Datei (andere, ältere Datenstruktur?).

Der GPS-Quick-Toggle im CM11-ROM war und ist (immer noch) buggy, wie von @dmasu beschrieben. - Ich benutze nur noch den Weg über die System-Einstellungen, um das GPS zu verwalten (okay, Ein/Aus scheint beim Toggle zu funktionieren, aber die Visualisierung des Symbols nicht und auch nicht der aktive Modus). - Ich hoffe, das bekommen die Progger noch in den Griff.
 
  • Danke
Reaktionen: linolino
Ich nutze "nur Gerät", da klappt der Toggle über die Schnell Start Leiste. Sonst völlig erratisch v wie oben beschrieben. Nachdem GPS Status nach 5 min unter freiem Himmel partout keinen Fix zeigen wollte, hat GPS Test binnen einiger Sekunden 5 Satelliten v gefunden. Danach gehen andere Apps problemlos :)
Edit: ooo hat recht, es IST erratisch - mal ist die eine, dann die andere APP schneller.
 
Zuletzt bearbeitet:

Ähnliche Themen

K
  • kschroeder
Antworten
5
Aufrufe
1.794
ooo
O
J
Antworten
5
Aufrufe
2.380
jodu
J
D
  • Defy+ User
Antworten
9
Aufrufe
2.387
Defy+ User
D
Zurück
Oben Unten