V 2.5.4

Allgemeine Diskussionen zum GNSS Commander
PilaBlu
Site Admin
Beiträge: 94
Registriert: 21.08.2017, 16:28
Wohnort: Stuttgart
Kontaktdaten:

Re: V 2.5.4

Beitrag von PilaBlu » 12.11.2017, 12:13

Hallo Wolfgang,
zuerst die benutzten und dann die nichtbenutzten
Yep - stimmt! Die Sortierung mache ich in meiner Library nach dem Auswerten der GSV/GSA Strings.
Bei "intern" werte ich aber NMEA nicht mehr aus, sondern greife eben direkt auf die Android API zu.
Die Sortierung ist also so wie von Android vorgegeben - könnte ich aber ändern...
in der Statusseite wird nur die Summe der benutzten GPS Sats angezeigt
Der Wert kommt aus dem GGA - hier greife ich wieder auf die NMEA Daten zu.
Nur den GSV/GSA und GST hole ich nicht mehr über NMEA sondern aus der API!
PRN 33 und 40 SBS aufgeführt, in der Skyansicht ist aber kein grüner Kreis zu sehen
Du hast Android Version kleiner/gleich Marshmallow im Einsatz - oder?
Ich frage nur weil es die korrekte Sat-System Zuordnung unter Android erst aber der V7 gibt!
Bis V7 liefert die API nur PRNs und keine SatSysteme, d.h. ich bestimme im Code dann einfach
anhand der PRN das Sat-System. Das könnte durchaus fehlerhaft sein.
PRNs 1-32 => GPS / 33-64 => SBAS (das muss aber nicht richtig sein!)
Ich glaube die "GPS-Status" App gibt hier immer GPS als System an. (1-64)

Gruß
Markus
C macht es einfach, sich selbst ins Bein zu schießen; C++ erschwert es, aber wenn es Dir gelingt, bläst es Dir das ganze Bein weg! [Bjarne Stroustrup]

wugi
Beiträge: 52
Registriert: 21.08.2017, 20:56

Re: V 2.5.4

Beitrag von wugi » 12.11.2017, 12:46

Hallo Markus,
danke für deine Antwort :)
Du hast Android Version kleiner/gleich Marshmallow im Einsatz - oder?
richtig MM 6.01
Gruß Wolfgang

gnssfan
Beiträge: 16
Registriert: 24.10.2017, 17:50

Re: V 2.5.4

Beitrag von gnssfan » 13.11.2017, 15:22

Hallo Markus,
Unter anderem wird alle 5 Sekunden der Heap-Speicherverbrauch geloggt.
Der Heap ist m.E. unauffällig.
[0000::Logger.] [dumpHeap()] usedMem:6MB maxHeap:128MB availHeap:122MB
[0000::Logger.] [dumpHeap()] usedMem:5MB maxHeap:128MB availHeap:123MB
usw. usedMem geht auch mal auf 8-9MB hoch und dann wieder zurück auf 5-6MB wie es bei funktionierender Speicherverwaltung sein sollte.
Ich hatte das auch mit System Monitor verfolgt und alles unauffällig mit sehr niedriger Auslastung und viel verfügbarem RAM und Speicher. Vollzulaufen scheint da nichts.

Ich habe es noch etwas genauer beobachtet und es wirkt wie ein Problem mit dem Setzen der Location und gleichzeitigen Zugriff anderer Apps.
- Wenn soweit möglich alle Apps mit Location Zugriff gestoppt sind dauert es länger bis zum Crash . Alle Zugriffe wie ein Google Play Store etc. krieg ich nicht unterbunden und vielleicht kollidiert es da
- Wird Maps gestartet endet es häufig mit einem sofortigen Android Neustart.
Mal so ins Blaue spekuliert.
Kann es sein, dass die Location nicht atomar gesetzt wird und es zu sowas wie einem Null-Pointer etc. kommt?
Gibt es da alternative Methoden die Location zu setzen?

Falls das noch was aussagt: Es wird nur das Android System neu gestartet. Die Kernelprozesse bleiben bestehen, also kein kompletter Neustart.

Viele Grüße,
Martin

PilaBlu
Site Admin
Beiträge: 94
Registriert: 21.08.2017, 16:28
Wohnort: Stuttgart
Kontaktdaten:

Re: V 2.5.4

Beitrag von PilaBlu » 13.11.2017, 18:16

Hi Martin,

