Wie Synchronisation von Events oder Countern per Funk?

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).

Sntp hast du dir schon angeschaut?

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.

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...