Announcement: there is an English version of this forum on Hallo zusammen, da Funk nicht mein Hauptgebiet ist, hoffe ich auf Denkanstöße und Erfahrungen von euch. Folgendes Problem: Es gibt drei bestehende Messgeräte: Gerät 1 besitzt eine CAN-FD Schnittstelle wo Messdaten mit 1kHz geliefert werden. Zusätzlich gibt es einen AD-Wandlertakt mit 1MHz. Beides steht im feststehenden Koordinatensystem zur Verfügung. Die akkubetriebenen Geräte 2&3 bewegen sich individuell im Raum max. 2m entfernt von Gerät 1. Datenausgabe per Bluetooth LE Modul (Microchip rnbd451) an eine gemeinsame "Bluetooth-CAN" Bridge. Nun besteht der Wunsch die Messdaten zu synchronisieren. Idee 1: Man könnte in jedem Gerät z.B. einen 1ppm Zähler nachrüsten, und jeweils einen Zeitstempel zu den Messdaten mitschicken. Problem ist der initiale Offset zwischen den Zählern. Eine "gleichzeitige" Syncbotschaft über CAN und Bluetooth hat nach diversen Messungen einen Jitter von 20ms ergeben. Neben den unschönen 20ms Jitter durch die Bluetooth Strecke gibt es das Problem, dass die beispielhaften 1ppm Zähler über die Temperatur durchaus auch 50ppm haben können. Idee 2: Irgendeine primitive, möglichst als Modul erhältliche, Funkstrecke um z.B einen initialen Syncimpuls in die Messgeräte zu bekommen um die rtc Zähler zu Nullen. Das Problem mit der temperaturbedingten Drift der Zähler bleibt. Idee 3: Den AD-Wandlertakt aus Gerät 1 in die Geräte 2&3 bekommen um den Takt auch hier als Wandlertakt zu nutzen. Geht auch runtergetaktet, da hier kein großes Oversampling nötig ist. Weitere Salamischeiben die mir akut einfallen: - Lichtimpuls für Syncimpuls nicht möglich, dreckige Umgebung - Initiale Kabelverbindung theoretisch machbar aber im Handling sehr ungeschickt->Notlösung - Schallimpuls für Syncimpuls vmtl unsicher, da Umgebungsgeräusche ausgeblendet werden müssen. -Geräte 2&3 noch relativ variabel in Sachen Hardware -Geräte 2&3 haben etwa die Abmessungen einer Zigarettenschachtel - Ideal wäre ein Vorschlag zu Idee 3, sonst wäre ein Zeitunterschied der individuellen Zeitstempel im Bereich einer Millisekunden innerhalb von etwa 30 Minuten das angedachte Ziel. Ob das realistisch ist.... Hoffe die Grundproblematik ist klar geworden, sonst natürlich gerne melden. Evtl wäre auch ein anderes Unterforum besser? Besten Dank und viele Grüße!
Wenn freier Himmel, und Strom genug vorhanden, wäre GPS eine Möglichkeit. Oder eine genaue Quarzreferenz die eine Uhr betreibt und diese wird alle x Stunden über BT oder WLAN synchronisiert. Da kann man softwaretechnisch die Abweichung vorausberechenen.
:
Bearbeitet durch User
Für Ethernet gibt es IEEE-1588. Hier ist ein Ansatz für BT zu finden: https://ieeexplore.ieee.org/document/9970850 Das hat, wie alles was Präzision heißt, natürlich seinen Aufwand und Preis.
Fabian N. schrieb: > Eine "gleichzeitige" Syncbotschaft über CAN > und Bluetooth hat nach diversen Messungen einen Jitter von 20ms ergeben. Das hört sich eher so an, also ob jemand beim Aufblitzen einer Leuchtdiode die Synchronisationstaste gedrückt hat. Wie genau müssen die Geräte denn synchronisiert werden und wie oft, d.h. wie schnell driften deine Uhren in den Geräten auseinander?
:
Bearbeitet durch User
Rainer W. schrieb: > Fabian N. schrieb: >> Eine "gleichzeitige" Syncbotschaft über CAN >> und Bluetooth hat nach diversen Messungen einen Jitter von 20ms ergeben. > > Das hört sich eher so an, also ob jemand beim Aufblitzen einer > Leuchtdiode die Synchronisationstaste gedrückt hat. Die CAN-Botschaft zu Gerät 1 hat ein recht definierte Übertragungszeit, da ich für die Synchronisation sämtlichen Busverkehr abschalten kann. Die 20ms kommen tatsächlich aus dem Bluetoothmodul. Möglich dass sich da noch etwas machen lässt, aber auch da kenne ich mich zu wenig aus. Ich verwende die genannten Module im "transparent UART" Modus. Soweit ich das nachvollziehen kann, haben die Geräte Zeitslots in denen Sie senden dürfen, wenn ich einen verpasse, lande ich eben im nächsten. Vermutlich sind das in dem Fall hier 20ms? > > Wie genau müssen die Geräte denn synchronisiert werden und wie oft, d.h. > wie schnell driften deine Uhren in den Geräten auseinander? Also Wunsch wäre <5ms für eine Messdauer von min. 5 Minuten. Weniger bzw. länger natürlich gerne. Die Uhrendrift ist noch nicht genau bekannt. Erste Recherchen für ein 1ppm rtc IC ergeben 1ppm bei Konstant 25°C. Da die Geräte aber durchaus einen Temperaturunterschied von 40°C haben können, ergeben sich wohl auch schnell mal 60ppm für dF/F. 1ppm Grunddrift wären 0,6ms in 10 Minuten, mit den angenommenen 60ppm durch die Temperatur wären wir somit deutlich über den gewünschten 5ms. Das schönste wäre natürlich den Synctakt zu übertragen, bzw. einen Bruchteil davon. Damit wäre die Temperaturdrift von Zählern umgangen. Aktuell habe ich überlegt ob man mit einem Ultraschallwandler beispielsweise ein 10kHz Signal aus dem 1Mhz Takt erzeugen kann, welches dann in den Geräten 2&3 detektiert wird.
GPS und dann Absolutzeitstempel. In 'Keller'räumen einen GPS Repeater...
Dein Temperaturdrift ist natürlich ein Problem, aber so als Lowtech-Lösung könnte man doch einfach ab und periodisch an einen Synchronisationspuls per unproblematischem Funk übertragen, mit dem dann der Drift der Uhren kompensiert wird. Das geht sogar im Nachhinein, wenn der Empfänger im Gerät dann in der nächsten Nachricht an die Zentrale die gemessene Zeitdauer mitschickt. Der Synchronisationspuls muss keine Daten übertragen und kann eine echte Lowtech-Lösung sein, man muss eben einmal charakterisieren, wie lange das braucht. Möglich wäre hier z.B. einfach per OOK jede Sekunde eine Nachricht z.B. dreimal hintereinander zu senden, die Synchronisation ist dann am Ende der letzten Nachricht. Das können die mobilen Geräte mit einem entsprechenden Empfänger auswerten und decodieren und dann am Ende der letzten Nachricht den Zeitspeicher auslesen und mit ins nächste Bluetooth-Paket packen. Wenn wir davon ausgehen, dass dein clock drift nicht so extrem ist, dass er sich innerhalb einer Sekunde maßgeblich verhindert, kannst du dann nachher die Zeitstempel einfach abschnittsweise linear interpolieren. Natürlich kann es sein, dass mal ein Synchronisationspaket nicht korrekt empfangen wird, aber dafür sendet man es ja relativ oft, denn auch wenn mal 5 Sekunden zwischen der Resynchronisation liegen, ist das wahrscheinlich nicht wahnsinnig kritisch.
Angehängte Dateien:
-
RV-3032-C7.png
40 KB
Fabian N. schrieb: > Die Uhrendrift ist noch nicht genau bekannt. Erste Recherchen für ein > 1ppm rtc IC ergeben 1ppm bei Konstant 25°C. Da die Geräte aber durchaus > einen Temperaturunterschied von 40°C haben können, ergeben sich wohl > auch schnell mal 60ppm für dF/F. Es gibt RTC ICs mit Temperaturkompensation, z.B. max. ±3ppm von -40 bis 85°C beim RV-3032-C7. Den statischen Offset kann man per Aging Register in 0.24ppm Schritten abgleichen. Edit: Die BEU synchronisiert die diversen Logfiles aus Fahrtenschreibern und Stellwerken nachträglich anhand von markanten Ereignissen, quasi in band Synchronisation...
:
Bearbeitet durch User
Du hast nicht gesagt dass es billig sein muss und dass der Oszillator nur einen verschwindend kleinen Teil des zigarettenschachtelgroßen Geräts einnehmen darf. Daher empfehle ich jetzt einfach mal ein Microchip CSAC-SA65 (Chip Scale Atomic Clock), das sollte auf jeden Fall genau genug sein. https://www.microchip.com/en-us/product/CSAC-SA65 SCNR. So und jetzt zu den realistischen Vorschlägen: Ist schon eine relativ hohe Anforderung mit 1ms Abweichung auf 30 Minuten und das auch noch bei signifikanten Temperaturschwankungen, das entspricht rechnerisch etwa 0.56 ppm. Mit einem Quarzofen (OCXO) wäre das nicht wirklich schwierig, die gibt es inzwischen auch in relativ klein (der ECOC-7050 braucht z.B. nur 7x5mm auf der Platine) aber man hat immer noch eine Aufheizphase (ca. eine Minute) mit reduzierter Genauigkeit und einen signifikanten Stromverbrauch. Wahrscheinlich reicht aber auch ein guter TCXO (z.B. SiT5155). Statt einer direkten Synchronisation der Taktsignale während dem Betrieb würde ich eher unabhängig voneinander messen mit einem halbwegs genauen OCXO/TXCO in jedem Gerät. Wenn man am Anfang und am Ende der Messzeit synchronisiert und je ein Offset bestimmt und dazwischen linear interpoliert wird man damit höchstwahrscheinlich die Anforderung erreichen. Mit nur einer einzigen Synchronisation am Anfang wird das deutlich schwieriger (aber nicht unbedingt unmöglich). Zum Thema Bluetooth-Jitter: Könnte es sein dass das Modul über eine gewisse Zeit (z.B. 20 ms) Daten sammelt und dann als ein Paket überträgt? Dann könnte man zur Synchronisation einfach jede Millisekunde ein Byte an das Modul senden und auf der anderen Seite die Ankunftszeiten der einzelnen Bytes auswerten, damit könnte man theoretisch die Genauigkeit der Synchronisation von 20ms auf 1ms verbessern. Oder man macht mehrere Übertragungen von je genau einem Byte mit Abständen die nicht mit den Zeitslots des Bluetooth-Moduls korrelieren und verwendet am Ende nur die schnellste einzelne Übertragung. Benötigt natürlich etwas Zeit zum Experimentieren aber es ist gut möglich dass man mit solchen Tricks eine deutliche Verbesserung erreichen kann. Absolut verlässlich wird das aber auch nicht, Bluetooth macht automatisch Retransmissions bei Störungen und das erzeugt natürlich auch Jitter - und ein Test in einer störarmen Laborumgebung beweist nicht dass es unter allen Bedingungen zuverlässig funktioniert. Optische Synchronisation über Infrarot würde ich auch nicht völlig ausschließen, gibt integrierte Empfänger mit eingebautem Demodulator (z.B. 38 kHz, ursprünglich entwickelt für Infrarot-Fernbedienungen), da muss man sich nicht um Details wie Photodioden-Verstärker und analoge Signalverarbeitung kümmern. Und die Teile haben eine ziemlich hohe Empfangsempfindlichkeit, das Problem mit Dreck kann man eventuell einfach beheben indem man z.B. 100x stärker als theoretisch nötig sendet, braucht schon eine Menge Dreck um das Signal um 99% zu dämpfen so dass es trotzdem nicht mehr reicht. Eine Sync-LED kann auch helfen so dass der Nutzer merkt wenn es ein Problem gibt und gegebenenfalls den Sensor abwischen kann.
Danke für die Vorschläge und schön, dass es hier auch noch Beiträge ohne Gestänker gibt! Die Variante mit GPS und Absolutzeitstempel finde ich sehr elegant, da sie mir sowohl Drift über längere Zeit, als auch die Anfangssynchronisation löst. Hier hab ich nun mal ein Modul UBlox NEO-M9N besorgt um zu sehen wie sich das empfangstechnisch verhält. Eigentlich wäre mir eine Chip-Antenne lieber (diese ist jetzt auch auf dem Testboard), die normalen Keramikantennen sind hier grenzwertig groß. Zudem wäre ich nicht abhängig von einem weiteren Funkmodul zwecks Zulassung und co. Eine Frage zur Ermittlung von absoluten Zeitstempeln mit 1ms Auflösung hätte ich noch: Wie fusioniere ich die (langsame) Zeitinformation über die NMEA Botschaft mit einem (schnellen) Zeittakt. Ich müsste ja für die Absolutzeit wissen welche Taktflanke genau zur entsprechenden Sekunde zählt. Bei einem Puls je Sekunde ist es natürlich machbar, bei 1kHz ist die Zuordnung aber irgendwie schwierig. Oder braucht man genau dafür dann einen extra GPS-Timing Chip (Neo/LEA-M8T), der zwei einzelne Timepulse-Ausgänge hat? Die RTC ICs haben mich etwas verwirrt. Ich habe nach den besten ppm geschaut und dann die Temperaturdrift für dF/F im Datenblatt gesehen. Es gibt aber wohl welche, wie die vorgeschlagene RV-3032-C7 die grundsätzlich etwas mehr ppm hat, dafür sehr schön temperaturstabil ist. Die Quarzöfen/TCXOs/OCXOs sind natürlich auch schick, Problem ist der höhere Strombedarf. Die Zigarettenschachteln sind Akkubetrieben. Die Infrarotschnittstelle hab ich auch auf dem Schirm, wäre evtl noch eine Notlösung vor der Variante mit Kabel. Etwas ähnliches hab ich schonmal bei etwas anderem gemacht, das hat gut funktioniert. Damals waren die Geräte aber stationär, und nur normaler Werkstatt-Dreck/Staub. Diesmal sind die Einzelgeräte beweglich und haben nicht immer direkte Sichtverbindung. Zusätzlich kommt eben Dreck im Sinne von "Feldweg-Umgebung" dazu. Was die 20ms vom Bluetooth angeht, ist es für mich noch etwas nebulös. Das Modul schaltet, zumindest mit meinem geringen Wissen dazu, selbstständig zwischen einer Einzelbyte-Übertragung und einer Übertragung von mehreren Bytes um. Gefühlt, je nach dem wie hoch die Datenrate ist, die ich übertragen will. Deshalb hatte ich für den Syncimpuls per Bluetooth alles an sonstiger Übertragung abgeschaltet und nur ein Einzelbyte übertragen. Das hatte aber eben diese Schwankung um 20ms. Man könnte natürlich nochmal schauen, was passiert wenn man versucht mehrere Syncbotschaften zeitlich definiert loszuschicken. Evtl. verhält es sich dann zeitlich definierter. Eine Reihe von LEDs für den Anwender wird es sicher geben
Fabian N. schrieb: > Man könnte natürlich nochmal schauen, was passiert wenn man > versucht mehrere Syncbotschaften zeitlich definiert loszuschicken. Evtl. > verhält es sich dann zeitlich definierter. Falls das API es ermöglicht, nach dem programmierten Abschicken einer Botschaft per Software zu ermitteln, wann sie tatsächlich die Antenne verlassen hat, kann man einen Zähler mitschicken, an dem der Empfänger erkennt, ob und welchen Offset (Vielfaches von 20 ms) er einrechnen muss. Nebenbei: Du benutzt hoffentlich den Beacon-Modus? Wenn nicht, findet eine Art Handshake statt, auf dessen Zeitverbrauch du keinen Einfluss hast.
Fabian N. schrieb: > Man könnte natürlich nochmal schauen, was passiert wenn man > versucht mehrere Syncbotschaften zeitlich definiert loszuschicken. Evtl. > verhält es sich dann zeitlich definierter. Falls das API es ermöglicht, nach dem programmierten Abschicken einer Botschaft per Software zu ermitteln, wann sie tatsächlich die Antenne verlassen hat, kann man einen Zähler mitschicken, an dem der Empfänger erkennt, ob und welchen Offset (Vielfaches von 20 ms) er einrechnen muss. Nebenbei: Du benutzt hoffentlich beim Bluetooth den Beacon-Modus? Wenn nicht, findet eine Art Handshake statt, auf dessen Zeitablauf du keinen Einfluss hast.
Fabian N. schrieb: > Eigentlich wäre mir eine Chip-Antenne lieber Vielleicht CAM-M8Q (10x15x3mm)? Obwohl, SAM-M10Q braucht inkl. Keramikantenne auch nur 16x16x7mm. Die M10 brauchen angeblich weniger Strom. Fabian N. schrieb: > Idee 1: > Man könnte in jedem Gerät z.B. einen 1ppm Zähler nachrüsten > Idee 2: > Irgendeine primitive, möglichst als Modul erhältliche, Funkstrecke > um z.B einen initialen Syncimpuls in die Messgeräte zu bekommen um > die rtc Zähler zu Nullen. > Idee 3: > Den AD-Wandlertakt aus Gerät 1 in die Geräte 2&3 bekommen um den Takt > auch hier als Wandlertakt zu nutzen. Idee 1+2+3: Den 1ppm Zähler hat man, wenn man den 1Hz-Takt (RTC oder GPS) benutzt, um den Quarztakt des uC zu regeln. Der 1kHz-Takt kann dann auf µs genau mit dem 1Hz-Takt synchron laufen. Weil nur 1kHz gebraucht wird, geht das auch per Software. Der Start kann per Bluetooth ausgelöst werden, tatsächlich startet die Messung mit dem nächsten 1Hz-Impuls. Also sollte 1Hz als GPS-PPS-Takt reichen. Jetzt müssen "nur noch" die drei 1Hz-Takte synchronisiert werden. Mit GPS gibt's das geschenkt. Der RV-3032-C7 hat einen Eingang, mit dem das auf ±122µs genau geht. Generell fände ich es übersichtlicher, wenn man Idee 3 umdreht, also alle drei Geräte mit der gleichen Technik aus der gleichen Quelle synchronisiert werden. Kann Bluetooth Broadcast? Dann könnte man hoffen, dass der Bluetooth Jitter im Sender passiert und der Fehler für alle drei Geräte praktisch gleich groß wird.
:
Bearbeitet durch User
Fabian N. schrieb: > Was die 20ms vom Bluetooth angeht das connection interval kann eingestellt werden, minimum 7,5ms, default sind halt 20ms bei diesem Modul
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.