bei deinen Heap-Werten sollte da in der Tat nix anbrennen.
Kann es sein, dass die Location nicht atomar gesetzt wird und es zu sowas wie einem Null-Pointer etc. kommt?
Die Location-Manager Klasse bietet die Methode setTestProviderLocation() um eine Mock-Position zu setzen.
In dieser Methode wird die Position wiederum an den entsprechenden Service weitergeleitet. (GPS und/oder Network)
Dass es da drin zu einem Null-Pointer Zugriff kommt ist nicht unmöglich aber schon ziemlich unwahrscheinlich.
Gibt es da alternative Methoden die Location zu setzen?
Nein - unter Android gibts nur die gerade beschriebene Funktion für Mocking.

Was ist nochmal der genaue Unterschied zur funktionierenden Variante?
Anderes Handy + andere OS Version oder? Und "nur" bei externem GNSS Empfänger?
Wenn du nur mal so zum Test die Simulation laufen lässt dann schepperts nicht?
VIELE Fragen ... :mrgreen:

Noch eine letzte: Wie oft kommt denn der GGA? 1Hz?

Gruß
Markus
C macht es einfach, sich selbst ins Bein zu schießen; C++ erschwert es, aber wenn es Dir gelingt, bläst es Dir das ganze Bein weg! [Bjarne Stroustrup]

gnssfan
Beiträge: 16
Registriert: 24.10.2017, 17:50

Re: V 2.5.4

Beitrag von gnssfan » 14.11.2017, 13:32

Hallo Markus,

zu den Unterschieden der Smartphones

- Nicht geht es mit externem GPS bei KitKat 4.4.2 mit 1GB RAM, ohne "Falsche Standorte" gibt es hier auch keine Probleme
- Keine Probleme mit bei Lollipop 5.1 3GB RAM.

Normal läuft die GGA mit 1 Hz ein. Testweise mal mit 10 Hz und mit 0,2 Hz konfiguriert, was aber keinen Unterschied gezeigt hat inkl. der Zeiten bis zum Crash.

Bei Verwendung der Simulation mit Falschen Standorten gibt es kein Problem, auch mit eingestecktem USB GPS.

Dabei ist mir aufgefallen, dass die Simulation anscheinend die Mock Location etwas anders setzt als bei externem Empfänger. Zwar unwahrscheinlich, dass das mit dem Problem zu tun hat, aber trotzdem mal unten ausgeführt.
Bei der Simulation zeigen die anderen Apps eine Höhe an, bei externem Empfänger nicht. In der Meldung GGA ist vom Format zwischen Simulation und Extern kein Unterschied feststellbar. Die MSL/Geoid Referenz Höhe und der Geoid Abstand zum Ellipsoid sind bei beiden in GGA angegeben. 196.3 + 47.3 bzw. 516.819 + 45.729.
Aus der NMEA Ausgabe, nur Länge/Breite sind mit X überschrieben.
Extern: $GNGGA,191309.00,XXXX.93881,N,XXXXX.11128,E,1,12,0.95,196.3,M,47.3,M,,*4A
Simulation: $GPGGA,150642.00,XXXX.0000000,N,XXXXX.0000000,E,4,19,0.6,516.819,M,45.729,M,461.8,0985*47

Der Wert aus der MSL Höhe aus GGA wird in gnss Commander bei der Ellipsoid Höhe angezeigt. Das finde ich gut so, da die MSL-Höhe mir mehr sagt.
In der Mock Location wird auch diese MSL Höhe als Altitude gesetzt bei der Simulation, bei externem anscheinend nicht. Die anderen Apps ziehen davon dann noch ihren eigenen Geoid-Ellipsoid Abstand ab, weshalb dann dort eine entsprechend falsche MSL angezeigt wird. Bei der Simulation im Beispiel 471 m und bei externem Empfänger dann -47 m, da hier vermutet die Altitude nicht gesetzt wird.

Noch mehr Fragen von mir, sorry :)
Kann die Mock Location Altitude mit der Ellipsoid Höhe gesetzt werden (im Beispiel 196.3 + 47.3 bzw. 516.819 + 45.729)?
Oder variiert das von Android Version, Gerät und GPS Empfänger?
(setAltitude(double altitude): Set the altitude, in meters above the WGS 84 reference ellipsoid)

Grüße,
Martin

PilaBlu
Site Admin
Beiträge: 94
Registriert: 21.08.2017, 16:28
Wohnort: Stuttgart
Kontaktdaten:

Re: V 2.5.4

