NMEA-Protokoll: USB oder serielle Schnittstelle?

    Hi,
    ich habe eine Verständnisfrage zum NMEA-Protokoll.


    Mein GPS-Gerät (SiRF III) liefert die NMEA-Daten über ein USB-Kabel an den PC. Werte ich diesen Datenstrom mit VisualGPS oder U-Center aus, erhalte ich fragmentierte Datensätze; die Sat-Nummern stimmen nicht, die Empfangsstärke erfolgt nur in 3 Anzeigen, es werden nicht alle Satelliten angezeigt.


    Das Gerät hat auch die Einstellmöglichkeit auf die serielle Schnittstelle. Diese liefert typisch ein 0183-NMEA Protokoll mit 4.800 Baud.


    Kann es sein, dass das an die serielle Schnittstelle gelieferte NMEA-Protokoll "bessere" Daten enthält?


    Ich habe auch ein PC-Interface-Kabel, aber leider eines mit offenen Enden und kann es nicht anschliessen, nocht nicht.


    Das Gerät selbst wertet die Sat-Signale und Anzeigen richtig aus, ich vermute daher, dass die binären Sirf-Daten genommen werden.


    Also, spielt es eine Rolle, ob ein NMEA-Protokoll über USB oder über die serielle Schnittstelle in den PC gelangt?


    Gruß
    Günther


    Hallo Günther,


    m.W.nein, kam mir noch nicht unter. Und binäre Daten werden eigentlich seit ca 4 Jahren nicht mehr verwendet, allg. hat sich (die Textform von) NMEA eingebürgert. An der Baudrate sollte es eigentlich auch nicht liegen, denn das wurde auch vor vielen Jahren schon festgestellt, dass 4800 Bd dicke ausreichen - sofern nicht u.U. alle Protokolle aktiviert sind, GSV sekündlich eingestellt ist. Das könnte zu performace-Problemen führen.


    Richtiges Auswerten ist auch möglich, wenn die Empfangs-SW fehlertolerant arbeitet, also z.B. defekte NMEA-Sätze ausblendet - wenn es dann nicht zu viele in Folge sind (Kontrollbyte-Auswertung).


    Schick mir mal zum Anschauen ein etwa 1 min-log-Ausschnitt.

    Hi, Charly,
    im Anhang ein kleines Logfile.


    Gruß
    Günther


    Edit: Ich habe das Logfile gelöscht.

    2 Mal editiert, zuletzt von Polarstern ()

    Zitat

    Original von Polarstern
    ... im Anhang ein kleines Logfile. ...


    Hallo Guenther


    Ich habe mich zwar laenger schon nicht mehr intensiv mit VisualGPS beschaeftigt und meine Erinnerung laesst nach, aber aktiviere mal RMC. Denn die "Nichtanzeige" ist nur auf der Eingangsseite nicht da. Bei der eigentlichen SAT-Anzeige ist das alles da

    Einmal editiert, zuletzt von 900SS-97 ()

    Hallo Günther,


    ich sehe im log nichts ungewöhnliches, da sind auch keine Abbrüche zu sehen.


    Alfreds Einwand verstehe ich nun nicht, denn wenn ich Dein Eingangsposting richtig verstanden habe, ist Navigation ja o.K. Also reicht GGA, RMC ist m.E. nicht nötig.


    Was aber zu Performanceproblemen führen könnte, ist die Art der Protokolle. GLL braucht man nicht, GSV und GSA kommen alle sek., das ist vornehmlich für GSV i.d.R. zu oft. Hier reichen alle 5 sek. dicke aus, meist behebt sich damit auch das Problem zerschnibbelter Protokolle.


    Bliebe noch die Frage: wie, wo, kommt es zu fragmentierten Datensätzen, denn im log sehe ich nichts davon. Kann man das mitloggen?

    Einmal editiert, zuletzt von karomue ()

    Zitat

    Original von karomue
    Also reicht GGA, RMC ist m.E. nicht nötig.


    Hmm, was hat jetzt GGA mit RMC zu tun? ?(


    Ich dachte bisher, GGA plus RMC oder VTG muss sein?

    Navigation mit Google Maps über Android Auto und AAWireless im Nissan Qashqai Akari Automatik. Zusätzlich ist POIbase NAVI ein treuer Beegleiter meiner Fahrten  ;)

    Zitat

    Original von karomue
    ...
    Alfreds Einwand verstehe ich nun nicht, denn wenn ich Dein Eingangsposting richtig verstanden habe, ist Navigation ja o.K. Also reicht GGA, RMC ist m.E. nicht nötig.
    ...


    Hallo Charly


    Ich hatte auch geschrieben, das ich mich laenger nicht mehr intensiv mit VisualGPS beschaeftigt habe. An meine Aufzeichnungen dazu komme ich im Moment nicht ran. Also versuche ich aus der Erinnerung zu leben. Da ist mir so, als ob ich den Fall schon mal hatte. Deswegen schrieb ich das er mal RMC aktivieren soll. Ob das zum Erfolg fuehrt, kann ich nicht sagen. Aber einen kostenlosen Versuch ist es Wert.


    Ob die Navigation geht, stand fuer mich nicht zur Debatte

    Hi, Charly,
    dass die Sätze da sind, ist schon klar.


    Aber schau' Dir mal die Signalstärke an, da werden nur 3 Werte ausgegeben:


    $GPGSV,3,1,08,26,79,163,36,15,70,274,36,28,58,084,50,27,38,080,36*72
    $GPGSV,3,2,08,08,29,075,36,18,23,314,36,10,16,193,36,17,13,125,44*75
    $GPGSV,3,3,08,,,,,,,,,,,,,,,,*71


    Ein Satellit, der schon längst getrackt wird, kommt nicht in die Balkenanzeige, Satellitennamen erscheinen doppelt in der Anzeige.


    Blende ich die Satellitenseite im Gerät auf, erscheinen unterschiedliche Werte, so wie sie auch meine iBT in etwa bringt, manchmal aber auch noch höhere Werte, was ein wenig unlogisch ist, auch wenn ich eine ext. Hirschmann dran habe.


    Ich habe den Eindruck, als wenn die Techniker hier ein eigenes Protokoll kreiert haben, mit dem U-Center und VisualGPS nicht so richtig etwas anfangen können.


    Die Kernfrage ist, können an der seriellen Schnittstelle andere Werte als bei USB ankommen?


    Gruß
    Günther

    Zitat

    Original von HSVMichi


    Hmm, was hat jetzt GGA mit RMC zu tun? ?(


    Ich dachte bisher, GGA plus RMC oder VTG muss sein?


    Hallo Michi.


    In GGA und RMC stehen die Koordinaten, es gibt Progs die werten nur RMC und nicht GGA aus.


    Dann steht in RMC und VTG die Geschwindigkeit: Will man die haben und wird sie nicht evtl. aus Koordinatendifferenz und Zeit errechnet, dann muss man eines der beiden mit reinnehmen. Welches, das hängt wiederum vom Prog ab, und da sind z.B. schon MN und TTN - soweit ich das noch weiß - unterschiedlich.


    @Günther,


    ich schau mir das jetzt mit anderen Analyseverfahren noch an.


    Hallo Günther,


    die Empfangsstärke ist "gewöhnungsbedürftig", aber bei 1min 30 sek log-Länge möchte ich dazu nicht mehr sagen. Könnte ja sein, dass der FW-Mensch hier nur diskrete Stufen zulässt, wer weiß?


    Doppelte sat-Namen konnte ich keine entdecken, ich habe aber auch nicht das Textfile auf die einzelnen Sätze direkt untersucht.


    Dass an USB und seriell unterschiedliche Daten ausgegeben werden, halte ich nicht für relevant, denn das ist doch meist (immer?) nur ein aufsplitten auf verschiedene Wege eines einzigen Ursprungsdatenstroms.


    Was mich stört ist die Höhe mit -0049 bzw -0050 m, das ist schon mal sicher falsch, und dass die Geoidkorr. fehlt. Was ist das für eine Maus?


    Geschwindigkeit gibt es - logisch - nicht, da RMC oder VTG fehlt. Zumindest nicht direkt aus dem log.


    Evtl. mal 20 - 30 min-log?

    Hm, ja. VGPS wertet die sat-Balken etwas seltsam aus, warum weiß ich nicht. u-center sieht soweit ich das überblicke o.K. aus.


    VGPS wird von mir schon seit geraumer Zeit nicht mehr verwendet, u-center bietet viel mehr Auswertemöglichkeiten.

    Hi, Charly,


    es ist eine Maus im weitesten Sinne: Magellan Triton 1500.


    Das Gerät liefert am Laptop ein Sat-Signal.


    Das Gerät selbst zeigt beste Höhenwerte an, bei guter Accuracy o bis 1m, daher auch meine Vermutung, dass wohl eher die binären Sirfdaten ausgewertet werden.


    Mich hat schon GLL - ein emulierter Loran C-Datensatz - irritiert.


    Wenn ich z.B. mein Garmin GPS 72 nehme, steht da unter Interfacing die NMEA 0183 version 2.3, ASCII Text output.
    Neben GPRMC usw. werden noch die speziellen Garminsätze PGRME, PGRMZ und PSLIB übertragen.


    Derartige Angaben gibt es seitens Magellan zum Triton nicht. Ich weiss auch nicht, ob ich eine gute Auskunft vom Support bekomme, wenn ich anfrage.


    Ich werde ein längeres Logfile aufzeichnen.


    Leider sind die Anomalien nur zufällig aufgefallen, weil ich nebenbei auf das Display des Triton geschaut habe oder aber temporär auf dem Satellitenbild in VisualGPS zufälligerweise 2 Satelliten-Nummern doppelt gesehen habe; meine Beobachtungen warten deshalb so intensiv, weil ich EGNOS aufspüren wollte.


    Zuerst habe ich gedacht, VisualGPS kommt mit Windows Vista nicht zurecht, aber die verqueren Infos kommen auch über u-Center rein.


    Ein Magellan-Kenner meinte, die richtigen NMEA-Daten kommen nur über den seriellen Anschluss rein.


    Gruß
    Günther

    Ui ja.


    Garmin-Protokolle kenne ich von meinen Garmins noch, bei Magellan ist die Kenntnis 0.


    Und da könntest Du für beides schon Recht haben, das lässt sich verm. auch nicht so ohne weiteres überprüfen:


    USB und seriell unterschiedlich,
    binäres Protokoll als Ausgabe.


    Mit Magellans habe ich hier noch keinen gesehen, auch keine logs erhalten. Da bin ich wie gesagt auch chemisch rein.


    Und ob die Protokolle (GSV auf 5 sek.) programmierbar sind, ist auch fraglich.


    Bei den Garmin kann man - wenn ich mich recht erinnere - die Baudrate einstellen. Wenn das beim Magellan auch geht, versuche mal die nächste Stufe. Aber bei "nur" sporadischen Fehlern ist das so eine Sache....

    Hi, Cahrly,


    das Logfile im Anhang.


    Wenn Du die Dop-Werte unter die Lupe nehmen könntest, und mal nach EGNOS schauen, würde mich freuen.


    Zur Höhe: Wenn in NMEA -0056 ausgewiesen wird, zeigt das Gerät -12 , die Differenz ist konstant 46 m.


    Gruß
    Günther


    Edit: Datei entfernt

    Einmal editiert, zuletzt von Polarstern ()


    Mach ich.


    Und hätte mir auch einfallen können, Du bist ja "Land unter". :D