Synchronisation bei serieller Schnittstelle über lange Zeiträume

Hallo,

ich zeichne in einem Fahrzeug neben verschiedenen Sensordaten auch die GPS-Position mit 10Hz auf. Dabei werden in einem SubVI über die serielle Schnittstelle NMEA-Daten aufgezeichnet, die NMEA-Sätze getrennt und gespeichert. Daneben wird auch die Systemzeit geloggt. Alle rund 60s kann man in den Systemzeitabständen (meist genau 0.109375 oder 0.09375s, genauer geht's Windows-bedingt nicht bzw. steht kein weiterer Counter/Timer zur Verfügung) Sprünge von um die 0.6s erkennen, während die UTC-Zeit vom GPS in 0.1s Schritten normal weiterläuft. Aus den anderen Sensordaten kann ich schließen, dass die Kommunikation mit der seriellen Schnittstelle hinterher hinkt. Dabei wird die Verzögerung jedoch nicht vollständig kompensiert und summiert sich immer weiter, nach 8min hänge ich 5s hinterher. Einen ähnlichen Effekt konnte ich bereits beim Ansteuern eines Radars über die serielle Schnittstelle feststellen und das umgehen, indem nun Pulse über Counter gezählt werden, da bin ich nicht direkt auf die serielle Schnittstelle angewiesen. Das geht beim GPS jedoch nicht.
Wie kann ich die Kommunikation mit dem seriellen Port synchronisieren? Gibt es einen anderen Weg als über die VISA-Geschichte. Der andere Weg wäre die UTC-Zeit als Basis zu nehmen, nur vertrau ich der genauso wenig wie der Systemzeit und zusätzlich ist die nicht immer verfügbar, hat da jemand Erfahrungen was zuverlässiger ist?

P.S.: Was ist eurer Erfahrung nach die maximale Anzahl gleichzeitig (und dazu noch unter verschiedenen Baudraten) zu nutzender COM-Ports?

Grüße,

PAX

' schrieb:Wie kann ich die Kommunikation mit dem seriellen Port synchronisieren?

Ohne Synchronisation geht es ja gar nicht, wie wird es denn z.Z. bei Dir synchronisiert? Ohne Antwort auf diese Frage ist es gar nicht möglich, zu Deinem Problem ewas Sachdienliches zu sagen.

Die beiden gängigen Methoden sind:
1.) Taktung von Datenempfänger.
Der Daten-Sender arbeite als Slave und sendet nur nach Aufforderung durch den Master.
2.) Taktung vom Datensender aus.
Der Daten-Sender sendet autark und ohne Aufforderung. Das Ende eines Datenblockes wird mit TermChar, z.B 0xA, markiert. Die Datenempfangsschleife mit VISARead wartet auf das Eintreffen von TermChar, dann wird der Datenblock aus dem Puffer gelesen und verabeitet. (Es schadet auch nicht, wenn Window manchmal mit etwas anderem beschaftigt und VISA Read von LabVIEW nicht zeitgerecht bedient werden kann. Es sammeln sich dann mehrere Datenblöcke im Empfangspuffer an, die aber bei den folgenden, schnelleren Iterationen wieder abgebaut werden)

In Beiden Fällen ist es nicht möglich, daß das Einlesen hinterherhinkt - vorausgesetzt natürlich, die Zeit für das Verabeiten der Daten ist kürzer als die Datenrate des Senders.

Das Dümmstmögliche, was man ab und zu sieht, ist, daß bei Methode 2 in die Datenempfangsschleife ein Wait hineingebracht wird, in der irrigen Annahme, daß sei für die Synchronisation notwendig. Das Gegenteil ist der Fall.

Hallo,