Beitrag von PilaBlu » 14.11.2017, 20:31

Hi Martin,
Nicht geht es mit externem GPS bei KitKat 4.4.2 mit 1GB RAM
OK ... hilft jetzt zwar auch nicht viel weiter bei der Fehlersuche aber immerhin eine klare Aussage! :)
die Simulation anscheinend die Mock Location etwas anders setzt
Da gibt es in der Tat einen gewollten Unterschied:

Früher habe ich ausschließlich die GGA-Position gemockt, d.h. da war die Position+Höhe immer korrekt.
Die allermeisten (privaten) Anwender nutzen die App aber zum Navigieren! :P

Daher hab ich mich dann später (weiß nicht mehr wann genau) beim "Mocken" auf den RMC fokusiert.
Wenn der RMC kommt, dann wird der immer bevorzugt - erst wenn 5 Sekunden kein RMC mehr kommt,
dann schalte ich intern wieder auf den GGA zurück. Der RMC liefert ja auch 'bearing' und 'speed' und
ohne diese Infos würdest du auf Google-Maps z.B. keinen Richtungspfeil sehen.
Das (RMC statt GGA) ist auch der Grund warum du keine Höhe siehst! (der RMC hat nur Lage-Info)
Kannst gerne testen und einfach mal deinen RMC-String abschalten...

Ich muss mal prüfen ob ich im Code die Höhe einfach aus dem GGA "klauen" kann.
:idea: Auch interessant zu wissen: Crasht dein Teil auch bei abgeschaltetem RMC?

Übrigens - nur als Info am Rande:
Die App wird natürlich auch von professionellen Vermessern genutzt. (meist mit dem ppm-10xx)
Das war ja auch der Grund warum ich die App zusammen mit ppm überhaupt entwickelt habe.
Diese Anwender nutzen auch nicht die gemockte Koordinate sondern greifen über eine eigene
Schnittstelle des GNSS-Commanders auf die Positions- und Qualitätsdaten zu.

Um diese zahlenden Kunden nicht zu verwirren, werde ich eine Release-Planung einführen.
Kurzum: Es wird erstmal gesammelt und dann zu definierten Zeiten ein neues Update eingestellt.


Viele Grüße
Markus

P.S. ich bin sogar am überlegen, ob ich die App nicht aufteile
Der GNSS-Commander wie bisher dann nur für die PRO-User und eine eigene App für Anwender
die damit nur ihren externen (einfachen) GNSS Empfänger anbinden oder das interne GNSS
besser nutzen wollen ... :geek:
C macht es einfach, sich selbst ins Bein zu schießen; C++ erschwert es, aber wenn es Dir gelingt, bläst es Dir das ganze Bein weg! [Bjarne Stroustrup]

gnssfan
Beiträge: 16
Registriert: 24.10.2017, 17:50

Re: V 2.5.4

Beitrag von gnssfan » 15.11.2017, 18:57

Hallo Markus,

ohne RMC wird die Höhe angezeigt. Da kommt zwar die vom ublox Sensor im GGA gelieferte MSL Höhe in den gemockten Daten als Ellipsoid Höhe an, aber das macht hier nichts. Was für eine Höhe im GGA geliefert wird mag ja auch vom Sensoranbieter abhängen und müsste sonst auch noch in der App konfigurierbar sein. Das braucht es nicht.
Die Höhe war auch mehr ein Hinweis auf einen Unterschied im Mocking zwischen GPS Simulation, die hier nicht crasht, und dem externem GPS.

Ohne RMC crasht dieses KitKat-Teil mit dem externen Sensor auch nicht mehr. Ist zumindest über Stunden ohne Fehler gelaufen. Natürlich gibt es dann ohne RMC keine Geschwindigkeit. Mit RMC und GGA crasht es aber nach ein paar Sekunden bis zu wenigen Minuten.
Beim Gegentest mit RMC ohne GGA zeigt der gnss Commander nur eine Geschwindigkeit an, aber keine Position und keinen Fix. Damit wird auch keine Mock Location gesetzt und es erfolgt ebenfalls kein Crash. Sagt jetzt nicht so viel aus.

Bleibt momentan nur die Vermutung, dass das Setzen der Mock Location ohne Höhe irgendwie in einer ungünstigen Laufzeit-Konstellation dieses KitKat-Teil zum Crash bringt. Nicht gerade logisch, da die Höhe ja per Default 0 von Android gesetzt sein sollte, aber wer weiß!?

