Allgem. Einstellungsfragen, z.B. Baudrate

Zitat

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

CDI Informationssysteme Gmbh & Co Computer KG
Tauentzienstr. 1 D1999 Berlin 30
Tel (030) 24 60 15...

(Stimmt wahrscheinlich lngst nicht mehr)

Serien-Nr 06444. htrans Modem heißt das Ding und liegt neben mir...

Hihi,

"Achtung! Hörer richtig herum einsetzen (s, Abb.) Für beste Übertragungsergebnisse Koppler in Seitenlage betreiben!"

Nostalgie, Nostalgie...

(ich hatte das schon einen PC (8086) und habe mitleidig C64 und Schneiderfreunde geblickt!)

Hallo,
zur der ursprünglichen Frage möchte ich mal folgendes einwerfen:
in der PC-Welt kann 4800 Baud mit 4800 Bit/sec. gleichgesetzt werden, da wir bei der Übertragung nur 2 Zustände haben.
Ein Zeichen wird mit 8 Bit übertragen, dazu kommen ein Start- und ein Stopbit. Wenn man jetzt noch den Handshake (Hardware oder Software je nach Geräten) unterschlägt muß man mit 10 Bit pro übertragenem Zeichen rechnen.
Das heißt, das in einer Sekunde max. 480 Zeichen übertragen werden können.
Da das NMEA-Protokoll kein Binär- sondern ein ASCII-Protokoll ist wird eben eine Zahl (z.B. 12,123456) mit 9 ASCII-Zeichen zu je 8 (10) Bit übertragen.
Weiterhin ist zu beachten, das bei jedem empfangenen Zeichen von der COM-Schnittstelle ein Interrupt ausgelöst wird, damit das Programm die Zeichen abholt (haben PDA's FIFO Speicher ?)
Das belastet die NAVI-Applikation, die permanent zum Zeichenabholen unterbrochen wird. Es ist für die Application besser wenn sie sich nicht permanent mit der Abholung der Zeichen am COM-Port beschäftigen muß sondern.

Halo Jürgen,

danke. 10 bit, hm. Da müsste man jetzt nochmal genau zählen, hier könnte es jetzt eiin wenig eng werden mit 4800 wenn alle Prot auf 1 stehen. Das könnte nun der häufig zu sehende Grund sein, dass GSV auf 5 steht.

Zitat

Ein Zeichen wird mit 8 Bit übertragen, dazu kommen ein Start- und ein Stopbit. Wenn man jetzt noch den Handshake (Hardware oder Software je nach Geräten) unterschlägt muß man mit 10 Bit pro übertragenem Zeichen rechnen.

das würde ich so jetzt nicht stehen lassen...

Zitat

Da das NMEA-Protokoll kein Binär- sondern ein ASCII-Protokoll ist ....

ich habe nmich mit dem Thema tatsächlich nicht tiefer beschäftigt, aber das würde ich auch bezweifeln! ASCII ist ein Highlevelzeichensatz, der vom Prinzip ausschliesslich zur Visualisierung vom maschinenverständlichen Binärcode dient. Der nmea-Datenstrom ist nun wirklich sehr maschinennah (bzw. mausnah :gap ), es würde technisch gar keinen Sinn machen, so etwas in ASCII-Form umzurechnen und dann zu übertragen!

Wenn jemand nähere Links zum Aufbau vom SIRF-Chipsatz hat bzw. zur Definition des NMEA-Protokolls bzw. deren Übertragung würde mich das sehr interessieren, mal nachlesen, von was wir hier so sprechen....

vg

Bodo

Hallo zusammen,

ich bin leider erst Heute wieder Online und hab daher den Thread erst jetzt gesehen. Gelesen habe ich die zwei Seiten verständlicherweise noch nicht vollständig. Erstmal nur überflogen.

Mir drängt sich aber spontan die Frage auf : hat einer von Euch meinen Thread überhaupt gelesen ? Oder soll ich jetzt alles was ich dort rein geposted habe, hier als Erklärung noch mal posten ?

Das was Ihr hier bzgl. der theoretischen Übertragungstechnik diskutiert geht aus meiner Sicht am Ziel vorbei und trifft die ursprüngliche Fragestellung in keinster Weise. Die Übertragung Protokoll- und Parameter-mäßig - zwischen meiner GPS-Maus und dem PDA waren definitiv in Ordnung. Lediglich das Timing also die zu übertragende Datenmenge und die dafür zur Verfügung stehende Zeit passten bei 4800b/s nicht zusammen. Mein PDA ich habe ja glaube ich geschrieben, dass ich es auch mit meinem Notebook verifiziert hatte hatte absolut kein Performanceproblem. Nochmal : jeder aktuelle PDA sollte aus meiner Sicht mit jeder aktuellen Navi-SW über GPS-Daten, die mit 38.400b/s übertragen werden, lachen. Wenn nicht, ist der PDA oder die Navi-SW nicht für die Navigation geeignet. Just my opinion ;-))) Diese meine These/Meinung wurde aber bisher in keinem meiner Threads oder Postings zu diesem Thema eindeutig widerlegt.