ich arbeite schon nach der 2. Methode mit TermChar und habe fürs GPS heute anscheinend meinen Fehler gefunden, nach 15min war entweder 1 GPS-Satz verschluckt oder die Zeit um 0.1s auseinandergelaufen, aber das ist mir genau genug. Das Problem am Anfang war, das die 3 Nmea-Sätze GGA,GST sowie RMC in keiner geordneten Reihenfolge, jedoch meist als Packet zeitlich nah zusammenhängend gesendet werden. Bei einer Main-Loop-Time von 0.1s bei gleicher GPS-Rate habe ich nun entweder Glück und alles passt ins Zeitfenster oder eben nicht. Läuft es einmal synchron dann ist das auch stabil. Also hab ich für die ersten 4s ein Zeitfenster zum Initialisieren eingeräumt, in dem ich bei Asynchronität eine Änderung der Main-Loop-Time um 80ms zulasse, dann fängt sich das ganze recht schnell. Leider war irgendwo noch ein leeres VISA-Read dazwischen, das beim Experimentieren irgendwann eingefügt jedoch nicht wieder entfernt wurde und somit für die ganze Verzögerungsgeschichte verantwortlich war. Das klingt wahrscheinlich alles ziemlich abenteuerlich aber scheint mir die einzig funktionierende Möglichkeit, NMEA-Sätze haben nunmal leider auch keine feste Länge oder Struktur (auch wenn es ein Standard ist, sind die Strukturen je nach Zustand andere, leere Sätze haben z.B. wesentlich mehr Datenfelder als eben jene bei Empfang...). Ich hoffe, dass ich das Problem beim Radar nun auch noch beheben kann, wenn gleich da der Fehler wo anders liegen muss.

Die alte serielle Schnittstelle wird auf neueren Systemen eher stiefmütterlich behandelt, hab ich das Gefühl. Leider kann ich sie nicht ganz umgehen...

Achso zum Thema wait: ist das gänzlich überflüssig? An anderer Stelle verwende ich auch die serielle Schnittstelle und leere zunächst den Buffer wonach sich ein wait anschließt. Diese Struktur habe ich nun schon öfter gesehen und daher übernommen, aber generell warte ich schon ungern. Macht das an dieser Stelle Sinn oder eher nicht?

Grüße,

PAX

' schrieb:Achso zum Thema wait: ist das gänzlich überflüssig? An anderer Stelle verwende ich auch die serielle Schnittstelle und leere zunächst den Buffer wonach sich ein wait anschließt. Diese Struktur habe ich nun schon öfter gesehen und daher übernommen, aber generell warte ich schon ungern. Macht das an dieser Stelle Sinn oder eher nicht?

Ja, ich weiß, daß man es ab und zu sieht, das macht die Sache aber nicht besser. Die Wait-Funktion in der Empfangsschleife übernimmt aber doch bereits Visa Read. Es wartet solange, bie eines dieser "Ereignisse" eintritt:
Entweder "TermChar" oder "Timeout" oder "Anzahl Bytes" (Inputwert) erreicht.

Wenn man bei Inbetriebnahme (Initialisierung) der Datensender schon läuft und man plötzlich anfängt die Daten zu empfangen, kann ja so einiges schief gehen. Ideal wäre, wenn das Abhören gemau in der Pause zwischen zwei Datensätzen beginnen würde. Es kann aber genausogut passierien, daß man mitten in einen Datensatz oder sogar mitten in ein Byte hineinhört. Um das abzufangen, muß man solange lessen, bis es keinen Rahmenfehler mehr gibt. Von da an ist der erste Datensatz möglicherweise noch nicht vollständig, aber ab nächsten Datensatz ist die Synchronisation für immer hergestellt.
Trotzdem kann es auch beim normalen Enpfang sinnvoll sein, den Fehlerstrang immer nach Rahmenfehlern abzufragen und den Datensatz auf richtige Bytelänge zu kontrollieren. Alles was nicht OK ist kommt in den Müll - und nicht in die Datenauswertung.

Alles klar, danke. Ich werde einfach mal alle wait-Elemente rauslöschen und schaun, ob noch alles funktioniert. Soweit bin ich mit dem GPS ja jetzt zufrieden, Ramenfehler traten bis jetzt nicht auf und die Daten kommen sauber. Das ganze ist mitlerweile schon ein recht komplexes Programm, sobald eine Sache abgeschlossen ist bemerkt man wieder Fehler am anderen Ende. Grad hab ich einen Counter der zuviel zählt, Messergebnisse über die serielle Schnittstelle sind hier in Ordnung, aber beim Counter hab ich Tagesabhängig mal zuviel oder auch mal zuwenig. Sehr verwirrend, die Counter der NI-PCI-Devices hatte ich bisher immer als sehr zuverlässig eingeschätzt. Naja ich werd mir erstmal das Signal ansehn und den Counter mit einem Pulsgenerator überprüfen, soll hier jetzt aber auch nicht das Thema sein.

Vielen Dank auf jeden Fall für die Unterstützung,

PAX