Synchronisation von Controllern für Zeitmessung

Gast #4136218
Lesenswert?
• ▲
▼
Hallo,

ich habe ein recht unschönes Problem, für welches mir keine gescheite 
Lösung einfallen möchte.
Ziel ist eine Anlage zur Zeitmessung, welche mit fünf Lichtschranken, 
Atmels und WLAN-Modulen aufgebaut ist. Zur Anbindung wird von einem 
Tablet / Smartphone ein AP erstellt, zu welchem sich alle Einheiten 
verbinden. Die Messungen sollen möglichst vergleichbar und präzise sein.

Das Problem welches sich ergibt, ist die Synchronisation. Da es beim 
WLAN häufiger zu Laufzeiten von bis 10-200ms kommen kann, wäre die 
Messung sehr unpräzise. Aus diesem Grund muss jede Einheit 
beispielsweise einen "TimeStamp" mitsenden. Diesen Timestamp müsste man 
jetzt allerdings unter den Stationen synchronisieren bzw. der 
Auswertelogik einen Offset beibringen zur Korrektur. (Oder eine andere 
Art synchronisierter Takt / Count)

Beispiel:
Einheit 1 löst aus und sendet 14:02:292 (TimeStamp) / 29292 (Ticks since 
Reset)
Einheit 2 löst aus und sendet 14:03:212 (TimeStamp) / 29921 (Ticks since 
Reset)
Einheit 3 löst aus und sendet 14:03:200 (TimeStamp) / 29900 (Ticks since 
Reset)

Offensichtlich waren diese drei Einheiten nicht ausreichend 
Synchronisiert.
Die Synchronisierung über WLAN mit NTP stelle ich mir zu komplex und 
ungenau vor.

Die Einzige Lösung welche mir einfallen würde, wäre wohl ein externer 
Quarz oder RTC + Quarz. Dabei würde man zu Einsatzbeginn alle Einheiten 
mit einer physischen Leitung verbinden und (auf 0) synchronisieren... 
physikalisch aus dem Grund um die Latenz möglichst gering zu halten...

Je genauer und präziser die Zeiterfassung, desto besser. Für Vorschläge 
bzgl. der Komponenten (Quarz  RTC  ????), alternative 
Lösungsvorschläge und konstruktive Kritik bin ich offen :)
#4136264
Lesenswert?
• ▲
▼
Wofür soll die Zeitmessung denn genau sein?

Sind die Einheiten so nah zusammen das man sie mit einer Leitung 
vernünftig verbinden kann? Wenn ja könnte man einen Atmel den "leader" 
spielen lassen und den beginn der messung vorgeben indem er beginnt 
einen Takt zu senden an dem sich alle orientieren (der Leader müsste 
dann als letzter eingeschaltet werden)
#4136269
Lesenswert?
• ▲
▼
Wäre es eine Idee, das von einem 4. Element ein broadcast gesendet wird?

Da senden verzögert sich weil gewartet werden muss bis das Medium frei 
ist. Aber empfangen sollten alle zur gleichen zeit. Vorher in einen 
await sync Modus schalten wo alle anderen Aktivitäten abgeschaltet 
werden um auf empfängerseite keine unnötigen Verzögerungen zu haben. 
(Polling wenn kein IRQ verfügbar ).

Wenn der Sender ein Signal hat wann das Paket gesendet wurde und die 
Verzögerung immer gleich ist  kann man das herrausrechnen. Dann braucht 
es kein 4. Element.

Edit:
evtl kann man mit mehreren Messungen auch die Abweichung herausfinden 
und rausrechnen.
In der wiki gibt es glaube einen Artikel dazu über genaue uhren.
Moderator Persönliche Seite #4136278
Lesenswert?
• ▲
▼
Tim Post schrieb:
> Die Synchronisierung über WLAN mit NTP stelle ich mir zu komplex und
> ungenau vor.

NTP ist alles andere als ungenau, denn es rechnet Laufzeiten komplett 
raus. Allerdings wird NTP oft verwechselt mit SNTP, welches Du 
wahrscheinlich meinst. Bei S(imple)NTP wird tatsächlich nur ein 
einzelnes Mal auf einen NTP-Server zugegriffen und Laufzeiten nicht 
berücksichtigt. Die Komplexität von SNTP ist allerdings sehr gering. Bei 
NTP gebe ich Dir recht.

Aber vielleicht schaust Du Dir mal die Methodik von NTP an, wie die das 
machen und kannst daraus eine eigene Idee für Dich selbst entwickeln...
Gast #4142733
Lesenswert?
• ▲
▼
Hallo,

Danke erstmal an Alle für das Feedback.
Ich habe mich ausgiebig mit den verschiedenen Lösungen beschäftigt.

Ein Kabel zur Synchro wollte ich einfach nicht haben, da es unpraktisch 
ist (vergessen, Erweiterung um neue Sensoren, mechanische Fehler, 
persönlicher Ehrgeiz ;)).

Die Distanz ist leider jedes mal komplett unterschiedlich und kann vom 
ersten bis zum letzten Sender, durchaus mehrere hundert Meter 
betragen... auch ein Grund, weshalb permanente Leitungen unschön wären.

Broadcast klingg wirklich nach einer super Idee und hat mich überzeugt. 
Da ich allerdings auch mal mit Störungen im Frequenzband rechnen muss, 
war es mir schon fast wieder zu unsicher. Grundsätzlich wäre dies aber 
so von mir ungesetzt worden...

Das bisherige 'angebliche' Zeitmesssystem ist nur ein Konzept oder 
Projekt, an welchem ich mal ein wenig Zeit investiert habe. Jeder 
Messpunkt hat ein OCXO mit einer Abweichung <50ppm...


Also. Meine Lösung ist wie folgt:
Jeder Messpunkt bekommt einen GPS-Empfänger mit einem PPS und einer 
Genauigkeit von ~40ns, sowie einen TCXO mit einer Abweichung von <1ppm.

Somit kann sich jeder Messpunkt selbständig die exakte Uhrzeit bis zu 
einer ausreichenden Genauigkeit besorgen, jede Sekunde (ggf häufiger, je 
nach Einstellung) mit dem GPS-PPS korrigieren und die Zeit zwischen den 
Nachrichten mit den TCXO interpolieren...
Gast #4142989
Lesenswert?
• ▲
▼
Jein. Der Zeitempfang ist auch im Gebäude relativ zuverlässig möglich. 
Zusätzlich gäbe es ja auch noch eine RTC, sowie die Möglichkeit eine 
leistungsstärkere Antenne anzuschließen...

Weitere Ideen nehme ich gerne entgegen, allerdings sind diese 
Komponenten so fürs erste vorgesehen und bestellt...


Danke!
#4143061
Lesenswert?
• ▲
▼
Irgendwie sind die Anforderungen etwas unterschiedlich. Zum einem muss 
es ein GPS mit OCXO sein, zu anderen geht auch eine RTC...
Die Beide haben nichts miteinander zu tun. Ein RTC ist nur eine 
Timekeeper, der die Zyklen von einem quarz zaehlt. Wenn man die RTC mit 
OCXO zusammen verwenden wuerde waere man fast so gut wie ein GPS plus 
OCXO.

Antwort schreiben

Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt. Bitte hier nur auf die ursprüngliche Frage antworten, für neue Fragen einen neuen Beitrag erstellen.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.