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.

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.

Ja, fällt mir grade ein, dass der Loox ja in einen "Sparbetrieb" geschaltet werden kann. Wenn ich das noch richtig weiß, fährt da der Prozessor Takt runter.

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

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

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

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.