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.

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 Anderl,

die logs von hamba stehen hier:

http://www.pocketnavigation.de/board/tid22763-sid.htm

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???

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?

<lach>

nein, das weiß ich nicht!

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.

Hallo, man hat mich gerufen, da bin ich!

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

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.

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...

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!!