Synchronisation bei serieller Schnittstelle über lange Zeiträume

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