Posts: 8
Threads: 1
Joined: Nov 2010
Hallo zusammen,
zunächst mal ein dickes Lob für dieses coole, nützliche Programm. Ich habe allerdings mit der neuen Version ein kleines Problem, weiß aber nicht ob es ein Bug oder ein Feature ist. 
Also, ich habe fürs Auto ein Navi von Navigon. Bei diesem habe ich eine Logfunktion freigeschaltet. Die Logdatei ist eine Textdatei , welche NMEA Datentelegramme vom Typ $GPRMC und $GPGGA enthält. Das Problem ist, dass das Navi sofort nach dem Einschalten mit dem Loggen anfängt, obwohl es noch keine gültige Position hat. Das sollte aber eigentlich nicht weiter stören, da die Datentelegramme als ungültig markiert sind. D.h. bei Telegramm $GPRMC steht an der 3. Datenposition ein "V" (V=void) bzw. bei $GPGGA an der 7. Position "Qualität der Messung" eine 0 für ungültig.
Wenn man so eine Logdatei mit RC 1.33 öffnet, funktioniert alles bestens, d.h. die ungültigen Daten werden herausgefiltert. Bei RC 2.0 werden alle Daten geladen, was etwas blöd ist, wenn sich die ersten Koordinaten in Nähe der Adria befinden. 
Lässt sich die Funktionalität von Version 1.33 wiederherstellen?
Gruß Paule
Posts: 7,530
Threads: 230
Joined: Aug 2007
20.11.2010, 21:10
(This post was last modified: 20.11.2010, 21:11 by routeconverter.)
Hallo pk68,
willkommen im Forum!
(18.11.2010, 21:47)pk68 Wrote: zunächst mal ein dickes Lob für dieses coole, nützliche Programm.
Das freut mich 
(18.11.2010, 21:47)pk68 Wrote: Wenn man so eine Logdatei mit RC 1.33 öffnet, funktioniert alles bestens, d.h. die ungültigen Daten werden herausgefiltert. Bei RC 2.0 werden alle Daten geladen, was etwas blöd ist, wenn sich die ersten Koordinaten in Nähe der Adria befinden.
Lässt sich die Funktionalität von Version 1.33 wiederherstellen?
Ich kann so ohne weiteres nicht sagen, welche der vielen Änderungen zwischen 1.33 und 2.0 zu dem veränderten Verhalten geführt hat. Bitte schick mir doch eine Testdatei, dann schaue ich mir gerne das an.
In der FAQ steht, wie man Dateien im Forum hochlädt oder mich erreichen kann.
--
Christian
Posts: 7,530
Threads: 230
Joined: Aug 2007
23.11.2010, 13:53
(This post was last modified: 23.11.2010, 13:54 by routeconverter.)
Ich zitiere hier ein Mailantwort von mir für die anderen Leser dieses Threads:
> Es ist der erste $GPGGA Datensatz, der an der 7. Position "Qualität der Messung" eine 1 für gültig stehen hat. Die Datensätze davor haben an dieser Position keinen Eintrag.
Korrekt, an dieser Stelle ist RouteConverter etwas nachlässig und wertet weder das 'N' von RMC-Sentences noch die '1' von GGA-Sentences aus. Die Signalintegrity von RMC-Sentences gibt es erst seit NMEA 2.3 und viele Logger können da noch nichts. Und bei GGA-Sentences schreiben viele Logger alles Mögliche hinein :-(
> Inzwischen habe noch etwas weiter "geforscht". Die ungültigen Datensätze werden zum großen Teil (entgegen meiner Behauptung im Post) heraus gefiltert. Wenn man die Liste in Routeconverter einlädt, sind die ersten 47 Positionen unbrauchbar.
Das kommt aufgrund der laxen Haltung (s.o.)
> Könnte es sein, dass RC $GPGGA Datensätze als gültig akzeptiert, sobald mehr wie 2 Satelliten vorhanden sind?
Schlimmer noch: es muß sich nur vom Vorgänger unterscheiden, um als Datensatz akzeptiert zu werden. Da habe ich länger dran gefummelt, damit RouteConverter möglichst viele NMEA-Logs von fehlerhaften GPS-Loggern liest - und ich nicht so viele Supportanfragen bekomme.
Wenn Du es testen magst, baue ich eine versteckte Option (da gibt es schon einige: http://www.routeconverter.de/download/Hi...ptions.reg) ein, das die Prüfung strikter macht. Würde das helfen?
--
Christian
Posts: 8
Threads: 1
Joined: Nov 2010
Hallo Christian,
(23.11.2010, 13:53)routeconverter Wrote: Schlimmer noch: es muß sich nur vom Vorgänger unterscheiden, um als Datensatz akzeptiert zu werden. Da habe ich länger dran gefummelt, damit RouteConverter möglichst viele NMEA-Logs von fehlerhaften GPS-Loggern liest - und ich nicht so viele Supportanfragen bekomme.
danke für die Erläuterungen. Ist natürlich Mist, wenn diverse Logger sich nicht an die Regeln halten. Da versteht man, dass Du Kompromisse eingehst, damit möglichst viele Leute mit Deinem Programm arbeiten können.
(23.11.2010, 13:53)routeconverter Wrote: Wenn Du es testen magst, baue ich eine versteckte Option (da gibt es schon einige: http://www.routeconverter.de/download/Hi...ptions.reg) ein, das die Prüfung strikter macht. Würde das helfen?
Das ist ein Supervorschlag. Wenn es nicht zuviel Aufwand ist, wäre eine Option, die nur gültige Datentelegramme akzeptiert (also RMC mit 'A' bzw. GGA mit '1' oder '2'), hilfreich. Wenn der entsprechende Eintrag keinen Wert hat, sollte das Telegramm auch als ungültig bewertet werden.
Gruß Paule
Posts: 7,530
Threads: 230
Joined: Aug 2007
(23.11.2010, 22:08)pk68 Wrote: (23.11.2010, 13:53)routeconverter Wrote: Wenn Du es testen magst, baue ich eine versteckte Option (da gibt es schon einige: http://www.routeconverter.de/download/Hi...ptions.reg) ein, das die Prüfung strikter macht. Würde das helfen?
Das ist ein Supervorschlag. Wenn es nicht zuviel Aufwand ist, wäre eine Option, die nur gültige Datentelegramme akzeptiert (also RMC mit 'A' bzw. GGA mit '1' oder '2'), hilfreich. Wenn der entsprechende Eintrag keinen Wert hat, sollte das Telegramm auch als ungültig bewertet werden.
Hallo Paule,
ich habe jetzt keine versteckte Option draus gemacht, da die 2.2er Entwicklung gerade erst angefangen hat, bekomme ich so vielleicht Feedback, ob aktuelle Logger akkuratere Log-Dateien erzeugen.
Die Idee, keinen Wert auch als ungültiges Telegramm zu werten, habe ich verworfen, da ich zu viele Testdateien habe, wo die Qualitätsfelder konsequent nicht ausfüllt sind.
Die aktuelle Vorabversion zeigt Deine Testdatei bei mir nun so an, wie man es erwarten würde. Bitte teste mal und berichte.
--
Christian
Posts: 8
Threads: 1
Joined: Nov 2010
Hallo Christian,
kurzes Feedback von mir. Die Vorabversion funktioniert so, wie ich es von RC 1.33 gewohnt war. Ich habe diverse Logdateien mit Version 1.33 bzw. 2.2 ausprobiert. Die Positionszahl und Dauer der eingelesen Dateien waren gleich. Nur bei der Tracklänge zeigt RC 1.33 einen zu kurzen Weg an. Aber das ist ja korrigiert. Danke für die schnelle Hilfe.
Gruß Paule
PS: Bei der Weiterentwicklung von Routeconverter ist es eventuell geplant, dass man den Track in Abhängigkeit z.B. der Geschwindigkeit mehrfarbig gestalten kann?
Posts: 104
Threads: 2
Joined: Sep 2008
(26.11.2010, 17:54)pk68 Wrote: PS: Bei der Weiterentwicklung von Routeconverter ist es eventuell geplant, dass man den Track in Abhängigkeit z.B. der Geschwindigkeit mehrfarbig gestalten kann?
Es gibt bei den versteckten Optionen eine Option "write/Speed" um beim KML-Export die Geschwindigkeit visuell anzeigen zu lassen. Allerdings wird das nur in Google Earth angezeigt.
Posts: 8
Threads: 1
Joined: Nov 2010
(26.11.2010, 18:50)EddiVonDerAlm Wrote: Es gibt bei den versteckten Optionen eine Option "write/Speed" um beim KML-Export die Geschwindigkeit visuell anzeigen zu lassen. Allerdings wird das nur in Google Earth angezeigt.
Danke für den Hinweis. Kann man die Einteilung der Segmente (Bereiche a 10km/h) noch verfeinern? Ich habe noch einen iBlue 747A+ Logger, den ich bei meinen Radtouren einsetze. Da ist ein 10km/h Raster wenig sinnvoll, denn über 30km/h komme ich im Gelände nicht hinaus.
Posts: 104
Threads: 2
Joined: Sep 2008
Sehe ich ein, dass das mit dem Fahrrad nicht so gut klappt bei dem Raster. In 5 km/h Schritten wird es dann allerdings für die Autofahrer wieder etwas unübersichtlich.
Kannst Du programmieren?
Posts: 8
Threads: 1
Joined: Nov 2010
(29.11.2010, 10:01)EddiVonDerAlm Wrote: Kannst Du programmieren?
Microcontroller in C, ein bißchen Visual Basic, LabView, mit Java sieht es schlecht aus.
|
