Hallo zusammen, ich suche eine prinzipielle Vorgehensweise, um Events in einem System aus mehreren Slaves und einem Master per Funk zu synchronisieren. Mein Setup besteht aus * 1 Master, bestehend aus einem Embedded Linux System * 1 bis 50 mobile Slaves, basierend auf XMega CPUs und etwas Peripherie * Funkverbindung basierend auf 802.15.4 Modulen (MRF24J40 von Microchip) und eigenem Protokoll-Stack Die Kommunikation erfolgt nur zwischen Master und Slaves, nicht zwischen den Slaves untereinander. Der Master sendet in regelmäßigen Abständen Kommandos an die Slaves, die diese eigenständig ausführen. Zusätzlich sollen zu vorab definierten Zeitpunkten auf Master und Slaves gleichzeitig und unabhängig von der Funkkommunikation vordefinierte Aktionen ausgeführt werden. Die Aktionen haben einen Abstand von wenigen Sekunden, der maximale Jitter sollte im Bereich von 50 ms liegen. Mein Ansatz besteht darin, auf Master und Slave Counter zu starten und bei Erreichen von vordefinierten Werten die definierten Aktionen zu starten. Wie kann ich diese mit der geforderten Genauigkeit synchronisieren? Ich habe mir hierzu NTP angesehen, halte es jedoch für zu komplex, um es auf den XMegas zu implementieren bzw. auf den Protokoll-Stack zu portieren. Vielen Dank schon einmal vorab!
Wenn du 50ms jitter haben darfst.. warum löst du die aktionen nicht direkt per trigger vom master aus..? mehrere clients über eine verlustbehaftete schnittstelle zu syncen ist echt ätzend. du wirst schon etwas in der komplexität von ntp brauchen..
alternativ, wenn du sowas wie broadcasts kannst, kannst du natürlich auch einfach regelmäßig eine zeit broadcasten, und die clients die jeweils übernehmen lassen. dann musst du dir nur noch überlegen was du mit aktionen machst die durch die zeitkorrektur evtl plötzlich in der vergangenheit liegen...
dunno.. schrieb: > Wenn du 50ms jitter haben darfst.. warum löst du die aktionen > nicht > direkt per trigger vom master aus..? > > mehrere clients über eine verlustbehaftete schnittstelle zu syncen ist > echt ätzend. du wirst schon etwas in der komplexität von ntp brauchen.. Dafür gibt es verschiedene Gründe: 1. die Aktionen müssen mit hoher Zuverlässigkeit ausgeführt werden, d.h. auch dann, wenn ein Datenpaket nicht durchkommt; da die MRF24J40 im 2.4 Ghz Band operieren, ist ein gewisser Datenverlust immer vorhanden 2. die Kommunikation erfolgt immer per Unicast (aus Sicherheitsgründen), d.h. alle Clients müssten individuell getriggert werden, was ein hohes Datenaufkommen und hohen Jitter nach sich zieht
dunno.. schrieb: > alternativ, wenn du sowas wie broadcasts kannst, kannst du > natürlich > auch einfach regelmäßig eine zeit broadcasten, und die clients die > jeweils übernehmen lassen. dann musst du dir nur noch überlegen was du > mit aktionen machst die durch die zeitkorrektur evtl plötzlich in der > vergangenheit liegen... Hatte ich auch erwogen, ich fürchte jedoch, dass ich damit den geforderten Jitter nicht erreiche. Die Verzögerung durch die Übertragungsstrecke sowie Drift der lokalen Oszillatoren müsste ich vmtl. zumindest rudimentär berücksichtigen.
wie lange dauert es denn, ein kommando vom master an den slave zu schicken, im worst case..? gibts ne fehlerkorrektur? wenn das unterhalb 50ms ist -> super. übernimm einfach direkt die zeit.. wenn nicht -> dann musst du die abweichung messen, und landest wohl zwangsläufig bei etwas was wie ntp aussieht..
dunno.. schrieb: > wie lange dauert es denn, ein kommando vom master an den slave zu > schicken, im worst case..? gibts ne fehlerkorrektur? > > wenn das unterhalb 50ms ist -> super. übernimm einfach direkt die zeit.. > > wenn nicht -> dann musst du die abweichung messen, und landest wohl > zwangsläufig bei etwas was wie ntp aussieht.. Die Dauer zwischen Absetzen des Kommandos auf dem Master und Verarbeiten auf dem Slave kann durchaus > 100ms liegen (Fehlerkorrektur, Re-tries), daher fürchte ich, dass ich nicht ohne ein Synchronisation auskomme. Daher die Frage, ob es ggf. auch einfachere Verfahren als NTP gibt (insbesondere ohne bzw. mit einfacheren statistischen Verfahren).
Hat der rfPCI eventuell sowas wie einen SOF (Start of Frame) Ausgang? Ich hatte quasi das gleiche Problem, damals mit den TI Funkchips und MSP430 als Controller. Ich hab das dann folgendermaßen gelöst: Der SOF Ausgang hing beim Master und bei den Controllern an einem Capture Pin des Timers. Der Timer lief mit einem Uhrenquarz. Bei jedem Paket wurde auf beiden Seiten beim Start des Frames dann ein Zeitstempel abgelegt. Dann hatte ich zwei Sync-Pakete implementiert, beim ersten nimmt der Slave den Zeitstempel und beim zweiten schickt der Master seinen Zeitstempel des ersten Paketes zum Slave. Damit kann der seine interne Uhr nachstellen (Timer-Differenz). Das muss halt zyklisch ausgeführt werden. Somit kam ich auf einen Jitter von +- 30µs etwa (Uhrenquarz-Takt).
Christian R. schrieb: > Hat der rfPCI eventuell sowas wie einen SOF (Start of Frame) > Ausgang? > Ich hatte quasi das gleiche Problem, damals mit den TI Funkchips und > MSP430 als Controller. Ich hab das dann folgendermaßen gelöst: > > Der SOF Ausgang hing beim Master und bei den Controllern an einem > Capture Pin des Timers. Der Timer lief mit einem Uhrenquarz. Bei jedem > Paket wurde auf beiden Seiten beim Start des Frames dann ein Zeitstempel > abgelegt. Dann hatte ich zwei Sync-Pakete implementiert, beim ersten > nimmt der Slave den Zeitstempel und beim zweiten schickt der Master > seinen Zeitstempel des ersten Paketes zum Slave. Damit kann der seine > interne Uhr nachstellen (Timer-Differenz). Das muss halt zyklisch > ausgeführt werden. Somit kam ich auf einen Jitter von +- 30µs etwa > (Uhrenquarz-Takt). Leider verfügt der MRF24J40 nicht über einen SOF Ausgang. Ich verstehe Dein Protokoll so: 1. Master sendet Sync-Paket 1 und speichert Zeitstempel 2. Slave empfängt Sync-Paket 1 und speichert Zeitstempel 3. Master sendet Sync-Paket 2, dieses enthält den Zeitstempel des ersten Sync-Pakets Wie rechnest du dann die Dauer für die Übertragung heraus? Benötigst Du nicht 2 x Zeitstempel von jeweils Master und Slave?
dunno.. schrieb: > Sntp hast du dir schon angeschaut? Habe ich mir kurz angesehen, nach meinem Verständnis ist das zwar das selbe Protokoll wie NTP, alerdings ohne jede Form von Korrektur.
Idee: Master an Slave: . ID Slave an Master: . Zeit "Vollständig Empfangen" (Slavezeit) . ID . Zeit "Beginn Senden" (Slavezeit) Beide Pakete haben die selbe Länge. Master hat: A=Zeit zwischen "Begin Senden" und "Vollständig Empfangen" am Master B=Zeit zwischen "Vollständig Empfangen" und "Beginn Senden" am Slave C=Slavezeit Vollständig empfangen D=Slavezeit Beginn senden An Master und Slaves die Zeiten für Senden/Empfangen/Berechnen bestimmen. Der Rest ist Übertragungsstrecke. Keine Retries. Dann die Slave-Zeit vorsichtig nachführen. Eventuell muss D in einem zweiten Paket von Slave an Master geschickt werden, weil der Slave vielleicht nicht weis, wann er senden kann. Alternativ auch: "vollständig gesendet" Slavezeit
:
Bearbeitet durch User
Mit den zwei Zeitstempeln habe ich den Timer der Slaves auf den des Masters synchronisiert. Die normale Uhrzeit in UTC wurde extra noch übertragen. Die Verzögerung zwischen den SOF Ausgängen lag im ns Bereich, war vernachlässigbar. Der Funk geht ja mit nahezu Lichtgeschwindigkeit.
DisplayFreak schrieb: > 2. die Kommunikation erfolgt immer per Unicast (aus Sicherheitsgründen), Das ist kompletter Unsinn. Unicast erhöht gegenüber Broadcast die Sicherheit in keinster Weise, insbesondere nicht in einem Funknetz. Dort ist nämlich physisch sowieso jedes Paket ein Broadcast-Paket und wird höchsten logisch zu einem Unicast-Paket. Wenn Sicherheit eine Rolle spielt, dann mußt es Verschlüsselung geben. Dann kann man zwischen Unicast und Broadcast unterscheiden. Aber selbst dann gibt es keinen Grund, auf Broadcast-Dienste zu verzichten, die werden einfach mit einem anderen Schlüsselpaar abgewickelt und fertig ist der Lack. > d.h. alle Clients müssten individuell getriggert werden Aus einer falschen Voraussetzung kann man allerdings nur falsche Schlußfolgerungen ziehen. Das gute alte "shit in->shit out"-Prinzip...
Es geht ihm sicher (wie mir damals) um die Sicherheit, dass das Paket auch ankommt. Ich hab das damals trotz aller Versuche mit Broadcasts nur mit Unicasts mit aktiver Bestätigung und Retransmits hinbekommen. Dann war es auch störfest gegenüber WLAN und BT.
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.