Allgem. Einstellungsfragen, z.B. Baudrate

  • @all,


    dieser Thread soll auf allgemeine Frage eingehen, die bei Problemen mit der Navigation auftreten. Ausgangspunkt ist hier zunächst der Thread


    http://www.pocketnavigation.biz/board/addreply.php?postid=231495&sid=


    Hier ist von hamba ein Verweis auf einen weiteren Thread, in dem die Frage gestellt wurde, ist die Einstellung der COM-Port Geschwindigkeit evtl. verantwortlich für ein "Nachhinken" bei der Navigation. hamba hat dazu 2 logs gepostet, einmal langsam, 4800 Baud und einmal schnell, 38400 Baud.


    Ich habe nun beide logs angesehen und kann bezüglich der Frage, gibt es bemerkbare Unterschiede in der Aufzeichnung, keine solche sehen.


    Leider kann ich das Excel-File - so wie es momentan existiert - nicht anhängen, da es auch gezippt die übertragbare Größe überschreitet. Da muss ich mir mal was überlegen.


    Aber mal eine Grundsatzfrage, hier möchte ich um Beteiligung von entsprechenden Experten bitten.


    Ausgang war wie hamba andeutete, wenn die Schnittstellengeschwindigkeit hoch gesetzt wird, gibt es keine "Nachhink"-Probleme.


    Da die beiden logs vollständig sind, also keine Lücken, Unterbrüche aufweisen, muss zunächst davon ausgegangen werden, dass der Datenstrom von der Maus egal welche Baudrate eingestellt ist, den PDA und die Navi-SW erreicht. Denn das log wird ja über die Navi-SW zur Aufzeichnung geschickt. Das wirft jetzt schon eine weitere Frage auf: Was besagt eigentlich die COM-Port-Baudrate? Ist es nicht so, dass die Geschwindigkeit mit der die Maus Daten liefert garnicht beeinflusst werden kann? CruxView als Programmierprogramm bietet jedenfalls keinen Programmierpunkt mit dem die Datenübertragungsrate beeinflußt werden kann.


    Was also bewirkt die Baudrate-Einstellung der Schnittstelle? Geschwindigkeitsfilter? Wenn dann aber auch bei 4800 Bd die Daten vollständig ankommen würde das die bestätigen, die sagen, 4800 reicht allemal.


    Dann müsste der Grund wo anders liegen. Z.B. das GSV-Protokoll. Es wurde verschiedentlich gepostet, dass GSV mit einer Wiederholrate = 1 zum "Nachhinken" führt. Bei TTN wäre eine mögliche Erklärung:


    das GPS-Modul läuft ja immer mit. Dort werden aus dem GSV-Prot die Sat-Balken und die Stellungsanzeige in der "Himmeldarstellung" generiert. Nun weiß man, dass Grafikanzeigen Zeit kosten. Ist das der Knackpunkt? Dass bei GSV=5 nur 1/5 der Daten in die Grafik umgesetzt werden müssen, könnte das eine Erklärung sein.


    So, mehr fällt mir momentan nicht ein. Mal sehen, ob noch jemand was dazu beitragen kann.

  • Hallo Charly,


    Zitat aus Wikipedia:


    "Da es keine Taktleitung gibt, die die Übertragung synchronisiert, muss auf beiden Seiten der Übertragungstrecke dieselbe Übertragungsgeschwindigkeit (in Baud) eingestellt sein, damit die Übertragung klappt.


    Pro übertragenem Datensatz (Byte) wird die Übertragung mittels des Startbits eingeleitet. Serielle Übertragungen funktionieren grundsätzlich aber auch ohne Startbit.


    Darauf folgen 5-8 Datenbits (Nutzdaten), wahlweise ein Parity-Bit und schließlich ein oder zwei Stoppbits.


    Da alle diese Variationen in den Standards nicht festgelegt sind, müssen bei beiden Geräten, die an der Kommunikation beteiligt sind, die Parameter gleich eingestellt sein, bevor eine erfolgreiche Kommunikation zustande kommen kann."


    Also wenn ich mir das so überlege, dann komme ich zu folgendem Schluß, ob der richtig ist weiß ich nicht???


    Die Baudrate muß an beiden Geräten gleich sein, sonst geht nix. Man kann aber bekanntlich nur den Port am PDA verändern nicht die Maus. Demzufolge müsste in der Maus eine automatische Geschwindigkeitsanpassung stattfinden. Könnte es also sein, daß in der Maus bei einer niedrigeren Baudrate ein Zwischenspeicher fungiert? Dann wäre es ja denkbar, daß die Maus mit einer Zeitverzögerung die zwischengespeicherten Daten an den PDA sendet. Damit wär das hinterherhinken erklärt.
    Gegen diese Theorie spricht aber, daß der Zwischenspeicher ja nicht beliebig groß sein kann. Was passiert also wenn dieser dem Überlauf nahe ist??


    Also das war meine Theorie. Vielleicht wars ja ein Denkanstoß, der uns dem Ziel näher bringt.


    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. Ja. Nein. Weiß nicht.


    Das mit der gleichen Geschwindigkeit hat ja schon was für sich. Das mit Zwischenspeicher aber auch.


    Aber: von Hamba liegen 2 logs vor, das eine 1/2 h, das andere knapp 1h lang. Eines mit 4800, das andere mit 38400 Bd.


    Gegen beide Versionen spricht, dass alle beiden logs keine Abbrüche oder so zeigen, also offensichtlich störungsfrei übertragen wurden. Das spricht einerseits gegen gleiche Geschwindigkeit, aber auch gegen Anpassung in der Maus - woher sollte sie auch wissen, dass sie die Geschwindigkeit ändern soll.


    Auch Zwischenspeicher erscheint wenig zutreffend, denn nach einer h sollte da schon jeder Speicher zu sein - soviel Speichplatz würde kaum spendiert werden.


    Was mich momentan etwas stört, den logs nach wurden sie - evtl. - nicht mit einem Navi-Prog sondern vielleicht mit einem Tool aufgenommen. Das könnte die Verhältnisse etwas ändern, da Tools weniger Zeitprobleme als NaviProgs haben sollten. Ob dabei aber mehr herauskommt könnte auch wieder nur ein Versuch zeigen.


    Vielleicht sollte4 man mal wieder ein Usertreffen bei Navigon ins Auge fassen, diesmal evtl. mit der Bitte um Aufklärung, wie die Verarbeitung des von der Maus kommenden Datenstromes erfolgt. :]

  • Hallo Charly,


    könntest Du mir die Log's mal per Mail zukommen lassen?


    Würde mich mal interessieren.


    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.

  • Bitte mal kontrollieren:


    ich habe mal ein wenig gezählt - zählen lassen, Excel - pro Protokollzeile war das Maximum 56 Zeichen, das sind 608 Bit - mit den Trennkommas.


    GGA/1, GLL/0, GSA/1, GSV/5, RMC/1, VTG/0.


    Bei allen aktivierten Protokollzeilen, 5 + 3*GSV = 8, gibt das 600 *8 (608 war nur in GGA, alle andere lagen unter 560) = 4800 bit. Alle mit 1 sec aktiviert passt das ja noch in 4800 Baud. Richtig?


    Das würde doch die bestätigen, die immer schon meinten, 4800 Bd reicht aus. Schon gar wenn GSV auf 5 steht.


    Kommentare???

    Viele Grüße, Charly


    Quod licet Iovi, non licet bovi

    Einmal editiert, zuletzt von karomue ()

  • Hallo Charly,


    VORSICHT !!! Bit ist nicht gleich Baud!!!


    Kurzinfo:
    Baud (=Schrittrate): Anzahl der Zustände eines Signals pro Sekunde.
    Bitrate: Anzahl der übetragenen bits pro Schritt multipliziert mit der Baudrate,

    Baud-und Bitrate gehören zu den meistverwechselten Begriffen der Datenfernübetragung (DFÜ). Die Baudrate wird nach J.M.E. Baudot, dem Erinder des Baudot Telegraphen Codes benannt. Es gibt die Schrittgeschwindigkeit und nicht die Übetragungsgeschwindigkeit an und drückt aus, wie oft in der Sekunde eine Signal-(oder Daten-)Übetragung stattfindet. 600 Baud bedeuten demnach, da&zlig; 600 mal in der Sekunde eine Signalübetragung (=Schritt) vonstatten geht. Einheit von Baud ist 1/s. Erst wenn bekannt ist wieviel bits pro Schritt übertragen werden, kann man die Bitrate ermitteln, die in bps (bits per second) gemessen wird. Diese wird ermittelt, indem die Baudrate mit der Anzahl der bits multipliziert wird, die bei einem Schritt übetragen werden.


    Zustand ist der Möglichkeitsraum, den ein bit einehmen kann (per Definition des bit-Begriffs = 2). Zwei Zustände werden durch 1 bit, 4 Zustände durch 2 bits, 8 Zustände durch 3 bits, 16 Zustände durch 4 bits (oder: 1 Quadbit) codiert , allgemein: x Bit codieren x2 Zustände.



    " Baud ist nicht dasselbe wie BPS
    -------------------------------


    Die Einheit Baud (1/s) hat die definierte Bedeutung: Schritte pro
    Sekunde. Mit Schritten sind diskrete Signalaenderungen gemeint.
    Die Einheit BPS (Bit/s) ist zwar aehnlich, beschreibt aber die
    Anzahl der bits pro Sekunde. Es muss einfach mal gesagt werden,
    dass die zwei Ausdruecke absolut nicht dasselbe sind. Es ist
    naemlich durchaus moeglich, mit einem Signalschritt mehr als nur
    1 Bit zu uebertragen


    Ich weiß nicht ob wir da momentan auf dem Holweg sind??


    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,


    ich habe jetzt nicht alles versucht zu verstehen.


    Aber ist es nicht so, dass ein ASCII-Zeichen durch die Zustände "0" und "1" gekennzeichnet ist, und 8 Bit lang. Damit sollte doch schon mal ausgeschlossen werden können, dass mehr Zustände übertragen werden.


    Außerdem ist "meine" Version doch dann die ungünstigste, werden mehr Zustände übertragen, passt auch mehr pro Zeiteinheit rein, also kann mit 4800 Bd noch mehr übertragen werden als meine Annahme.


    Kann das so bestätigt werden?

  • Hallo Charly,


    Oh Du lieber Gott lass mich bitte wieder Fahrzeuge konstruieren so wie ich das gelernt habe!!!! (mein Hilfeschrei).
    Also langsam wirds mir trotz Schmalspur-Informatik-Ausbildung zu hoch (Kfz-Informatik).


    ASCII und 8 bit ist richtig. Zumindest ohne erweiterten ASCII-Satz nur darfst Du das nicht mit der Baudrate gleichsetzen. Wenn ich das richtig sehe, dann beschreibt die Baudrate sozusagen die Frequenz, mit der die Schaltzustände "wechseln". Im Grunde gebe ich Dir schließlich recht.


    Ich denke aber, daß vielleicht ein anderer, empirischer Weg uns vielleicht weiterbringen würde.
    Woran ich denke, ist eine parallele Logaufzeichnung mit gleicher Hardware aber unterschiedlicher Baudrate. Wenn man dann die "Zeitstempel" der zugehörigen Koordinaten vergleicht wäre zu prüfen ob es da Unterschiede gibt. Allerdings müsste man dazu noch eine externe Zeit miteinbinden. Irgend etwas in der Richtung. Ich hab nur noch keinen konkreten Lösungvorschlag für so einen Versuch ?( ?( ?(


    Ist jetzt wahrscheinlich total bescheiden formuliert, aber ich kanns irgendwie nicht richtig in Worte packen, sorry.
    Ich hoffe Du weißt worauf ich hinaus will.


    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.

  • <lach>


    nein, das weiß ich nicht! :D


    Und ich schrei mal mit: welcher Teufel hat mich geritten, mein gemütliches Rentnerdasein mit solchen Problemen "aufzuwerten"... :(


    Aber ich möchte mich auch ungern in die Tiefen begeben, da ich da so den Zauberlehrling schemenhaft sehe.


    Aber im Ernst: hamba hat ja 2 logs - steht schon unten - mit extrem unterschiedlicher Baudrate gepostet. Es gibt auch keine Zeitunterbrüche, soweit ich die tausende von Zeilen richtig gelesen habe. :]


    Und vielleicht könne wir uns darauf einigen, wenn wir Bit/sek gleich Baud setzen, habe wir einen der möglichen Ansätze. Bei allen anderen - mehr Zustände oder so - bringe ich mehr Zeichen / Zeiteinheit rein, also bei 4800 Baud eben mehr als 4800 Bit / sek.


    Ich habe leider kein spezielles Wissen über Baud, habe aber Deine Einwände fast wortwörtlich auch gelesen - ohne sie jetzt im Detail auch zu verstehen.


    Wir wollen doch nur wissen, passt ein komplettes Protokoll, alle Zeilen auf 1 gesetzt, in das Übertragungsraster: komplettes Protokoll innerhalb 1 sek übertragen. Und das können wir - glaube ich - annehmen.

    Viele Grüße, Charly


    Quod licet Iovi, non licet bovi

    Einmal editiert, zuletzt von karomue ()

  • Schlußwort



    Meines Erachtens sind 4800 B/s für eine Navi ausreichend.


    Ich denke Du stimmst mir zu.


    War auf alle Fälle interessant, Charly.


    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, man hat mich gerufen, da bin ich!


    Gott sein dank habe ich mich erfolgreich über 11 Semester theoretischer Informatik gequält :-D)


    So will hier mein Wissen ebenfalls noch abgegen. Anderls ausführen haben mich sehr an meine Vorlesungen erinnert, wie immer nix verstanden, unterschied zwischen heute und damals: seinerzeit durfte ich das nicht zugeben und musste den Herren Professoren vorgauckeln, den ganzen Quatsch verstanden zu haben.


    Ich sehe das so:
    das Baud ist ganz klar mit bit per Sekunde definiert, ein "Mass" das weitgehend die der Datenübertragung verwendet wird. Auf deutsch: wieviels Bits flutschen in der Sekunde über eine Leitung. Es handelt sich um asynchrone Datenübertragung, das heisst es gibt keinen Takt, der das übertragene Bit kennzeichnet (das wäre dann die synchrone Übermittlung). Folge daraus ist tatsächlich, das Sender und Empfänger wissen müssen, mit welcher Geschwindigkeit die Daten übertragen werden müssen. Um zu Beginn abzukären, ob das klappt, werden Handshakes ausgetauscht, dann wissen beide, das es losgehen kann. Intelligente Systeme können zudem die Geschwindigkeit zwischen Sender und Empfänger in gewissen Grenzen aushandeln, wer erinnert sich nicht an die netten Pfeiforgien, als wir noch mit Modems ins Internet (nein Besser in irgenwelchen dubiosen Boards) eingewählt haben. Ich hoffe, das sowir alle mit mir konform gehen (wo bei der Unterschied zwischen Bitrate und baudrate nicht wirklich klar ist).


    So, jetzt geht das ganze DIngen noch weiter. Das was die Maus an nmea-Commands ausspuckt und wir zwangsläufig als "Byte" interpretieren muss nicht zwangsläufig ein Byte (oder eine Menge an Bytes) sein. Der geneigte Programmierer erinnert sind daran, dass es verschiedene Werte gibt (byte, single, double, string boolean und weis der Teufel was sonst noch). Soll heissen, das da zwar ein 47,12345 als Koordinate kommt, was wir als Mensch als 8Byte (=8 Zeichen inkl. Komma) interpretieren, für eine digitales System ist das uU 2 Byte oder 4 Byte. Ich will damit erkläten, das Charlys gezählte 600 Zeichen nicht unbedingt als 600 Byte übertragen werden, dazu müsste aber den genauen Aufbau der Datenstruktur erkennen. ME werden das aber deutlich weniger als 600 Byte/Zeile sein.


    So, nun meine Ansicht, wie so eine Maus tut: bestimmt hat die Maus einen Speicher, aber nicht im Sinne eines Massenspeichers wie Festplatte sondern als Zustandspeicher (ja so was gibt es zB bei der klassischen Moore-Maschine). Da heisst, die Maus schreibt Ihre GPS Daten in dem Zustandspeicher. Da die gemeine NMEA-Maus nicht mehr als einem Hertz (!!) Daten liefern kann, wird dieser Zustandsspeicher als max. einmal in der Sekunde upgedatet. In der Regel wird so ein Zustandspeicher in Form von Registern abgebildet. Nach meiner Theorie stehen als ein endliche Anzahl von Registern für die diversen Unterprotokolle zur Verfügung (andere Möglichkeit wäre, dass diese Register geteilt verwendet werden, also erst für GGA reserviert, dann für VTG.... glaube ich aber nicht wirklich, denn dann müsste Bei GSV=5 jeder 5 fünfte GGA wegfallen, von allen anderen Sätzen ganz zu schweigen)


    Auf der anderen Seite wird diese "Schnittstelle" vom Übertragungsprogramm ausgelesen und an einen in diesem Fall PDA übertragen. Die Geschwindigkeit dieser Übertragung wird dann in der Maus eingestellt wie auch auf dem PDA zB in TTN. Sollten die angeforderten Daten mit einem Rutsch übertragen werden können, also zB innerhalb der 4800bit, wird ein ziemliches Problem entstehen (also wenn zB 5000bit zu Übertragen wären würde ich nicht alle Daten in der Mausupdatezeit rüberbringen). In dem Fall müsste man also die Übertragungsgeschwindigkeit nach oben drehen.


    Von Interesse wäre nun also, inwiefern unterschiedliche Daten zwischen einer Übertragung mit 4800 oder 9600 (also der doppelten Datenmenge) übertragen werden. Nach meiner Theorie müssten also vom Timestamp abgesehen bei 4800 einmal der Satz X kommen, bei 9600 zweimal der Satz X (also mit der gleichen Information, es ist mir schon klar, dass hier x verschiedene nmea-Sätze ankommen). Das würde also heissen, dass bei höheren Datenübertragungsrate kein Bit mehr an nutzbaren Daten rüberkommt.


    Alles wilde Spekulation!! Erst müsste man mal Wissen, wie die kleine Blackbox "GPS-Maus" wirklich aufgebaut ist. Aber in E-Technik war nun wirklich eine Pfeife...


    Bzgl. der Teilfrage "schadet es, gewisse nmea-Sätze öfters zu senden" würde ich sagen, dass wahrscheinlich nicht die Übertragung das Problem ist (sonst wäre das Problem bei schnellerer Übertragung weg), sondern wie Charly auch vermutet die Weiterverarbeitung.


    so, jetzt ein Bier und dann TTN3.0neu installiert!


    vg


    Bodo



    PS: noch eine Anmerkung zu internen Speicher: meine Theorie, dass die Maus keinen Massenspeicher hat, wird mE dadurch gestützt, dass die Hersteller nicht damit "angeben". Sonst würde auf jeder Umverpackung stehen: mit 100kByte SPeicher oder so ähnlich; zudem hätte dann schon lange jemand 1MByte oder mehr eingebaut.

    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

  • Hallo Bodo,


    sehr interessant, aber ich fürchte, um wenigstens einen Teil zu verstehen müsste ich das ausdrucken. ;D


    Ja, Anfang der 50er Jahre wurde das bei uns nicht behandelt. Computer - diesen Commodore mit der Zwergentastatur - gab es erst Jahre später, "Modems" tauchten meine ich noch später auf: diese Backsteine, in die man einen Telefonhöhrer drücken konnte, die mit der Wahnsinnsgeschwindigkeit von 300 Baud (dreihundert!), die die Buchstaben etwa "hack...Pause...hack...Pause..." auf den Monitor stanzten... :D


    Gut, aber können wir uns einigen, beschränken: übertragen werden Texte in ASCII, freilaufende Geschwindigkeit der Maus, Maus jagt raus was sie hat ohne Puffer. Die logs von hamba zeigen bei beiden Geschwindigkeiten weder fehlende Sätze noch doppelte oder mehrfache, was über die mitgeliefere Zeit kontrolliert werden kann. Also muss es wohl eine asynchrone Übertragung sein, die unter oder bei 4800 Baud liegt.


    Wollen wir mal wieder an den Ausgangspunkt zurückdenken, woher kommt das Hinterherhinken, kann hamba mit seiner Theorie recht haben, dass eine höhere Geschwindigkeitseinstellung das Problem löst?


    Nachdem sich jetzt wohl gezeigt hat, dass auch bei allen aktivierten Protokollzeilen und einem Wíederholinterval von 1 sek alle Daten innerhalb 1 sek auch bei Einstellung 4800 Baud durchkommen, muss die Ursache im PDA oder in der Verarbeitung der Navi-SW liegen.


    Zustimmung???

  • Zustimmung: ja! bis auf den Ziegelstein und dem Telefonhörer: das war ein Akustikkoppler; wow, was waren das für Zeiten!!

    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

  • Hallo Bodo,


    << Akustikkoppler; wow, was waren das für Zeiten >>


    hach, ja. Und wie begeistert war ich von meinem ersten 2.400er Modem ... :)


    Viele Grüße, Sven