Das sich mit jedem guten Mäuseprogrammiertool z.B. WinFast Navigatgor (denn kenne ich auswendig, bei anderen dürfte es aber ebenso sein) - auch die Übertragungsgeschwindigkeit in der Maus einstellen lässt ist wahrscheinlich inzwischen klar.

Ich habe in diesem Thread ja geschrieben, dass die 4.800b/s theoretisch wohl gerade so ausreichen müssten. In der Praxis zumindest bei meiner GPS CF-Karte ist das aber nicht so siehe LOGs. In dem Log mit der langsameren Speed (4.800b/s) ist definitive nicht die komplette NMEA-Sequenz also alle eingestellten Unterprotokolle innerhalb des Intervalls enthalten. Bei der langsamen Speed bricht die Übertragung der NMEA-Sequenz einfach ab. Dann braucht die GPS CF-Karte eine Pause welche zu einem konstanten Nachlaufen führt und dann beginnt die nächste NMEA-Sequent also das nächste Intervall wieder von vorne. Das kann man doch in den Logs eindeutig sehen, oder ? Der von mir vermutete Hintergrund für dieses Verhalten ist, dass die (meine SiRFstarII) GPS-Maus offensichtlich bestimmte Dinge nicht parallel sondern sequentiell erledigen muss. Ich kann mangels fehlender Alternativmäuse aber natürlich keine Gegentests machen. Es ist daher erst einmal eine subjektive Meinung von mir. Deshalb habe ich ja den Thread geschriben. Damit hatte ich mir von interessierten Experten eine entsprechende Reaktion d.h. deren Erfahrungen - erhofft. Hat nun einer von Euch das mal mit seiner Maus ausprobiert ? By the way : natürlich kann ein komplexes Navi-Programm weitere Verfälschungen bringen. Deshalb sollten die Test so wie bei mir mit einem einfachen GPS-Viewer, der in der Lage ist NMEA-Logs zu schreiben, gemacht werden.

