SW um Logdaten zu bearbeiten

    Zitat

    Original von kockie
    ... die neue Version 3.0 der Qstarz-Logger macht diesen Fehler nicht mehr, in der Version 2.2 ist er vorhanden. ....


    Hallo Wolfgang


    So ganz ohne Fehl und Tadel ist die aber auch noch nicht, man arbeitet aber dran.

    Sehr schön!


    Ich werde mich ein wenig an Euch dranhängen müssen und dann von den Ergebnissen profitieren, mir selber fehlt leider derzeit die Zeit, um intensiver mitzuspielen.


    Gruss


    Wolfgang


    Natürlich gerne. Falls es Ergebnisse gibt. Oder präziser: falls es Ergebnisse gibt, die irgendwo relevant sind.


    Und da haben wir momentan - bei der älteren SW - das Problem der Vor-0en bei der Länge. In der aktuellen SW bereinigt. Bekannter Fehler bei TTQV, tolerant ist u-center - es mag einige weitere Progs geben, die NMEA-logs einlesen, einige werden auch tolerant sein, einige vielleicht nicht.


    Höhe ohne Dezimale ist vermutlich nicht relevant.


    Weitere NMEA-Felder wurden zumindest von mir bislang nicht überprüft.


    Es ist u.U. eine sehr leidige Geschichte logs, die nicht der bekannten (A.d.V.: mir!) NMEA-Konvention entsprechen mit allen bekannten NMEA-log einlesenden Progs zu prüfen.


    Beispiel: wer es gelesen hat, Wintecs Auswerteprog (noch aktuelle Version m.W.) hat ein Problem, Nachkomma-0en zu löschen, nicht zu übernehmen. Dies kann aber nur getestet werden, wenn man auch über solche Koordinatenübergänge führt - logisch. Weiter müsste man eigentlich auch die E/W und die N/S Übergänge prüfen. Problem gesehen?


    Also kann eigentlich nur gesagt werden, Umwandlungen nach NMEA haben sich nun mal an die NMEA-Konventionen zu halten, dann sind auftretende Fehler dem Auswerteprog zuzuordnen und nicht dem Umwandlungsprog.


    Im Falle Wintec gibt/gab es hier viele gute Ansätze, Fehler an Wintec zu melden. Leider sind alle - auch alle Versprechungen dazu - bislang im Sande verlaufen. Wie - persönliche Anmerkung - ich überhaupt den Eindruck gewinnen musste, dass ein NMEA-log bzw. die Erzeugung eines solchen, hier nur noch von untergeordnetem Interesse ist.


    Edit: Kleine Korrektur...

    Einmal editiert, zuletzt von karomue ()

    Zitat

    Original von karomue
    ...
    Höhe ohne Dezimale ist vermutlich nicht relevant.
    ...


    Auch das ist in der neueren Version nicht enthalten. Hier werden auch die Hoehen mit Dezimalstelle ausgegeben


    Der Logger geht aber auch ganz andere Wege als die der Mitbewerber. Hier werden individuelle NMEA-Protokolle IM Logger gespeichert. Man geht also hin und sagt dem Logger das man z.B. GGA und GLL geloggt haben will (Nicht nach dem Sinn fragen, dient nur als Beispiel) und erhaelt dann diese Protokollsequenzen im Logger. Daher braucht die anschliessende Software sich nicht irgendwelche Daten aus den Fingern zu saugen um die einzelnen NMEA-Protokolle an den entprechenden Stellen zu fuellen.


    Klar, das geht natuerlich zu Lasten der Aufzeichnungsdauer. Denn so muss er auch mehr Daten speichern. Der zur Verfuegung stehende Speicher ist schneller belegt.


    Hallo Alfred,


    das sieht fast aus, als wärst Du daran beteiligt. :]


    Finde ich eine ausgezeichnete Idee, analog der Einstellmöglichkeiten bei normalen (Mäuse-) logs die Protokolle einzustellen.


    Schade nur, dass Wintec dies nicht auch - bis jetzt zumindest - erkannt hat.


    Zu Lasten der Aufzeichnungsdauer? Das dürfte ein Problem der SW sein, denn wenn "nur" das aufgezeichnet wird - in den in der Größe festliegendem Logger-Speicher - was man haben will, hängt das nur davon ab wieweit man sich beschränken kann. Klar, wenn ich "volle Pulle" aufzeichne, dann wird es Konsequenzen für die Dauer haben.


    Was den Speicherplatz angeht: da wird man sicher als Anwender Wege finden. Es ist was anderes, ob jemand z.B. nur einen Tag speichern muss - weil er abends gegeb. auf einen "Speicher" wie Notebook o.ä. auslesen kann - oder ob jemand eine 14 Tage, 3-Wochen-Tour im Gebirge, in der Wüste, auf See loggen will. Da hat er aber nun wirklich eine Wahlmöglichkeit durch die Beschränkung auf wichtige Protokolle, das dürfte in erster Linie GGA only sein.


    Du - und einige andere Leser hier - kennst/kennen die WBT201 und deren Loggeraufzeichnung. Ich habe unseren Urlaub mitgeloggt, bzw. dort Mitte Juni angefangen. Seither nicht mehr gelöscht und immer wieder mal auch hier mitlaufen lassen. Der 14-Tage-Urlaub füllte den Speicher nicht einmal zu 50 %, heute habe ich noch keine 80% erreicht. Was heißen will, ich sehe im derzeit wohl allg. angebotenen Speicherplatz nicht unbedingt das Problem. Aber da hast Du selbst sicher auch bereits Erfahrung gesammelt, ein weiterer User wäre Wolfgang "moppeddriver", der mit der Xaiox (war es, oder?) und der 201 seinen Urlaub mitgeloggt hat.

    Nochmal, hallo Alfred.


    Ich bekam von Wolfgang (kockie) ein log mit der neuen SW. Da fällt mir auf, dass GGA nicht enthalten ist. Standard? Dann würde die Höhe ja überhaupt nicht geliefert.


    EDIT: Nicht, dass ich das wissen müsste, es wird aber Besitzer dieser Maus schon interessieren.

    Einmal editiert, zuletzt von karomue ()

    Hallo Charly,


    nein, hatte ich weggeschaltet.
    Mach ich öfter, da Höhenangaben bekanntermassen ungenau sind. Bei Interesse meinserseits füge ich sie später aus SRTM-Daten hinzu. Der Logger macht es prinzipiell.


    Gruss


    Wolfgang


    O.K., geklärt.


    Wäre auch etwas ungewöhnlich und nur in der "Testphase" verständlich gewesen.


    Damit hat das Mäuschen in Bezug auf Loggerdaten wohl die Nase schön weit vorne. Wäre schön, wenn das für die Loggermäuse zum Standard würde.


    Hm. Doch nicht geklärt.


    Die GGA-Zeile kommt nach einer - frei konfigurierbaren - MSG ($GPSMSG)-Zeile. Mit dem simplen Editor aus Win wird sie auch ausgegeben, nur u-center hängt siean die MSG-Zeile (unerklärlich) an und gibt beide gemeinsam als "unknown"-Meldung aus.


    Zumindest momentan kann ich mir darauf keinen Vers machen. Auch ist mit einem Hex-Editor kein Kriterium zu erkenne, das auf das von Wolfgang genannte Ausblenden hinweisen würde.


    Ein wenig abweichend ist nur, dass die MSG-Zeile mit $GPS.. anfängt, sonst ist nur $GP üblich.

    Zitat

    Original von karomue
    ... - MSG ($GPSMSG)-Zeile.
    ...
    Ein wenig abweichend ist nur, dass die MSG-Zeile mit $GPS.. anfängt, sonst ist nur $GP üblich.


    Das ist z.B. einer der Punkte weshalb ich in einem frueheren Posting schrieb das die Ausgabe nicht ganz ohne Fehl und Tadel ist.


    Warum die eingebracht wird? Dazu habe ich aber bisher auch noch keine Erklaerung parat.

    Zitat

    Original von 900SS-97


    Das ist z.B. einer der Punkte weshalb ich in einem frueheren Posting schrieb das die Ausgabe nicht ganz ohne Fehl und Tadel ist.


    Warum die eingebracht wird? Dazu habe ich aber bisher auch noch keine Erklaerung parat.


    Hm.


    Nur mal so nebenbei: dieses log reagiert sehr seltsam. Das bei mir vorliegende beginnt mit 2 Zeilen $GPSMSG, jeweils abgeschlossen - wie auch alle anderen Zeilen - mit der bekannten Checksum (nicht geprüft ob richtig), 2x 0D, 0A.


    Nachdem ich bei der 2. MSG-Zeile das S nach $GP im Editor mal gelöscht und das File unter neuem Namen gespeichert habe, dauert eine Wahnsinnszeit, sind alle 0D 0D 0A gelöscht.


    Leider ist das File zu lang, um es komplett zu untersuchen. Das neu erzeugte wird - natürlich - von u-center bis auf eine einzige unknown Zeile überhaupt nicht mehr erkannt, in dieser Zeile hängt dann alles komplett hintereinander. Sehr seltsam das, entzieht sich momentan weiterer Nachforschung/persönlicher Neugierde.


    Übrigens: das andere von Dir angezogene Posting hatte ich nicht gelesen.

    Einmal editiert, zuletzt von karomue ()

    Zitat

    Original von karomue
    ... Das bei mir vorliegende beginnt mit 2 Zeilen $GPSMSG, jeweils abgeschlossen ....


    Hallo Charly


    Machen alle so nach NMEA gespeicherten LogFiles des Utilitys. Die erste Zeile ist aber vom Aufbau her nicht identisch mit den Folgenden. Die erste enthaelt eine "Ordnung".
    $GPSMSG,0,1,2,4,5,7,9,10,11,12,13,14,16,15,17,18,0*34


    Frag mich bitte nicht nach dem Sinn dieser "Ordnung". Den Hintergrund habe ich noch nicht begriffen.

    Hi,


    Zitat

    Na ja, vielleicht lese die Auflösung am WE, wenn ich wieder zurück bin.


    uupps, ich muss wohl erst mein Basis-Studium in NMEA fertig machen, bevor ich hier wieder auf 'Ballhöhe' bin ?(
    Ok, werd also mal alles in Ruhe aufarbeiten, neue SW-Versionen installieren und meine neuesten Logs damit bearbeiten.
    Ich hoffe ich komm damit noch dieses Jahr hin ;D


    @Charly: nee, war geschäftlich + Du kriegst noch eine PN von mir


    PN gelesen, beantwortet.


    Und lass Dich nicht verwirren mit den neugierigen Fragen/Antworten zwischen Alfred und mir.


    Die von der neuen Auswerte-SW generierten NMEA-logs haben schon so ihre Eigenarten...... Das muss aber für original-belassene logs nicht stören.

    Hi,
    während mein PC nun mit allen derzeit aktuellen SW-Versionen versorgt wird, studiere ich diesen Thread, um mein NMEA-Wissen zu verbessern. Dabei fällt mir auf, dass ich das Problem NMEA-Logs, bzw die Unzulänglichkeiten der SW bereits im August schon mal hier gepostet hatte:
    NMEA-LOG-SW-Problem
    Leider gab's damals keine für mich zufriedenstellenden Ergebnisse.


    So und hier einige Zwischenergebnisse:
    Travel Recorder 2.4 = erzeugt immer noch NMEA-Logs, die QV (.95) nicht verarbeitet. "Zudem ist ein Speichern als .Bin-File (immer noch) nicht möglich." Diese Aussage ist falsch gewesen. Das Speichern des Bin-File geschieht automatisch beim Download der Logdaten.




    Korrektur: Bin-File Speicherung ist möglich !

    Einmal editiert, zuletzt von ppcfan ()