Vielleicht kannst du die Höhe im Location Mock in einem zukünftigen regulären Release noch einbauen. Das mit der Releaseplanung ist selbstverständlich sehr gut nachvollziehbar.
Bis dahin muss es hier halt ohne RMC laufen ;)

Viele Grüße,
Martin

PilaBlu
Site Admin
Beiträge: 94
Registriert: 21.08.2017, 16:28
Wohnort: Stuttgart
Kontaktdaten:

Re: V 2.5.4

Beitrag von PilaBlu » 06.12.2017, 11:29

Hi Martin,

schau dir bei Gelegenheit mal bitte die neue Version 2.5.4.6 an.
Ich musste wegen NTRIP-Pro einen Bugfix einschieben ... und dann hab ich das hier auch gleich gemacht:
Damit sollte die Höhe auch mit RMC Strings angezeigt werden. (hole ich mir in dem Fall aus dem GGA)

Ich habe intern noch einen Timer laufen der mir zyklisch die Position neu "mockt" auch wenn gar keine neuen Daten
anliegen. Der Timer ist vor allem ab Android M/N wichtig, da sonst immer wieder die interne GPS dazwischenfunkt!
Effekt: Die Position springt zwischen der extern-gemockten und der internen hin- und her. :evil:

Diesen Timer habe ich jetzt so codiert, dass er erst ab Marshmallow ausgeführt wird.
Bitte teste einfach mal ob sich auf deinem KitKat Teil damit ein positiver (nicht) Crash-Effekt ergibt.

Zum Thema internes GPS mocken habe ich eine schlechte Nachricht. :cry:
Das geht zwar rein technisch - hängt sich aber nach kurzer Zeit auf.
Irgendwas hakt da im internen Android Handling...

Hast du hierzu schon mal folgendes getestet:
+ GNSS-Commander starten und auf "internes GPS" schalten
+ jetzt eine beliebige andere App (z.B. Maps) starten und die Position prüfen
:arrow: es könnte nämlich sein, dass die Location-Abfrage dann besser funzt

Ich frage ja im Hintergrund die Position via NMEA ab und das könnte (muss aber nicht!)
auch die Location-Abfrage in anderen Apps verbessern ...

Viele Grüße
Markus
C macht es einfach, sich selbst ins Bein zu schießen; C++ erschwert es, aber wenn es Dir gelingt, bläst es Dir das ganze Bein weg! [Bjarne Stroustrup]

gnssfan
Beiträge: 16
Registriert: 24.10.2017, 17:50

Re: V 2.5.4

Beitrag von gnssfan » 09.12.2017, 15:45

Hallo Markus,

Danke für die Anpassungen! :)
Die Anzeige der Höhe funktioniert jetzt und finde ich persönlich ganz nützlich.

Zu den Merkwürdigkeiten meiner Android-Teile.
Leider starte das KitKat-Teil trotzdem nach einigen Minuten (5-15) neu bei aktiviertem RMC. Ohne Mocking oder mit einer USB-Terminal App läuft die GPS-Maus stundenlang und gibt die NMEA-Strings aus. Das nützt natürlich nicht so viel ohne Mocking. Ich teste da erst noch ein wenig weiter und gebe dann nochmal Bescheid, wenn ich noch was finde.

Mein anderes Android-Teil mit 5.1 und dem Problem mit dem internen GPS ist wirklich verquer. Den Ansatz mit GNSS-Commander und internem GPS im Hintergrund laufen zu lassen, habe ich probiert. Leider bringt das keinen Erfolg. Sobald Maps gestartet wird, wird dem GPS sozusagen der Saft abgedreht und die Satelliten gehen verloren. Im ersten Augenblick hat Maps noch einen korrekten Standort und rast dann davon, bis die App "kein GPS" moniert. Wenn man den GNSS-Commander wieder in den Vordergrund bringt kommen die Signale nach und nach wieder mit z.Bsp. 12-14 SV used und SNR zwischen 20-40! Mit anderen Navi-Apps ähnlich und entsprechend nutzlos, wenn die einen z.Bsp. in anderen Ortsteilen orten. :?
Als Bluetooth GPS Maus für das KitKat mit GNSS-Commander geht das interne GPS dieses 5.1 Smartphone hingegen einwandfrei. Damit crasht das KitKat Teil mit Mocking nicht, obwohl auch RMC geliefert wird.

Irgendwann gibt es dann halt doch neue Hardware. :roll:

Viele Grüße,
Martin

Antworten