Wenn aber keiner von Euch Interesse an dem Thema hat und keine Lust hat eigene Tests zu machen, kann ich das aber auch nachvollziehen. Dann ist das Posting hier wie viele andere von mir :-((((( in anderen Threads halt das letzte Posting., hoffe ich.

Ich hoffe mal ich habe beim überfliegen der ganzen Postings nix wesentliches verpasst.

@ pug304,
eine relativ gute Quelle für Informationen zu den SiRFstar Chips und das NMEA-Protokoll ist SiRF Inc selbst. Infos zum detaillierten internen Aufbau des Chips dürften aber eher unter Betriebsgeheimnis fallen und nur schwer zu finden sein. Da ich aber kein Hardwaredesigner bin, würde ich damit eh nicht so Wahnsinnig viel anfangen können. Mir geht es auch nicht unbedingt darum die Ursache eines vorhandenen Verhaltens absolut zu verstehen. Sondern eher darum zu erfahren, ob das Verhalten nur bei meiner Maus so ist oder auch bei anderen.

Bis denn
Hamba

P.S. nicht das jetzt wieder einer meint ich wäre überempfindlich oder schnippig. Ich bin ganz normal höchstens ein bisserl Müde - und geh deshalb jetzt auch in die Koje.

Hallo,
leider kann ich mich an der Detailanalyse der LOG-Dateien nicht beteiligen aber

Zitat

Original von pug304

das würde ich so jetzt nicht stehen lassen...

Was spricht hier dagegen ? Kennst Du den Aufbau des RS232-Protokolls ?
Normalerweise ist als Parameter auf den beiden Gegenstellen 8N1 eingestellt
- 1 Startbit (immer fix definiert)
- 8 Datenbit
- No Parity (ggf. 1 zusätzliches Bit bei Even oder Odd)
- 1 Stopbit (ggf. auch 2 möglich)

Wenn man von einer Dreidrahtverbindung (Masse, TxD, RxD) ausgeht muß man auch noch die Bits des Overhead für das Software-Handshake (Xon / Xoff) von Brutto-Übertragungsvolumen abziehen.
Also ca. 460 ASCII-Zeichen / Sec. bei 4800 Baud !!!

Zitat

ich habe nmich mit dem Thema tatsächlich nicht tiefer beschäftigt, aber das würde ich auch bezweifeln! ASCII ist ein Highlevelzeichensatz, der vom Prinzip ausschliesslich zur Visualisierung vom maschinenverständlichen Binärcode dient. Der nmea-Datenstrom ist nun wirklich sehr maschinennah (bzw. mausnah :gap ), es würde technisch gar keinen Sinn machen, so etwas in ASCII-Form umzurechnen und dann zu übertragen!

Wenn jemand nähere Links zum Aufbau vom SIRF-Chipsatz hat bzw. zur Definition des NMEA-Protokolls bzw. deren Übertragung würde mich das sehr interessieren, mal nachlesen, von was wir hier so sprechen....

vg

Bodo

Alles anzeigen

Das NMEA-Protokoll mit seinen Unterprotokollen ist eindeutig ein ASCII-Protokoll. Man kan z.B. mit einem Terminal-Programm auf dem COM-Port die Daten in Klarschrift mitlesen.
Aufbau der Daten siehe z.B. Doku von karomue: HIER
oder auch bei NMEA: HIER
ASCII ein Highlevelzeichensatz ?? Dies ist einer der ältesten Zeichensätze in der EDV überhaupt (ursprünglich 7 Bit aus Amerika).

Im Gegensatz hierzu ist das SIRF-Protokoll ein Binärprotokoll.

Hallo hamba,

nu schlaf Dich erst mal aus. ;D

Ich kann Deinem letzten Thread nicht so ganz folgen. Ich habe Deine beiden logs angesehen, kann aber keinen Unterbruch in der zeitlichen Abfolge vom 1 sek-Intervall feststellen (beim langsamen selbstverständlich). Bei genauerem Hinsehen aber habe ich jetzt gesehen, dass das VTG Prot, das sonst zwischen RMC und GGA steht, ab und zu fehlt, z.B. bei 173517.617.

Soweit ich jetzt gesehen habe, ist es aber nur diese eine Zeile die fehlt, und das kommt bei 2144 ausgewerteten GGA-Zeilen genau 16 mal vor. Das sind, wenn ich richtig gerechnet habe ;D , 0,75%.

Also, gebe mal nähere Details damit wir das nachvollziehen können, falls wir weitermachen sollten.

Ach, Rheinhesse: der Neuigierde halber: wie macht man das mit dem Terminalprogramm? Irgendwie habe ich das bislang nicht geschnallt, würde mir das gerne mal am NB ansehen. Habe eine BT-Maus und einen BT-Adapter.Damit kann ich auch am NB "GPS"-len, z.B.mit VisualGPSXP.

Bitte Detailanweisung "für Anfänger". Telegrammstil sollte aber reichen.

Hallo Charly,

jo, das zeitweise fehlen ausbleiben - des VTG-Protokolls in der Log mit 4.800b/s ist genau der Punkt. Das VTG-Protokoll bleibt immer dann aus, wenn durch eine 3. GSV Sequenz eben mehr Daten zwischen der Maus und dem System (PDA oder PC) übertragen werden müssen. Das wiederum tritt ein, wenn mehr als 8 Satelliten in View sind.

Wieso kommst Du aber nur auf 16 fehlende VTG-Zeilen ? Ich habe mir wegen der doch etwas größeren Datenmenge ein kleines Perl-Script geschrieben, das die Logs durchgeht und neben der Ausgabe der GPS-Daten in ein Excel-File auch die Anzahl der Ausgabezeilen pro Protokoll auflistet.

Bei der Auswertung mit meinem Perl-Script komme ich bei der 4.800er Log auf :
2161 GGA-Zeilen
2161 GLL-Zeilen
2161 GSA-Zeilen
5186 GSV-Zeilen
2161 RMC-Zeilen
1840 VTG-Zeilen

Da aber VTG während des gesamten Loggings ebenfalls auf 1s Intervall eingestellt war, müssten hier auch 2161 Zeilen in der Log sein. Es fehlen somit insgesamt 2161 - 1840 = 321 VTG-Zeilen. Das entspricht dann 14%.

Die gleiche Auswertung der 38.400er Log bringt folgendes Ergebnis :
3111 GGA-Zeilen
3111 GLL-Zeilen
3111 GSA-Zeilen
6222 GSV-Zeilen
3111 RMC-Zeilen
3111 VTG-Zeilen

Hier fehlt also nach meinem Perl-Script keine einzige VTG-Zeile.

Die Gegenprüfung mit anderen Tools (UNIX-Tools : grep, wc) haben die Ergebnisse des Perl-Script bestätigt. D.h. das Script ist grundsätzlich o.k.

Die restliche Auswertung der 4.800er Log hatte ich dann über ein Excel-Sheet gemacht (liegt bei). Darin ist zu sehen, dass ab 18:33:51 (local time, d.h. in der Log ab 173351,622 UTC-Time) die VTG-Sequenz sporatisch ausbleibt. Ab 18:43:12 (= 174312,588 UTC) just ab dem Moment, als von 9 nur noch 8 Sats in View waren - ist die VTG-Sequenz dann wieder konstant da.

Bis denn
Hamba

Hallo Hamba,

stimmt. Ich habe einen Fehler bei mir entdeckt.

Kam daher, dass ich alle RMC-Zeilen extrahiert hatte, dann die Zeitdifferenz auf >1 sek abgefragt. Da kamen halt - nur - 16 Fehlstellen.

Soweit, so - un- - gut.

Aber: prüfe mal Dein Perl-Script, ich meine das ist auch nicht o.K.

Meine Auswertung sieht jetzt so aus:

GGA 2161
GLL 2161
GSA 2161
GSV 5186
RMC 2144
VTG 1840 Zeilen,

d.h. RMCs fehlen auch. Daher - vermutl. - mein Fehlergebnis. Schau mal bei den Zeiten 17:35:13, 16, 25 da sind RMCs und VTGs nicht da.

Fazit würde ich mal sagen: Deine Beobachtung, dass bei Aktivierung aller Protokollzeilen auf Intervall 1 sek die Übertragungsrate von 4800 Baud nicht ausreicht, ist wohl bestätigt.

Wieweit das jetzt merkbare Auswirkungen hat - RMC und GGA enthalten die Koordinaten, was TTN auswertet wissen wir nicht, von MN wissen wir, dass es nur GGA sein kann, denn sowohl die älteren als auch die neueren benötigen nicht RMC zwingend. Und GGA ist ja voll da.

Bliebe noch ein Performance-Problem. PDA? Navi-SW?

Auch das wissen wir nicht, wir können nur die Auswirkungen bemerken, und das ist - zumindest bei manchen Anwendern (alle???) so, dass GSV=1 zum Nachhinken führen kann. Muss???

Das schnelle log habe ich nicht mehr speziell untersucht. Ich meine, dass wir nun genügend Infos besitzen um sagen zu können, GSV sollte auf 5 eingestellt werden.

Hamba: eine Art Abschlußkommentar???

Generell: man sollte auch die eigenen Ergebnisse immer anzweifeln. Wäre schön, wenn mir das das nächste Mal
auch einfallen würde. ;D

Zitat

Bitte Detailanweisung "für Anfänger". Telegrammstil sollte aber reichen.

hallo Charly,

nimm einfach HYperterminal (unter Programme|Zubehör|Kommunikation)

(erst mal BT konfigurieren und COMx einrichten) Aufrufen. COMx auswählen, uU DFÜ-Paramter ändern und los gehts!

vg

Bodo

Hallo karomue,

Zitat

Original von karomue
Ach, Rheinhesse: der Neuigierde halber: wie macht man das mit dem Terminalprogramm? Irgendwie habe ich das bislang nicht geschnallt, würde mir das gerne mal am NB ansehen. Habe eine BT-Maus und einen BT-Adapter.Damit kann ich auch am NB "GPS"-len, z.B.mit VisualGPSXP.

Bitte Detailanweisung "für Anfänger". Telegrammstil sollte aber reichen.

Aber gerne. Ich kann hier momentan nur für Windows (Notebook) sprechen, entsprechende Terminal-Programme sollte es aber auch für PDA's geben.

• Start des mitgeliefertren Terminal-Programms unter Windows (HyperTerminal)
• Neue Verbindung definieren auf entsprechenden COM-Port mit GPS-Maus (kein Modem wählen, sondern COMx analog zu Einstellung in VisualGPS)
• Anschlußeinstellungen festlegen (4800 Bit/sec, 8N1)

und schon läuft der ASCII-Output der Maus im Terminal-Fenster (Klarschrift der Übertragung). Ein Log-File läßt sich auch einschalten. Da ich eine englische Windows-Version am laufen habe kann ich Dir die genauen Menübefehle nicht sagen (Transfer / Capture Text ...)

Hallo Rheinhesse,

ein AHA-Erlebnis. Nu konnte ich auch mal den Header der Emtac sehen.

Danke, habe mich zwar selten mit HyperTerminal beschäftigt - zu Modems-Zeiten mal - wusste also nicht, dass man sooo einfach auch COM-Ports mitschreiben kann...

Hallo karomue,

schön das ich auch mal mit Tips helfen konnte

Läßt sich aber nur bei ASCII-Daten verwenden. Binärdaten lassen sich ggf. mit einem Hex-Editor analysieren.