Allgem. Einstellungsfragen, z.B. Baudrate

  • @all,


    so, nachdem ich das mit dem Hyperterminal nun begriffen habe, ;D habe ich eben mal ein paar Versuche laufen lassen.


    Alle Prot auf 1, Geschwindigkeit 4800:


    das gesamte Datensatz kommt deutlich innerhalb 1 sek rein, schätze in 1/2 sek.


    Das gilt auch bei max Geschwindigkeit der Maus. Hier gibt es auch keine Verdoppelung, Vervielfachung der Protokolle, die Zeit zählt immer im 1 sek-Rhythmus hoch.


    Möchte jetzt nicht darüber philosophieren. 4800 sollten bei meiner Emtac das Gleiche sein wie bei irgendeiner Maus. O.K, ich hatte noch kein fix, d.h. es waren nicht alle Datensätze mit Daten gefüllt. Aber der kritischste, GSV, war "voll", da 12 sat in view.


    Das läßt mich jetzt doch wieder zweifeln daran, dass die Geschwindigkeit der Maus etwas mit angefressenen, fehlenden Protokollen und "Hinterherhinken" zu tun haben sollte.


    Nach nun erfolgtem fix hat sich nichts geändert. Sowohl mit Hyperterminal, CruxView Message und VisualGPSXP kommt der gesamte Datensatz in ca 1/2 sek. Leider kann ich so schnell garnicht stoppen!


    Die Feststellungen von hamba sollten damit einen anderen Grund haben, es wäre mal interessant - hallo hamba?? - wie, mit was seine logs aufgenommen wurden.


    Obige Erkenntnisse sind mit einem Notebook gewonnen worden. Auf einem PDA könnte es anders aussehen, mit einem der PDA-Progs ebenso.

  • Hi Charly,


    Na so wie das aussieht, sollten wir der Sache mal anders auf den Zahn fühlen.


    Ich denke, man sollte mal Versuchen einen Zusammenhang zwischen verwendeter Software in Bezug zur Rechenleistung des PDA aufstellen.
    Vielleicht mag Deine Vermutung ja bestätigt werden, daß die Software teilweise zu aufwendig programmiert ist.


    Zustimmung???


    Gruß
    Anderl

    **** ob Desti SP, TTN5 oder MN4.....angekommen bin ich fast immer ****
    !!!! Karte, Kompaß & Höhenmesser haben mich I M M E R ans Ziel gebracht !!!!


    www.eNavTools.de.vu
    Geodätische Koordinatentransformationen am Pocket PC
    Helmertparameter u. m.

  • Hallo Anderl,


    ja. Vorschläge wie anpacken? Momentan kann ich nicht mitspielen, da mein PDA - immer noch - weg ist. Sicher wird de Vergleich auf dem PDA schlechter aussehen als auf dem PC.

  • Hm,


    Mir schwebt mal vor, die Rechenleistung des PDA runterzufahren. Also mal das Gegenteil vom Übertakten. Hab auch schon Tools und Anleitungen dafür gefunden. So was in der Richtung vielleicht.


    Oder als Alternative, Leute finden, die die gleiche Software mit unterschiedlichen PDA verwenden. Wär zumindest mal ein Anfang.


    Also ich kann momentan mit einem HP 2210 + TTN3 wired dienen.


    Gruß
    Anderl

    **** ob Desti SP, TTN5 oder MN4.....angekommen bin ich fast immer ****
    !!!! Karte, Kompaß & Höhenmesser haben mich I M M E R ans Ziel gebracht !!!!


    www.eNavTools.de.vu
    Geodätische Koordinatentransformationen am Pocket PC
    Helmertparameter u. m.

  • Wäre naheliegend, daß die Taktrate runtergeht. Aber wir haben vielleicht noch ein Problem, daß zu berücksichtigen wäre. Die Speicherkarten auf denen evtl. Karten oder Software drauf ist, müssten als Fehlerquelle auszuschließen sein.


    Gruß
    Anderl

    **** ob Desti SP, TTN5 oder MN4.....angekommen bin ich fast immer ****
    !!!! Karte, Kompaß & Höhenmesser haben mich I M M E R ans Ziel gebracht !!!!


    www.eNavTools.de.vu
    Geodätische Koordinatentransformationen am Pocket PC
    Helmertparameter u. m.

  • Hm. Haben die bei reinem log auch ihre "Chips" im Spiel?


    Wir sollten beim Datenstrom von drr Maus, also beim log anfangen. Und da auch erst mal mit Tools wie VisualGPS. Dann haben wir Kartenzugriffe auf Karten in Karten - au, das konnte ich mir jetzt nicht verkneifen, übersetze das aber gerne :gap - erst mal außen vor.


    Ach ja,
    1. Speicher-
    2. Land-
    3. Speicher-Karten. :gap

  • Hallo zusammen,


    durch eine Erhöhung der Übertragungsgeschwindigkeit ergibt sich wirklich keine Verdoppelung der Protokolle oder der Daten. Der Übertragungszyklus wird ja surch das pro NMEA-Protokoll eingestellte Intervall vorgegeben. Ist die Übertragungsgeschwindigkeit höher, dann werden die anfallenden Daten einfach nur schneller von der Maus zum PDA/PC übertragen. Dafür entsteht dann zwischen dem letzten und dem nächsten Übertragungszyklus (Intervall) einfach nur eine entsprechend lange Übertragungspause.


    Ich habe mal theoretisch die Übertragungsmenge (ASCII-Zeichen) ausgerechnet, wenn alle NMEA-Protokolle angeschaltet und auf 1s Intervall eingestellt sind und wenn 12 Satelliten in view sind. Es müssten dann so ca. 484 Zeichen (GGA= 70, GLL = 47, GSA = 53, GSV1 = 71, GSV2 = 71, GSV3 = 71, RMC = 67 und VTG = 34) anfallen. Diese 484 Zeichen ergeben wiederum bei 8 Bit pro Zeichen 3872bit. Das ist also weniger als die theoretisch mögliche Übertragungsmenge die pro Sekunde bei 4.800b/s übertragen werden kann. Das hatte ich in meinem Thread auch festgestellt. Die errechnete Datenmenge ließe sich theoretisch innerhalb 0,80s übertragen. Da es sich hier um eine Überschlagsrechnung handelt, sind die angegebenen Werte natürlich blanke Theorie.


    Dennoch gibt es bei meiner SysOnChip GPS CF Plus in dieser Situation mit der Übertragung der anfallenden Datenmenge zeitliche Probleme. Das Problem scheint zumindest bei meiner SysOnChip GPS CF Plus zu sein, dass die GPS-Karte bestimmte Dinge nicht parallel abarbeiten kann. Das heißt, dass die SoC+ die Übertragung abbricht, weil sie andere Dinge erledigen muss.


    Durch die Erhöhung der Übertragungsrate auf 38.400b/s ist das Problem verschwunden. Die anfallende Datenmenge benötigt bei dieser Übertragungsgeschwindigkeit theoretisch ja auch nur 0,1s.


    Da ich bei meinen Tests sowohl mit dem PDA als auch mit dem PC die gleichen Ergebnisse erzielt habe und eine um das 8-fache höhere Übertragungsgeschwindigkeit den PDA/PC theoretisch noch mehr fordert, schließe ich Performanceprobleme durch die HW/SW aber definitiv aus. Was diesbezüglich mit (m)einem PDA ohne Performanceeinbussen möglich ist, sieht man hier.


    Mit welcher SW ich damals die NMEA-Daten aufgezeichnet hatte, weis ich gar nicht mehr genau. Ich glaube aber es war auf dem PDA der TomTom GPS-Viewer (Treiber) und auf dem PC mit GPS Diagnostics.


    Bis denn
    Hamba

  • Hi @all,


    Ich hab jetzt mal XCPU installiert. Werde heute mal die Taktrate von 400 auf 200 MHz runterfahren und sehen, ob die Karte "hinterherhinkt". Mal sehen ob es an sowas liegen könnte.


    Gruß


    Anderl

    **** ob Desti SP, TTN5 oder MN4.....angekommen bin ich fast immer ****
    !!!! Karte, Kompaß & Höhenmesser haben mich I M M E R ans Ziel gebracht !!!!


    www.eNavTools.de.vu
    Geodätische Koordinatentransformationen am Pocket PC
    Helmertparameter u. m.

  • Hallo hamba,

    Zitat

    Original von hamba


    Ich habe mal theoretisch die Übertragungsmenge (ASCII-Zeichen) ausgerechnet, wenn alle NMEA-Protokolle angeschaltet und auf 1s Intervall eingestellt sind und wenn 12 Satelliten in view sind. Es müssten dann so ca. 484 Zeichen (GGA= 70, GLL = 47, GSA = 53, GSV1 = 71, GSV2 = 71, GSV3 = 71, RMC = 67 und VTG = 34) anfallen. Diese 484 Zeichen ergeben wiederum bei 8 Bit pro Zeichen 3872bit.


    hast Du bei der Berechnung der Protokolllänge pro Protokoll auch jeweils die 2 Zeilenende-Zeichen (CR/LF) berücksichtigt ?
    Im LOG ist ja zu erkennen das jedes Protokoll in einer neuen Zeile anfängt. Wären die 2 Zeichen nicht im Datenfluß hätte man im Protokoll nicht diese "optische" Trennung der Einzel-Protokolle. Zu kontrollieren ggf. mit einem HEX-Editor auf die Protokolldatei.


    Zitat

    Diese 484 Zeichen ergeben wiederum bei 8 Bit pro Zeichen 3872bit. Das ist also weniger als die theoretisch mögliche Übertragungsmenge die pro Sekunde bei 4.800b/s übertragen werden kann.


    bitte nicht mit 8 Bit/Zeichen bei serieller Übertragung rechnen, das ist definitiv falsch. 10Bit sind ein guter Wert.

  • ich denke, solange der genaue Übertragungsalgorithmus nicht klar ist, reden wir über ungelegte Eier. Wenn Start-/Stopbits gesendet werden, wird dies idR nicht zwangsläufig pro ASCII-Zeichen sein, die übertragenen Datenblöcke können auch deutlich grösser sein. Bei synchroner Übertragung werden gar keine Stopbits benötigt, ob diese Art der Übertragung überhaupt angewendet werden kann?


    vg


    Bodo

    iPAQ h2210 ROM 1.1, Haicom HI-303MMF mit Zusatzantenne, Transcend SD 45x 1GB, Kingston SD 512 MB,TTN 5.10/TTT, Checkpoint 5.01

  • Hi,


    start/stop/parity kommen vor/nach jedem Datenbit-block, d.h. 10bit's pro byte sind bei 8N1 korrekt.


    zur veranschaulichung einfach mal googlen, zB hier:
    http://francis.courtois.free.f…ial/Basics/BitFormat.html


    Ein Zeilenendezeichen (EOL) pro Zeile kommt auch dazu, wobei das zwischen 1 und 3 Zeichen lang sein kann (CR oder LF oder CR+LF, und manchmal muß auch noch ein Leerzeichen davor stehen)
    meine Maus sender CR+LF ohne Leerzeichen, also 2 Byte.


    Weiters kann es auch noch einen Protokolloverhead geben, wenn zB das Xon/Xoff oder ACK/NAK Protokoll verwendet wird, was aber m.W. bei NMEA nicht der fall ist.



    hamba's rechnung wird daher wie folgt korrigiert:
    * 484 Zeichen (GGA= 70, GLL = 47, GSA = 53, GSV1 = 71, GSV2 = 71, GSV3 = 71, RMC = 67 und VTG = 34) - wobei ich die Zeichen jetzt aber nicht nachgezählt habe ;)
    * dazu 8 Zeilenumbrüche zu je 2 Byte macht exakt 500 Zeichen
    * diese mal 10 Bit = 5000 bit/sek


    ...und schon sind wir drüber...


    lg,
    Martin

  • Hallo zusammen,


    ja soooooo genau habe ich das nicht ausgerechnet. Ich habe einfach mal den konservativen Ansatz gefahren und einfach nur das gerechnet was ich im Log gesehen habe. Die zusätzlichen CR/LF müssen aus meiner Sicht aber nicht zwingend im Datenstrom enthalten sein. Schließlich wird jeder Satz aller NMEA-Protokolle mit einem CRC-Zeichen beendet. D.h. die empfangende SW muss in der Lage sein das Ende jedes Satzes zu erkennen und könnte die CR/LF beim Loggen auch selbständig anfügen. Ist aber nur eine These. Man sollte das ganze mal tracen.


    Wenn Charly bei seiner Emtac mit 4.800b/s und allen NMEA-Protokollen auf On und 1s Intervall keine Probleme hat, müsste die Datenmenge aber irgendwie doch in die Übertragungsbandbreite passen.



    Anderl,


    glaube mir, mein PDA hat keine Performanceprobleme siehe Text in meinem Posting und den beigefügten Link. Und wenn er die hätte, hätte er bei 38.400b/s ja noch mehr als bei 4.800b/s. Bei 38.400b/s flutscht aber alles.


    bis denn
    Hamba

  • Hi,


    ich lese hier seit einiger Zeit mit und finde die Diskussion recht interessant, wenn sie auch bislang recht theoretisch ist.


    Ich denke, es macht hier wenig Sinn, darüber zu "streiten", ob jetzt ein paar Bit mehr oder weniger übertragen werden (können). Viel interessanter wäre es meines Erachtens, mal zu prüfen, ob die unvollständig übertragenen Daten eine kritische Anzahl von Bytes enthalten (evlt. sogar alle gleich lang sind).


    Hat denn schon jemand die Bytes in den "abgebrochenen" Übertragungen gezählt?


    Ist es evtl. möglich die Baudrate der Maus noch weiter runterzusetzen? Dann müsste sich doch zweifelsfrei nachweisen lassen, ob unvollständig übertragene Protokolle durch eine zu geringe Übertragungsgeschwindigkeit verursacht werde.


    Übrigens, CRLF müssen übertragen werden, da man sich das ganze im "Klartext" im Terminalprogramm ansehen kann


    Gruß, u4

  • Hallo zusammen,


    ich habe jetzt mal einen Trace (mit CommLog) mitgeschrieben, der die bereits durch Rheinhesse, MFS und user4711 betroffene Aussage bestätigt. Es ist auch im Trace eindeutig zu erkennen, dass auch bei meiner GPS-Maus CR (Hex : 0D) und LF (Hex : 0A) mit übertragen werden.


    Trace HEX-Dump :
    Rec :24 47 50 47 47 41 2c 31 37 33 33 34 30 2e 36 32
    Rec :33 2c 35 30 30 36 2e 39 32 34 39 2c 4e 2c 30 30
    Rec :38 33 36 2e 35 30 31 30 2c 45 2c 31 2c 30 37 2c
    Rec :31 2e 30 2c 31 35 34 2e 31 2c 4d 2c 2c 2c 2c 30
    Rec :30 30 30 2a 30 31 0d 0a 24 47 50 47 4c 4c 2c 35
    Rec :30 30 36 2e 39 32 34 39 2c 4e 2c 30 30 38 33 36
    Rec :2e 35 30 31 30 2c 45 2c 31 37 33 33 34 30 2e 36
    Rec :32 33 2c 41 2c 41 2a 35 30 0d 0a 24 47 50 47 53
    Rec :41 2c 41 2c 33 2c 31 33 2c 30 31 2c 32 30 2c 32
    Rec :35 2c 31 31 2c 30 37 2c 32 34 2c 2c 2c 2c 2c 2c
    Rec :31 2e 35 2c 31 2e 30 2c 31 2e 32 2a 33 33 0d 0a
    Rec :24 47 50 47 53 56 2c 33 2c 31 2c 30 39 2c 30 31
    Rec :2c 37 38 2c 30 38 34 2c 33 36 2c 31 33 2c 35 34
    Rec :2c 32 32 33 2c 34 38 2c 32 30 2c 35 32 2c 30 39
    Rec :31 2c 33 31 2c 30 34 2c 35 31 2c 32 39 35 2c 33
    Rec :39 2a 37 32 0d 0a 24 47 50 47 53 56 2c 33 2c 32
    Rec :2c 30 39 2c 30 37 2c 31 37 2c 32 34 32 2c 33 38
    Rec :2c 32 34 2c 31 36 2c 33 31 34 2c 33 37 2c 32 35
    Rec :2c 31 35 2c 30 33 38 2c 33 32 2c 31 31 2c 30 38
    Rec :2c 31 35 34 2c 33 39 2a 37 37 0d 0a 24 47 50 47
    Rec :53 56 2c 33 2c 33 2c 30 39 2c 32 37 2c 30 36 2c
    Rec :31 37 39 2c 32 39 2a 34 37 0d 0a 24 47 50 52 4d
    Rec :43 2c 31 37 33 33 34 30 2e 36 32 33 2c 41 2c 35
    Rec :30 30 36 2e 39 32 34 39 2c 4e 2c 30 30 38 33 36
    Rec :2e 35 30 31 30 2c 45 2c 35 36 2e 32 32 2c 32 36
    Rec :32 2e 36 36 2c 32 36 30 33 30 34 2c 2c 2c 41 2a
    Rec :35 31 0d 0a 24 47 50 56 54 47 2c 32 36 32 2e 36
    Rec :36 2c 54 2c 2c 4d 2c 35 36 2e 32 32 2c 4e 2c 31
    Rec :30 34 2e 31 2c 4b 2c 41 2a 33 43 0d 0a 24 47 50
    Rec :47 47 41 2c 31 37 33 33 34 31 2e 36 32 33 2c 35
    Rec :30 30 36 2e 39 32 31 38 2c 4e 2c 30 30 38 33 36


    Die CR/LF habe ich im HEX-Dump entsprechend Fett markiert. Das NMEA-Intervall im HEX-Dump fängt mit $GPGGA,173340.623, . an (zusätzlich blau markiert) und endet mit $GPVTG,262.66,. (zusätzlich rot markiert). Leider schreibt CommLog in der aktuellen Version 0.4 keine Timestamps mit. Das Timing lässt sich somit nicht erfassen bzw. analysieren.


    Aber ich habe meine Ansicht zur Übertragungsgeschwindigkeit ja schon mehrfach kommuniziert : mehr ist mehr und bleibt auch mehr ;-))) D.h. für mich : unabhängig von der tatsächlich zu übertragenden Datenmenge, macht es in meinem Umfeld - durchaus Sinn die Übertragungsgeschwindigkeit auf der GPS-Maus UND dem PDA/PC auf 38.400kb/s einzustellen bzw. eingestellt zu lassen (läuft ja schon mehrere Monate im täglichen Einsatz so).


    Bis denn
    Hamba



    P.S. CommLog ist ein Freeware Programm für den PDA und kann in der aktuellen Version 0.4 jeden COM-Port auf dem PDA tracen. Guckst Du hier.