@CITYHUNTER: Läßt sich folgendes nachvollziehen?

  • So, hallo mal wieder,


    um jetzt mal ein bischen mehr Klarheit zu bekommen habe ich mir mal die Protokolldefs gesucht.


    Offenbar wird von CruxView und SirfDemo die Info aus dem GGA Proto nicht ausgewertet, um die Uhrzeit und Position anzuzeigen. Na schön. Wir können auch anders ;)
    Um zu sehen, was wirklich von der Maus kommt habe ich jetzt mal SirfDemo auf meinem Lappi laufen. Es sind nur die Prots GGA und VTG aktiv. Im "Debug View" werden die empfangenen Daten im Klartext engezeigt. Dabei ist der erste Wert hinter dem $GPGGA die Uhrzeit hhmmss in UTC. Die Werte kommen schön gleichmäßig und im Vergleich zum Referenzuhr-Applet vom PTB (http://www.ptb.de/de/zeit/uhrzeit.html) mal minimal früher, mal minimal später aber insgesamt genau.


    Jetzt das Ganze auf dem PDA:


    Achtung: Nach SirfXTracDemo fragt CruxView, ob es die Maus in den MNEA-Modus schalten soll. Dabei hängt es sich bei mir immer auf. Habe die Maus dann mit SirfDemo vom Laptop wieder auf NMEA gesetzt.


    SirfXTracDemo schaltet meine Maus immer in den Sirf Modus. Damit ist die Zeit auch ziemlich genau. (Hängt sich aber leider nach einiger Zeit auf :-D) )


    CruxView zeigt jetzt nur Daten im "Message" Fenster.
    Zu Anfang werden die Daten total ungleichmäßig angezeigt, mal mehrere auf einmal, dann etwas Pause... Nach ca. 10s ist dann der 1s Rhythmus erreicht und die Zeit hinkt ungefähr eine Sekunde hinterher.


    Wenn MN4 auch genau diese Daten bekommt, dann kommt noch die interne Verarbeitungszeit dazu. Das klingt erstmal schon nicht so gut :( Wie soll da eine korrekte Position angezeigt werden, wenn die Daten eine Sekunde alt sind. Das ergibt bei 100 km/h schon mindestens 28m Fehler.


    Oje, jetzt höre ich lieber auf, weiter drüber nachzudenken... ?(


    Aber offensichtlich entsteht irgendwo im PDA in der seriellen Bearbeitung eine Verzögerung. Vielleicht ist es auch wirklich nur die Baudrate. NMEA 0183 ist definiert für 4800 Baud. Da ist es egal, ob die Schnittstelle auf 38400 oder 4800 steht (ist es bei mir wirklich - das wird offensichtlich alles vom Bluetooth-Profil geregelt - ich bekommen immer einen connect zur Maus), die Daten kommen effektiv nur mit 4800 Baud.
    Im Gegensatz dazu ist das Sirf Protokoll als 38400 definiert. Damit war die Zeit genauer (SirfXTracDemo).
    TomTom scheint schon zu wissen, warum sie den Sirf-Modus verwenden... (Habe ich jedenfalls irgendwo gelesen).


    Gruß
    Facehuger

  • Rooster
    habe Zweifel an grundsätzlichen (Buffer/Puffer) Problemen mit dem seriellen I/O. (zumindest in 2002)
    Die Anzeige von Cruxview ist wg der Fensteranzeige unregelmässig.
    In Glopus z.B. kommen alle Daten _regelmässig_ im Sekundentakt.
    Siehe auch <hier>
    Wolf
    ...
    natürlich haben wir immer den Takt (1 Sek) der Maus.

    Einmal editiert, zuletzt von WolfL ()