Wie kann ich mehrere in verschiedenen Räumen verteilte digtale Systeme
möglichst genau synchronisieren, sodass sie exakt zueinander passende
Aktionen ausführen?
Nehmen wir als vereinfachtes Beispiel einen Laser, der in einem
bestimmten Rythmus pulsen muss und eine Elektronik, die zum richtigen
Zeitpunkt empfangen muss und einen Sensor der das "fotografieren" soll.
Es kommt dabei auf die Helligkeitsauswertung an, d.h. die
Belichtungszeit muss stimmen. Der Sensor darf deshalb nicht deutlich
früher oder später zugemacht werden, als der Laser pulst, weil sonst
Rauschen mit in das Signal kommt.
Leider sind die Zeitmessungen im Bereich von 10kHz mit einer 1/100
Shutterfunktion, d.h. die Belichtungszeiten liegen bei 1 us und sollten
ihrerseits auf 1/1000 genau sein. Ich brauche also eine Genauigkeit auf
die 1/2 Nanosekunde und besser.Einfach eine Synchronleitung legen reicht
in dem Fall sicher nicht aus. Auch die Idee einen LWL zu nehmen habe ich
nicht verfolgt. Ich kann die einzelnen Einheiten mit einem Hochgenauen
Quarz ausrüsten, aber selbst der Beste ist nicht 100% stabil und ich
habe noch immer das Problem, dass die in den Subsystemen verbauten
Schaltungen keinen 100% einheitlichen Puls sehen.
Theoretisch könnte ich mit einer Elektronik den Laserblitz auswerten und
exakt bis zum nächsten warten (die Periode liesse sich sicher erfragen)
die Lichtgeschwindigkeit abziehen und dann auslösen, aber es gibt noch
ein Problem: In einem System steckt z.B. ein Mikrocontroller, der nur
mit 20 MHz läuft. Wie bekommt ich es hin, dass er einen Ausgang auf die
Nanosekunde genau schaltet?
Ich habe schon diese beiden Beiträge angesehen, aber die waren noch
keine Hilfe:
Beitrag "Oszillator synchronisieren"Beitrag "Mehrere MCUs synchronisieren - wie?"
Die einzige Chance wirklich im Nanosekundenbereich exakt zu sein, ist
das Versenden von Triggerinformationen mit einem TimeCode, ab dem etwas
passieren soll und das dezentrale Vorhalten einer systemweit
einheitlichen "Urzeit". Der Aufbau muss so erfolgen, wie in einem FPGA,
bei dem der interne Takt auf zero skew zum Eingang gestellt wird und
zudem Laufzeiten berücksichtigt werden.
Du brauchst eine zentrale, hochgenaue PLL mit Leitungen zu allen
Komponenten und darin jeweils wieder eine hochgenaue träge PLL als
Filterung. Ob an der Stelle ein LWL einen Vorteile bringt, wäre ich mir
nicht sicher, da es in dem gesamten Clockpfad eine Reihe von analogen
Unsicherheiten gibt. Du hast ja Treiber in Richtung der Komponenten und
in denselben auch wieder analoge Taktaufbereitung. Könnte man aber
probieren.
In jedem Fall muss diese gesamte Kette eintrainiert werden, indem man
sie aktiv vermisst (gfs sogar im Betrieb) und justiert, d.h. die
Zeitverzögerung vorkompensiert.
Ich würde einen FPGA nehmen und die Ausgänge über Eingänge vermessen,
die ihrerseits über eine ähnliche Mechanik vermessen und kompensiert
wurden. Dann hast Du weitgehend kalibrierte Ausgänge, über die Du
Zeitsignale senden und Eingänge über die Du welche empfangen kannst. Du
brauchst eine komplementär aufgebaute Rückmeldung für den Takt. Dann
schiebst Du die Ausgänge so hin, dass die Phasen rechnerisch stimmen.
Auf diese Weise sind systematisch sicher 100 - 200 ps drin + einigem
zufälligen Jitter in ähnlicher Grössenordnung.
Die Zeitsymbole werden in ähnlicher Weise parllel versendet, z.B. mit
einem seriellen Protokoll, das Gerät, Aktion und relativen Zeitpunkt
festlegt. Dann sendest Du alle Trigger mit ausreichendem zeitlichen
Vorlauf, zur Sicherheit aus redundant und bist in allen Geräten mehr
oder weniger synchron. Dann muss nur noch die interne Verzögerung durch
deren Verarbeitung ins Spiel gebracht werden.
Bei Deinem Mikrocontroller wird es natürlich insofern schwierig, als
dass der ohnehin nur alle 20MHz reagieren kann. Du müsstest also den
Takt des Mikrocontrollers auch von Aussen vorgeben und in der Phase
regeln und zudem alle Zeitabläufe mit 20MHz rastern, also in 50ns
Paketen denken. Ist das bei der APP überhaupt zulässig? Wichtig ist
auch, dass der Mikrocontroller mit einem starren timing arbeitet, das
berechenbar und komplett bekannt ist.
Um die gesamte Kette genauer zu bekommen, liessen sich gfs. mehrere
Taktzweige parallel aufbauen und eintrainieren und deren
Summeninformation als Trigger auswerten. Wenn es sehr genau werden soll,
müss die Schaltgüte im Bereich der FPGA-Ausgänge gesteigert werden,
damit sie keinen unnötigen Jitter induzieren und man muss sich eine
intelligente Vermessung einfallen lassen.
@ Ralf (Gast)
>ihrerseits auf 1/1000 genau sein. Ich brauche also eine Genauigkeit auf>die 1/2 Nanosekunde und besser.Einfach eine Synchronleitung legen reicht>in dem Fall sicher nicht aus.
Warum nicht? Wenn man die gleich lang macht, kommt da locker hin. 1/2 ns
~100mm Lauflänge auf normalem Kabel.
> Auch die Idee einen LWL zu nehmen habe ich>nicht verfolgt.
LWL ist nicht viel anders als Koax oder Twisted Pair.
>Theoretisch könnte ich mit einer Elektronik den Laserblitz auswerten und>exakt bis zum nächsten warten (die Periode liesse sich sicher erfragen)>die Lichtgeschwindigkeit abziehen und dann auslösen, aber es gibt noch>ein Problem: In einem System steckt z.B. ein Mikrocontroller, der nur>mit 20 MHz läuft. Wie bekommt ich es hin, dass er einen Ausgang auf die>Nanosekunde genau schaltet?
Indem die kritischen Sachen komplett in Hardware ablaufen, ohne jegliche
Software.
Was für ein tolles physikalisches Experiment soll das denn sein?
Ralf schrieb:> Auch die Idee einen LWL zu nehmen habe ich nicht verfolgt.
Warum nicht. Um Modendispersion zu vermeiden, solltest du allerdings
Singlemode-Fasern verwenden.
короткое троль schrieb:> Scheint ein Furz zu sein. Eher etwas in Richtung von Pink-Elephant...
???
Technologies
To achieve sub-nanosecond synchronization White Rabbit utilizes
Synchronous Ethernet (SyncE) to achieve syntonization and
IEEE_1588 1588 Precision Time Protocol (PTP).
короткое троль schrieb:> Scheint ein Furz zu sein. Eher etwas in Richtung von Pink-Elephant...
so mal es keine Gleichzeitigkeit gibt.
(http://de.wikipedia.org/wiki/Relativit%C3%A4t_der_Gleichzeitigkeit)
auch wenn die Baugruppen eine Aktion gleichzeitig starten und einen
anderen Abstand zu ziel haben, braucht das Licht auch schon wieder Zeit
bis es da ist. Wenn nun aber das Licht gleichzeitig ankommen soll, dann
müssen die Baugruppen zu unterschiedlichen Zeiten das Signal absenden.
Die Lichtgeschwindigkeit wird bei solchen Anwendungen natürlich
rausgerechnet, bzw. -gemessen. Die Positionen sind ja in diesem Fall
sicherlich bekannt oder zumindest zu ermitteln. Eine gewisse
Unsicherheit wird letztlich immer bleiben, schon mal wegen des nicht
100% deterministischen, weil rauschanfälligen Schaltverhalten der
Bauteile in der gesamten Kette. Die Distanz/Laufzeitkompensation des
Lichtwegs ist da das kleinste Problem. Selbst mit einfachsten Mitteln
sind Positionen auf einige cm zu bestimmen und das wären dann nur noch
Bruchteile von Nanosekunden.
Mit einem System aus varianten Laufwegen / Doppelspiegeln und mindestens
einer Umlenkung bekommt man auch Schwingungen von Systemen in den Griff
und kann sich auf Zehntel Millimeter bestimmen. Da macht das
Bauteilrauschen und dessen Wirkung auf den Jitter erheblich mehr aus.
Das Projekt von Cern sieht interessant aus. Je mehr Systeme da
mitwirken, desto sicherer und rascher bestimmbarer wird die absolute
Zeit. Die genaue lokale Zeit geht dann sowieso über einen lokalen
Zeitgeber, der in der Phase hingezogen wird, womit wir dann so langsam
wieder hier sind:
Beitrag "2 FPGA - Clocks gewaltsam synchronisieren"
Falk Brunner schrieb:> Warum nicht? Wenn man die gleich lang macht, kommt da locker hin. 1/2 ns> ~100mm Lauflänge auf normalem Kabel.
Es sind aber bis zu 10m alles zusammengerechnet. Ich brauche es schon
genauer und eine gleiche Länge ist nicht garantierbar,
> Was für ein tolles physikalisches Experiment soll das denn sein?
Forschung sozusagen
Jürgen Schuhmacher schrieb:> Um die gesamte Kette genauer zu bekommen, liessen sich gfs. mehrere> Taktzweige parallel aufbauen und eintrainieren und deren> Summeninformation als Trigger auswerten.
sowas hatte ich auch schon vorgesehen und zwar deshalb, um die Zeittakte
plausibilisieren zu können. Könnte man auch so nutzen, stimmt.
> Die Lichtgeschwindigkeit wird bei solchen Anwendungen natürlich> rausgerechnet, bzw. -gemessen.
Die Laufzeit, die das Licht benötigt ist bei uns Teil des Messwertes :-)
Martin schrieb:> EtherCAT => Distributed Clocks ( bis 1ns Jitter)
Quelle?
Meine Quellen sagen für EtherCAT wesentlich mehr... (Bereich 50 bis 100
ns)
Darum habe ich hier bisher nichts vorgeschlagen, da weder IEEE1588v2
noch EtherCAT ab Stange so genau sind.
Ralf schrieb:> Falk Brunner schrieb:>> Warum nicht? Wenn man die gleich lang macht, kommt da locker hin. 1/2 ns>> ~100mm Lauflänge auf normalem Kabel.> Es sind aber bis zu 10m alles zusammengerechnet. Ich brauche es schon> genauer und eine gleiche Länge ist nicht garantierbar,
Falk meint, dass ein Längenunterschied von 100 mm einer Zeit von 0,5 ns
entspricht.
Wenn du bei so einem aufwändigen Aufbau mit solch harten Anforderungen
noch nicht mal die Kabellängen vorgeben und garantieren kannst, na dann
viel Spass!
Servus
ich arbeite gerade an ein solchen Projekt. Du kannst Gigabit nehmen. Es
gibt PHYs die ein Referenztakt generieren. Dieser Takt kannst du über
einen Network Interface Synchronizer auf alle Platinen synchronisieren.
Dann hast du so gesehen den gleichen Takt überall. Über PTP kannst du
die Strecken zwischen den master und die slaves ausmessen.
Gruss
Ich würde einen externen Triggertakt als Systemtakt hernehmen, und
diesen Impuls splitten, über exakt gleichlange separate Koaxleitungen an
den Laser und den Shutter senden. So wäre sichergestellt dass beide
zeitgleich das Triggersignal erhalten. Zur Kompensation von Signallauf-
und - verabeitungszeiten haben sich in der Vergangenheit auch
Verzögerungsspulen oder Umwegleitungen bewährt. So werden bis in den
Gigaherzbereich Phasenlaufzeiten angepasst. Und so ließe sich auch die
Laserblitzlaufzeit kompensieren.
Eigentlich Grundlagenwissen für den Umgang mit Impulslaufzeiten
Namaste
Winfried J. schrieb:> Ich würde einen externen Triggertakt als Systemtakt hernehmen, und> diesen Impuls splitten, über exakt gleichlange separate Koaxleitungen an> den Laser und den Shutter senden. So wäre sichergestellt dass beide> zeitgleich das Triggersignal erhalten.
Sowas hatte ich auch im Sinn, nur sind die Kabel nicht gleichlang :-)
> Zur Kompensation von Signallauf- und - verabeitungszeiten haben sich> in der Vergangenheit auch Verzögerungsspulen oder Umwegleitungen> bewährt.
Das werde ich recherchieren, danke
