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.
Scheint ein Furz zu sein. Eher etwas in Richtung von Pink-Elephant...
короткое троль 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
короткое троль schrieb: > Scheint ein Furz zu sein. Welch wohlüberlegte, auf fundierten Quellen beruhende, hochqualitative Aussage. SCNR
> короткое троль schrieb: >> Scheint ein Furz zu sein. > > Welch wohlüberlegte, auf fundierten Quellen beruhende, hochqualitative > Aussage. http://de.wikipedia.org/wiki/Dunning-Kruger-Effekt
Ralf schrieb: > Jürgen Schuhmacher schrieb: >> Die Lichtgeschwindigkeit wird bei solchen Anwendungen natürlich >> rausgerechnet, bzw. -gemessen. > Die Laufzeit, die das Licht benötigt ist bei uns Teil des Messwertes :-) Das ist nicht zufällig diese ominöse Anwendung mit dem Auszählen der Taktperioden? Beitrag "Re: Synchronisieren auf rising- und falling-edge"
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
:
Bearbeitet durch User
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
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.