Hallo, ich möchte, dass zwei Mikrocontroller dieselbe Uhr (oder sagen wir einfach Zählerwert) haben. Die Anforderungen sind wie folgt: -Uhren haben/brauchen eine Auflösung von 10µs -Ein Fehler von 1 ms zwischen beiden Mikrocontroller ist tolerierbar -Die Synchronisation muss drahtlos aufgrund von Mobilitätsgründen erfolgen Jetzt kommt der Clue: Ich möchte die Synchronisation über Infrarot machen. Ich habe schon viel recherchiert und zum Thema drahtlose Synchronisation hab ich viel mit Bluetooth gefunden. Bezüglich Infrarot hab ich nur sowas in Richtung "kann man machen" gefunden. Also: Bluetooth ist ganz klar eine Alternative und mir bewusst für die Aufgabe, aber ich würd mir gern erstmal Meinungen über Infrarot einholen. Hat jemand damit Erfahrung gemacht und ist bei diesen Anforderungen das überhaupt realisierbar drahtlos? Die Uhrauflösung im Mikrosekundenbereich ist dabei essentiell und nicht änderbar. Danke.
Du sendest jede Millisekunde einen Puls mit Controller A. Controller B sieht diesen Puls und stimmt seinen internen Taktgeber nach. Auf diese Weise wird dauerhaft Synchronität erreicht.
Im richtigen Moment gibst Du EINEN Impuls ab und der voreingestellt Wert in den Controllern wird aktiviert.
Da man weder bei IR noch BT davon ausgehen kann dass ständig eine Verbindung besteht, würde ich Controller A eher seinen aktuellen Stand senden lassen als nur einen Synchronisationspuls. Also per IR nen String raussenden á la: - Startbyte - x Datenbytes - Stoppbyte
>eher seinen aktuellen Stand senden lassen
Problematisch an diesem Vorgehen ist, dass diese Datenübertragung eine
gewisse Zeit benötigt, die ich jetzt mal im einstelligen
Millisekundenbereich schätze + zusätzlich Decodierungszeit.
Das belastet wiederum die Zeitsynchronisierung, wobei ich den Sinn und
die Problematik dahinter verstehe.
wie wäre es mit der Art bei Ping ist es 20:00 Uhr. Also sende doch einfach Uhrzeit im Voraus und dein Modul soll nur auf ne Aktivierung warten.
>wie wäre es mit der Art bei Ping ist es 20:00 Uhr.
Diese Möglichkeit hab ich auch in Betracht gezogen.
In diesem Thema geht es mir nicht primär um die Frage "Wie?" sondern
"Wie gut wird das in der Realität (in einem Innenraum) funktionieren?"
D.h. woran könnte diese Synchronisation scheitern.
Ich dachte z.B. an Umgebungslicht und Störeinflüssen, die die
Synchronisation stören würden. Oder an zu hohen Verzögerungszeiten z.B.
durch die Hardware wie dem Mikrocontroller
Hi Wie gut lässt sich ein TV fernbedienen, wenn es - gerade hell ist - das Licht zusätzlich eingeschaltet wird - es dunkel wird - ... Wenn µC B das Telegramm nicht versteht, muß Er mit Seiner Uhrzeit weiter werkeln. Weiter wurde bisher nur die Kommunikation in eine Richtung genannt, also kann 'A' nicht erfahren, daß 'B' wieder korrekt läuft. Auch, daß die Berechnung/Prüfung Zeit beansprucht, ist kein K-O-Kriterium - die Rechenzeit sollte sich 1-malig bestimmen lassen und der Offset sollte sich zum Ergebnis addieren/abziehen lassen. MfG
THOR schrieb: > Da man weder bei IR noch BT davon ausgehen kann dass ständig eine > Verbindung besteht, würde ich Controller A eher seinen aktuellen Stand > senden lassen als nur einen Synchronisationspuls. Ja. Und ein Byte zusätzlich als CS oder CRC. Tim schrieb: > Problematisch an diesem Vorgehen ist, dass diese Datenübertragung eine > gewisse Zeit benötigt, die ich jetzt mal im einstelligen > Millisekundenbereich schätze + zusätzlich Decodierungszeit. Uninteressant, solange die Sende- und Bearbeitungszeit immer gleich bleibt. Allerdings würde ich auch eine Möglichkeit vorsehen, dass der Controller B den Empfang auch bestätigen kann, oder auch seinen Zählerstand zurückschicken kann (um ev. Abweichungen voneinander festzustellen).
Tim schrieb: >>wie wäre es mit der Art bei Ping ist es 20:00 Uhr. > > Diese Möglichkeit hab ich auch in Betracht gezogen. > > In diesem Thema geht es mir nicht primär um die Frage "Wie?" sondern > "Wie gut wird das in der Realität (in einem Innenraum) funktionieren?" > > D.h. woran könnte diese Synchronisation scheitern. > Ich dachte z.B. an Umgebungslicht und Störeinflüssen, die die > Synchronisation stören würden. Oder an zu hohen Verzögerungszeiten z.B. > durch die Hardware wie dem Mikrocontroller Das sind mögliche Einflüsse. Offen gesagt halte ich eine Aufzählung der möglichen Störfaktoren nicht für zielführend, wenn die Entscheidung sein soll, ob IR oder nicht. Möglicherweise ist es zweckmäßiger sich einmal anzuschauen, für welche Zwecke und unter welchen Bedingungen IR verwendet wird. Das Problem ist nämlich, aus meiner Sicht, dass die Anzahl der Faktoren an sich zwar nicht besonders hoch ist, die Wirkung von deren Kombination aber in realen Umgebungen kaum einzuschätzen ist. Soweit mir bekannt kann man reale IR-Anwendungen etwa so beschreiben: 1. Kurzzeitübertragungen im Bereich von bis 1s. 2. Hohe Redundanz (z.B. Wiederholungen). 3. Kurzstrecken bis zu einigen Metern. Bei hoher Informationsdichte eher im Bereich von 10cm. 4. Verzögerungen der Übermittlung bis zu einigen Sekunden. 5. Starke Variation der Übertragungszeit, Verhältnis min/max etwa 10 oder mehr. 6. Länge einer Information etwa zwischen einigen 10ms (RC5 25ms) bis zu einigen 100ms. 7. Echtzeitübertragungen (etwa Audio) unter Inkaufnahme von Störungen und mit vergleichsweise (im Vergl. zu Funk) hohen Leistungen. 8. Strahlengang steht unter Kontrolle bzw. Möglichkeit von mehreren Ausbreitungswegen. 9. Totalausfall akzeptabel; zumindest in wesentlichen Anteilen der gesamten Benutzungsdauer (etwa 5%) und für Dauern im Stunden bis Tagebereich. Dann steht man halt mal auf und geht auf die Wanderschaft zur Glotze :-) Ich gehe davon aus, dass Du zunächst eigene Schlussfolgerungen ziehen möchtest.
Sieh dir mal NTP an. Deine Infrarotübertragung (egal, wie du sie konkret realisierst) wird wohl kaum schlimmer sein als die Weiten des Internets - und da funktioniert die Synchronisation mit NTP sehr gut. Selbst wenn du nicht NTP selbst implementieren willst, die Prinzipien, mit dennen da der Einfluß des Übertragungsweges rausgerechnet wird, sollten dir bei deinem Problem weiterhelfen.
Tim schrieb: >>eher seinen aktuellen Stand senden lassen > > Problematisch an diesem Vorgehen ist, dass diese Datenübertragung eine > gewisse Zeit benötigt, die ich jetzt mal im einstelligen > Millisekundenbereich schätze + zusätzlich Decodierungszeit. > Das belastet wiederum die Zeitsynchronisierung, wobei ich den Sinn und > die Problematik dahinter verstehe. Der Empfänger kann sich ja merken, wann die Übertragung begonnen hat. Dann kann er die Dauer rausrechnen. Oder auch umgekehrt: Der Sender weiß, wie lange er zur Übertragung brauchen wird und kann das gleich berücksichtigen. Wenn Paketlänge und Bitrate konstant sind, ist es sogar noch einfacher. Tim schrieb: > D.h. woran könnte diese Synchronisation scheitern. > Ich dachte z.B. an Umgebungslicht und Störeinflüssen, die die > Synchronisation stören würden. Die Übertragung sollte auf jeden Fall moduliert durchgeführt werden, wie bei IR-Fernbedienungen. Die Sender/Empfänger gibt's ja in der Form, wo das schon eingebaut ist. Man muss dann nur noch etwas einbauen, dass sicherstellt, dass das Signal von Fernbedienungen nicht als Synchronisations-Signal missverstanden wird. > Oder an zu hohen Verzögerungszeiten z.B. durch die Hardware wie dem > Mikrocontroller Aber 1 ms ist doch für einen µC eine lange Zeit. Ralf D. schrieb: > Sieh dir mal NTP an. Deine Infrarotübertragung (egal, wie du sie konkret > realisierst) wird wohl kaum schlimmer sein als die Weiten des Internets > - und da funktioniert die Synchronisation mit NTP sehr gut. Allerdings schafft es in den "Weiten des Internets" dann auch keine 1 ms Genauigkeit mehr. > Selbst wenn du nicht NTP selbst implementieren willst, die Prinzipien, > mit dennen da der Einfluß des Übertragungsweges rausgerechnet wird, > sollten dir bei deinem Problem weiterhelfen. Der Übertragungsweg ist in diesem Fall eine Infrarot-Strecke. Da gibt's nicht viel rauszurechnen. Solange der Empfänger nicht ewig braucht, um zu erkennen, dass er ein Sync-Paket bekommen hat, ist das einzige, was signifikant Latenz hat, die zeitliche Länge des Pakets, die aber bekannt und damit trivial rauszurechnen ist.
:
Bearbeitet durch User
Ralf D. schrieb: > Sieh dir mal NTP an. Wäre auch mein Vorschlag. Hier was zum Einlesen: Mills et al. RFC 5905: NTPv4 Specification June 2010 https://www.ietf.org/rfc/rfc5905.txt Wie genau das funktioniert, findest du z.B. hier: D. Mills: Computer Network Time Synchronization - The Network Time Protocol on Earth and in Space (2nd ed.) CRC Press (Boca Raton, London, New York) 2. Auflage 2011 ISBN 978-1-4398-1463-5 Grüße Stefan
:
Bearbeitet durch User
Rolf M. schrieb: > Ralf D. schrieb: >> Sieh dir mal NTP an. Deine Infrarotübertragung (egal, wie du sie konkret >> realisierst) wird wohl kaum schlimmer sein als die Weiten des Internets >> - und da funktioniert die Synchronisation mit NTP sehr gut. > > Allerdings schafft es in den "Weiten des Internets" dann auch keine 1 ms > Genauigkeit mehr. Bei mir zuhause hinter DSL liege ich im ms-Bereich für Offset und Jitter, die Kiste beim Hoster liegt eine Größenordnung besser. Entscheidend für die Genauigkeit ist eine möglichst konstante Verzögerung auf dem Übertragungsweg. remote refid st t delay offset jitter ============================================================== +stratum2-4.NTP. 129.70.130.70 2 u 18.746 1.149 0.211 -janetzki.eu 178.63.9.212 3 u 20.765 1.164 1.999 *stratum2-3.NTP. 129.70.130.70 2 u 21.153 -0.289 0.263 -node4.mneisen.o 192.53.103.108 2 u 34.077 -5.919 0.152 +phoenix.doeblit 185.11.138.18 3 u 0.086 0.049 0.085 remote refid st t delay offset jitter ============================================================== *ns1.customer-re 192.53.103.108 2 u 24.960 0.076 0.384 -178.162.194.82 78.46.52.71 3 u 18.029 -4.064 0.377 +mx01.nerdinator 131.188.3.222 2 u 20.713 -0.598 0.340 +selene.doeblitz 52.239.121.49 3 u 0.073 -0.043 0.071 Die Zeile mit "*" ist der ausgewählte Referenz-Server. Die letzte Zeile ist jeweils eine Maschine im lokalen Netz. NTP läuft selbst mit Consumer-Anbindung verdammt gut. >> Selbst wenn du nicht NTP selbst implementieren willst, die Prinzipien, >> mit dennen da der Einfluß des Übertragungsweges rausgerechnet wird, >> sollten dir bei deinem Problem weiterhelfen. > > Der Übertragungsweg ist in diesem Fall eine Infrarot-Strecke. Da gibt's > nicht viel rauszurechnen. Solange der Empfänger nicht ewig braucht, um > zu erkennen, dass er ein Sync-Paket bekommen hat, ist das einzige, was > signifikant Latenz hat, die zeitliche Länge des Pakets, die aber bekannt > und damit trivial rauszurechnen ist. Tja, und eben die Interrupt-Latenz und der Jitter, gerade letztere ist nicht unbedingt zu vernachlässigen (zumindest sollte man sich das vorher mal ansehen bzw. den worst case durchrechnen). Bei NTP haben so viele kompetente Leute soviele Manntage reingesteckt, daß man dieses Wissen nicht leichtfertig ignorieren sollte, IMHO.
:
Bearbeitet durch User
Zu ntp gibts auch online recht gute Erklärungen und Analysen - auf Englisch. https://www.eecis.udel.edu/~mills/ntp.html Leider ein wenig unübersichtlich (finde ich) aber wenn Du etwas bestimmtes nicht findest, kann man vielleicht einen Hinweis geben. Ich habe jedenfalls nur mit Hilfe dieser Webseite mal eine Synchronisation zwischen einem Linux-PC und einem AVR über eine serielle (RS232) Verbindung implementiert. Ist nicht sehr aufwändig.
Interessante Vorschläge! Da sollen zwei wahrscheinlich einfache Mikrokontroller zeitlich synchronisiert werden und als Vorschlag gibt es: "Bau das System zu zwei vollwertigen Computern aus und nutze das Internet". Meine Meinung zu solchen Vorschlägen lässt sich nicht drucken. Nach meiner Meinung geht das Ganze nur bei einem System, das praktisch nichts zutun hat. 1. Beide Systeme benötigen eine von vornherein genaue Uhr (Quatsch). 2. Der Empfänger muss kurz vor dem "nächsten" Zeitsignal in eine explizit geschaffene Warteschleife gehen, in der er auf das Ereignis (Signal) wartet. Hierbei sollten auch alle Unterbrechungen abgeschaltet werden. Das ist auch der Grund dafür, dass ich gesagt habe: "Das System darf nichts zutun haben". 3. Der Sender gibt einen Senf dazu und fertig ist. - Je genauer die Quarze sind, desto geringer kann die "Vorlaufzeit" für den Sprung in die Warteschleife sein. - Wenn der Empfänger wirklich nichts zutun hat, kann man sogar - in etwa - prognostizieren, wie lange das Zielsystem benötigt um die Synchronisation zu übernehmen und somit kann auch der Sender dass Signal "etwas" früher senden. - Die Synchronisationszeit lässt sich noch kürzen, wenn man anhand der vorhergehenden Impulse die eigene Startzeit korrigiert. - Nicht ganz unwichtig: Was passiert, wenn ich zwischen Sender und Empfänger stehe? (Kein Anschluss unter dieser Nummer!)
Sebastian S. schrieb: > Meine Meinung zu solchen Vorschlägen lässt sich nicht drucken. Man merkt deinem Posting an, dass du dich schon lange und intensiv mit dem Thema beschäftigt hast.
Ib der industriellen Messtechnik gibt esfür solche Syncronisation spezielle Protokolle (z.B. IRIG-B) die z.B. per Funk gesendet werden und von allen Messstationen empfangen werden.
Ralf D. schrieb: >> Der Übertragungsweg ist in diesem Fall eine Infrarot-Strecke. Da gibt's >> nicht viel rauszurechnen. Solange der Empfänger nicht ewig braucht, um >> zu erkennen, dass er ein Sync-Paket bekommen hat, ist das einzige, was >> signifikant Latenz hat, die zeitliche Länge des Pakets, die aber bekannt >> und damit trivial rauszurechnen ist. > > Tja, und eben die Interrupt-Latenz und der Jitter, gerade letztere ist > nicht unbedingt zu vernachlässigen (zumindest sollte man sich das vorher > mal ansehen bzw. den worst case durchrechnen). Wo willst du denn so viel Latenz und Jitter haben, dass du um mehr als 1 ms daneben liegst? Wenn das passiert, ist am Programm was falsch (über längere Zeit gesperrte Interrupts oder sowas). > Bei NTP haben so viele kompetente Leute soviele Manntage reingesteckt, > daß man dieses Wissen nicht leichtfertig ignorieren sollte, IMHO. Ja, mag sein. Ich finde es für diesen Anwendungsfall aber übertrieben. Bei einem PC mit Betriebssystem und Treibern und IP-Stack sowie einer Verbindung über Switches und Router und DSL und wer weiß was alles noch ist das natürlich was anderes. Das gibt's hier aber alles nicht.
@Georg >Sebastian S. schrieb: >> Meine Meinung zu solchen Vorschlägen lässt sich nicht drucken. >Man merkt deinem Posting an, dass du dich schon lange und intensiv mit >dem Thema beschäftigt hast. Ein nicht zu überbietend, hilfreicher Beitrag zum Thema.
Sebastian S. schrieb: > Da sollen zwei wahrscheinlich einfache Mikrokontroller zeitlich > synchronisiert werden und als Vorschlag gibt es: "Bau das System zu zwei > vollwertigen Computern aus und nutze das Internet". Muss ein anderer Thread gewesen sein, denn hier hat das niemand getan. Ein Verweis auf die grundsätzliche Arbeitsweise von NTP impliziert nicht die Verwendung von NTP. Wohl aber, dass man aus den darin genutzten Prinzipien vielleicht lernen kann. Statt das Rad neu zu erfinden. > Meine Meinung zu solchen Vorschlägen lässt sich nicht drucken. Ob eine Strategie wohl auf Dauer erfolgreich ist, all jene zu beschimpfen, die mit unpassend scheinenden Antworten kommen? Neben rein menschlichen Aspekten schliesst man damit nämlich auch jene Antworten aus, die man selber nicht verstanden hat.
:
Bearbeitet durch User
Rolf M. schrieb: > Ralf D. schrieb: [...] > Wo willst du denn so viel Latenz und Jitter haben, dass du um mehr als 1 > ms daneben liegst? Wenn das passiert, ist am Programm was falsch (über > längere Zeit gesperrte Interrupts oder sowas). Eben. Sollte man zumindest daraufhin überprüfen. Wenn du alle kritischen Abschnitte überprüfst und danach sicher bist, daß Latenz und Jitter klein genug sind, dann ist doch alles in Ordnung. Man sollte diese Prüfung halt nur nicht vergessen, sonst gibt es evtl. unschöne Überraschungen. >> Bei NTP haben so viele kompetente Leute soviele Manntage reingesteckt, >> daß man dieses Wissen nicht leichtfertig ignorieren sollte, IMHO. > > Ja, mag sein. Ich finde es für diesen Anwendungsfall aber übertrieben. > Bei einem PC mit Betriebssystem und Treibern und IP-Stack sowie einer > Verbindung über Switches und Router und DSL und wer weiß was alles noch > ist das natürlich was anderes. Das gibt's hier aber alles nicht. Deshalb ja auch der Hinweis auf die benutzten Verfahren. Man muß nicht NTP selbst nehmen, aber das Prinzip, mit dem dort die Laufzeiten herausgerechnet werden, kann man IMHO relativ einfach übernehmen.
Für meinen Geschmack fehlen noch einige notwendige Daten. - Wie hoch ist die Kurzzeitstabilität der verwendeten Uhren in den uC? Daraus ergibt sich sofort, wie oft synchronisiert werden muss. - Angenommen, es ist ein Master/Slave System. Wie zieht der Slave seine Taktfrequenz nach, um synchron zu bleiben? - Sind Zeitsprünge erlaubt? Wenn ja: Darf die Zeit auch rückwärts springen? - Wie lange darf die Synchronisierung dauern? - Soll mit einer Bake synchronisiert werden oder kann Duplex verwendet werden. NTP setzt Duplex voraus. Bei einem Baken System hat der Master keine Rückmeldung, ob seine Slaves auf Reihe sind. Die gängigen IR-Module arbeiten auf Frequenzen unter 50kHz. Das sind 20us pro Periode. Damit werden 10us Genauigkeit schon sportlich. Das läuft auf Phasenmessungen hinaus. Wenn man mit der Frequenz rauf geht - was prinzipiell möglich ist - kommt die nächste Baustelle, dass in Sender und Empfänger Arbeit gesteckt werden muss. Der Sender ist das kleinere Problem. Ein störfester Empfänger, der hinreichend breitbandig ist, bedeutet schon etwas Aufwand. Als grobe Hausnummer sollten 100kHz Bandbreite mit passendem Phasengang ausreichen.
Hallo, >Nach meiner Meinung geht das Ganze nur bei einem System, das praktisch nichts zutun hat. Das System hat mehrere periodische Aufgaben zu erledigen, die parallel zur Uhrensynchronisation ablaufen müssen. >Wie hoch ist die Kurzzeitstabilität der verwendeten Uhren in den uC? Daraus ergibt sich sofort, wie oft synchronisiert werden muss. Dazu kann ich leider keine Informationen geben. Ich kann nur sagen, dass beide Quarze ungefähr eine Genauigkeit von (mindestens) 20 ppm zur Frequenz haben, die den Uhrentakt erzeugt. >Angenommen, es ist ein Master/Slave System. Wie zieht der Slave seine Taktfrequenz nach, um synchron zu bleiben? Eine Frequenzänderung des Mikrocontrollers ist bisher nicht geplant, d.h. der Uhrentakt soll nicht geändert werden. >Sind Zeitsprünge erlaubt? Wenn ja: Darf die Zeit auch rückwärts springen? Ja und Ja >Wie lange darf die Synchronisierung dauern? Sie muss abgeschlossen sein, bevor das nächste Synchronisationsinterval beginnt. Grob geschätzt maximal 1 s >Soll mit einer Bake synchronisiert werden oder kann Duplex verwendet werden. NTP setzt Duplex voraus. Bei einem Baken System hat der Master keine Rückmeldung, ob seine Slaves auf Reihe sind. Bake (ohne Rückmeldung des Slaves) >Die gängigen IR-Module arbeiten auf Frequenzen unter 50kHz Sind damit die Empfänger gemeint? Bei den Empfänger muss man beachten, dass diese für eine Auswertung mehr als eine Periode ("burst") empfangen müssen, damit der Ausgang aktiviert wird (Mindestpulsbreite). D.h. sie reagieren nicht auf eine einzige Periode ihrer Trägerfrequenz. >Damit werden 10us Genauigkeit schon sportlich. Die Uhren haben eine Auflösung von 10us, wobei aber ein Fehler von 1 ms (zwischen Master und Slave) noch tolerierbar ist.
Georg G. schrieb: > Die gängigen IR-Module arbeiten auf Frequenzen unter 50kHz. Das sind > 20us pro Periode. Damit werden 10us Genauigkeit schon sportlich. Da es viele bisher ignoriert haben, hatte ich es in meine Antworten inzwischen schon mehrfach eingebaut: Die Anforderung lautet: Tim schrieb: > -Ein Fehler von 1 ms zwischen beiden Mikrocontroller ist tolerierbar Keine 10 µs, sondern 1 ms! Das wird aber weiter ignoriert, weshalb irgendwelche Interrupt-Jitters als Problem genannt und Phasenmessungen vorgeschlagen werden. Die meisten denken hier einfach viel zu kompliziert, weil nicht berücksichtigt wird, dass die Gangabweichung bis zu 1 ms betragen darf.
Sozusagen : deutschkompliziert ! Andere wollen dagegen Kompliziertes: möglichst EINFACH ! Hoch lebe die goldene Mitte !
Hi Rolf M. schrieb: > hatte ich es in meine Antworten > inzwischen schon mehrfach eingebaut: Die Anforderung lautet: > > Tim schrieb: >> -Ein Fehler von 1 ms zwischen beiden Mikrocontroller ist tolerierbar Wenn 'Tim' jetzt was von Seinen Antworten gesagt hätte (wobei es eine Antwort war), wäre Das jetzt irgendwie 'offizieller' - aber egal. Bei 1MHz macht der µC pro µs einen Befehl (diverse Ausnahmen mit bis zu 3 Takten, Sprünge z.B.). Das macht 333 - 1000 Befehle vom Erkennen des Sync-Wunsch, bis zu Dessen Ende. Wo liegt das Problem, mittels IR-Sensor eine 'Ticker'-Zahl zu übertragen und Diese im Slave zu übernehmen bzw. drauf einzurasten? Wenn die µC etwas schneller getaktet werden, bekommen wir in der Zeit noch mehr Befehle unter - wo bitte siehst Du ein Problem? Selbst, wenn die Erkennung/Auswertung/Anpassung eine halbe Millisekunde dauert (500 Befehle), bist Du LOCKER innerhalb Deiner angepeilten maximalen Abweichung von 1ms. MfG
Der entscheidende Punkt bei einer Einweg-Synchronisation der Zeit ist folgender: Betrachtet wird die Zeit ab dem Beginn der Aussendung des Uhrstandes im Sender. Die Betrachtung endet am Ende des setzens des neuen Uhrstandes im Empfänger. Darin enthalten sind alle Aktivitäten im Sender und Empfänger die für das kodieren des Uhrstandes und dessen Aussendung nötig sind. Auch sind darin enthalten, alle sonstigen Aktivitäten des Senders und Empfängers die mit der eigentlichen Synchronisation nichts zu tun haben. Das sind im Prinzip nur Zeitdauern, um die der Vorgang verlängert wird. Entscheidend ist nun nicht, wie lange die Aktivitäten jeweils dauern, sondern wie gross die Schwankungen sind. Wenn sich für den Vorgang eine garantierte minimale und maximale Zeit angeben lässt, dann kann man ausrechnen, wie genau die Zeit eingestellt werden kann. Der Sender sendet seine Zeit t. Der Empfänger setzt seine Uhr auf t + (max + min) / 2. Die minimale Abweichung ist damit (max-min)/2. Diese Berechnung ergibt sich abstrakt aus Überlegung des Vorgangs (unidirektional, variable Verzögerung, garantierte minimale und maximale Verzögerung) unabhängig davon, wie das konkret implementiert wird.
Hallo, bei der Uhrensynchronisation gibt es die Werteanpassung (Zeitwert ändern) und Ratenanpassung (Taktfrequenz beschleunigen/verlangsamen) als "Stellglied". In wiefern ist eine Ratenanpassung bei einem Mikrocontroller wie z.B. STM32 möglich? Sagen wir mal dessen Prozessortakt wird auf Basis eines externen Takts erzeugt. Kann ich mit dem Mikrocontroller dann die Taktfrequenz der Uhr in einer so hohen Auflösung anpassen, dass ich den Zeitfehler auf maximal +/- 1 ms beschränken kann? Also ich bin mir sicher, dass man die Taktfrequenz der Uhr ändern kann, aber ist die Auflösung dementsprechend ausreichend?
Tim schrieb: > Hallo, > [...] Ich würde vorschlagen, dass Du erst einmal das eine Thema abschliesst. Ich wünsche mir da eine Darstellung dessen, was Du (ausser hier in dem Thread) gelesen und verstanden hast und eines Verfahrens (wenigstens verbal), mit dem das realisiert werden kann und warum das funktioniert. Ansonsten sehe ich nämlich in diesem Thread nicht mehr den Unterschied zwischen Hilfe zur Selbsthilfe und unbezahlter Arbeit.
Tim schrieb: > Taktfrequenz beschleunigen/verlangsamen Das ist relativ aufwendig, es sei denn, der Prozessor ist dafür schon ausgelegt. Einfacher ist es, den Vorteiler der Uhr zu manipulieren. Beispiel: Du hast 10MHz Taktfrequenz und deine Uhr tickt mit 10us. Dann hast du einen Vorteiler 1/1000. Zur Anpassung kannst du dann einmal pro Minute durch 1001 teilen, wenn deine Uhr zu schnell läuft. Mit einem passenden Schema kann man sehr fein korrigieren.
Wieder so ein supergeheimes Projekt, wenn man es wüsste, die Lösung viel einfacher wäre... Geht auch ein dritter uC? Der könnte die Synchronisation senden! Eine IR-Led kann man gut softwaremäßig modulieren, dass Du das Signal mit einem einfachen (38kHz-)Empfänger empfangen kannst! Gruss Chregu
Was spricht denn dagegen beide uC mit einem DCF77-Modul auszustatten? Das 1s Taktsignal kommt doch recht genau, oder? Im Wesentlichen würde ich mich darauf verlassen, dass die Abweichung des Systemtakts beider uC über einen kurzen Zeitraum wesentlich kleiner ist, als 1ms. Und dann, wenn das DCF-Modul ein stabiles Signal liefert und die Abweichung zum Systemtakt sagen wir größer als 100us ist, dann wird nachgeregelt. Man müsste halt mal vergleichen wie groß die Zeitliche Abweichung des 1s Taktes bei verschiedenen DCF Modulen ist, und ob dies stabil ist oder variabel. Klingt nach einer interessanten Aufgabe ;o)
1ms Gangabweichung ist eher sportlich mit einem 20ppm Quarz. 20ppm bedeutet 2*10^-5, dh die Millisekunde Gangunterschied ist nach 50000 ms erreicht. das waeren dann nur 50 sekunden. Dh ein 20ppm Quarz ist nach 50 sekunden um eine Millisekunde von einer idealen Uhr weggelaufen. Dh man ist eigentlich dauernd am synchronisieren. Eine Frage der Aufgabenstellung ... die kennen wir leider nicht. Vielleicht passt's, vielleicht nicht. Allenfalls interessant waere die Umgebung. Bei Aussenbedingungen (-40 ..+85) sind die 20ppm schwieriger wie nur innen (+20..+30). Die Gangreserve waere dann also kleiner als 50 sekunden. Wie hoch ist die Fehlerwahrscheinlichkeit ? Dh wieviele Versuche klappen nicht und werden verworfen ? Allenfalls muesste man die Synchronisation jede Sekunde ausstrahlen. Oder falls die Energie keine Rolle spielt, kontinuierlich. Wie oft hier : was soll das Ganze ?
Sapperlot W. schrieb: > 1ms Gangabweichung ist eher sportlich mit einem 20ppm Quarz. 20ppm > bedeutet 2*10^-5, dh die Millisekunde Gangunterschied ist nach 50000 ms > erreicht. das waeren dann nur 50 sekunden. > > Dh ein 20ppm Quarz ist nach 50 sekunden um eine Millisekunde von einer > idealen Uhr weggelaufen. > > Dh man ist eigentlich dauernd am synchronisieren. So ist das. Und wenn man jetzt noch unterstellt, daß jeder der beiden µC einen solchen 20ppm Quarz hat und daß die in entgegengesetzter Richtung driften, dann sind es sogar nur noch 25 Sekunden. MagIO schrieb: > Was spricht denn dagegen beide uC mit einem DCF77-Modul auszustatten? > Das 1s Taktsignal kommt doch recht genau, oder? Oder. Mit einer Demodulation der Amplitude des DCF-Signals kommst du nicht mal ansatzweise auf 1ms Genauigkeit (oder auch nur Jitter). Das liegt daran, daß Antenne und Filter i.d.R. sehr schmalbandig ausgelegt sind für hohe Empfindlichkeit und Trennschärfe (Ausblendung von Störquellen). Für die Schmalbandigkeit "bezahlt" man aber in Form von Signallaufzeit, die noch dazu abhängig ist von der Signalstärke und der Stärke eventueller Störungen. Allerdings ist DCF77 zusätzlich noch phasenmoduliert. Wenn man dieses Signal demoduliert, dann ist man zwar immer noch weit von 1ms Latenz entfernt, aber der Jitter sollte besser als 1ms werden. Siehe: https://de.wikipedia.org/wiki/DCF77#Genauigkeit:_Erkennung_des_Sekundenbeginns Infrarot hat übrigens genau das gleiche Problem wie DCF77, zumindest solange man handelsübliche Empfänger wie TSOPxxx verwenden will. Auch diese Empfänger sind recht schmalbandig und verzögern folglich das Signal deutlich. Im Zusammenspiel mit der AGC wird man außerdem noch einen deutlichen Einfluß der Umgebungshelligkeit auf diese Verzögerung beobachten können.
Man kann ungenaue Oszillatoren nicht nur durch Anpassung der Quarzfrequenz kompensieren, sondern auch durch Korrekturen in der Zeitgewinnung. Wenn beispielsweise jede Sekunde die Zeit tickt, dann muss man nicht zwangsläufig 1 Mio µs zu einem Zähler addieren, es dürfen auch 999123µs oder 1000077µs sein (wer lieber schiebt statt dividiert nimmt Zweierpotenzen). Schon hat man einen sich aus der Synchronisation ergebenden und sich nur sachte ändernden Korrekturwert, den man evtl. auch ab und zu mal in EEPROM oder sonstwo speichern kann. Es sollte durchaus möglich sein, entsprechende Strategien auch für Millisekunden statt Sekunden zu finden. Auch die offizielle Zeitmessung kennt Schaltsekunden, hier vielleicht ab und zu um einen Takt korrigierte Timer.
:
Bearbeitet durch User
Man koennte sich vorstellen einen 1kHz Traeger per IR auszusenden. Und die zu synchronisierenden Controller lassen einen PLL drauf locken. Dann waer's auch nicht so tragisch wenn das Signal mal verschwindet. Es gibt tolle VCXO Oszillatoren, die haben einen Steuerbereich von einem ppm oder so. Und die sind dann auch so genau.
@Axel: Danke für den Link ... manchmal ist das Internet weiter weg, als an anderen Tagen ;o) Zitat von da: "Die PTB Braunschweig gibt die immer noch hinzunehmenden Ungenauigkeiten mit 6,5–25 μs an, abhängig von Tages- und Jahreszeit." Also ... aus der uC Beschaltung Quarz raus, PLL mit hoher Genauigkeit rein und nach einer uC-Ewigkeit mal wieder mit DCF77 Phasenmodulation synchronisieren - dann vermutlich Eigenbau. Hat ja vielleicht den Charme, dass man auch gleich Uhrzeit und Datum geschenkt bekommt. MUss halt sichergestellt sein, dass die uC ausreichend guten Empfang haben.
Hallo, >Dh man ist eigentlich dauernd am synchronisieren. Eine Frage der >Aufgabenstellung ... die kennen wir leider nicht. Vielleicht passt's, >vielleicht nicht. >Wie oft hier : was soll das Ganze ? >Wieder so ein supergeheimes Projekt, wenn man es wüsste, die Lösung viel einfacher wäre... Ich möchte eine einfache Messung einer Signallaufzeit zwischen zwei Mikrocontroller durchführen. Auf dem einen Mikrocontroller soll zu bestimmten Zeitpunkten Schall erzeugt werden und auf dem anderen soll die Zeit begonnen werden zu messen. >Allenfalls interessant waere die Umgebung. Bei Aussenbedingungen (-40 >..+85) sind die 20ppm schwieriger wie nur innen (+20..+30). Es gelten immer Innenbedingungen mit +20...+30 >Einfacher ist es, den Vorteiler der Uhr zu manipulieren. Beispiel: Du hast 10MHz Taktfrequenz und deine Uhr tickt mit 10us. Dann hast du einen Vorteiler 1/1000. Zur Anpassung kannst du dann einmal pro Minute durch 1001 teilen, wenn deine Uhr zu schnell läuft. Mit einem passenden Schema kann man sehr fein korrigieren. Genau so war das gedacht mit der Ratenanpassung. >Geht auch ein dritter uC? Der könnte die Synchronisation senden! Eine IR-Led kann man gut softwaremäßig modulieren, dass Du das Signal mit einem einfachen (38kHz-)Empfänger empfangen kannst! Das Problem mit dem angesprochenen Empfänger ist, dass er das Signal ziemlich verzögert zum Ausgang bei der Demodulation. Und dieses verzögern ist wahrscheinlich nicht konstant sondern Abhängig von der Störumgebung. >Man koennte sich vorstellen einen 1kHz Traeger per IR auszusenden. Und die zu synchronisierenden Controller lassen einen PLL drauf locken. Dann waer's auch nicht so tragisch wenn das Signal mal verschwindet. Einen 1 kHz Träger habe ich erzeugen und empfangen können. Der Empfänger kann mit seiner eigenen Uhr die richtige Pulsbreite (bzw. Abstand zwischen 2 Flanken) des Trägers bestimmen. >Infrarot hat übrigens genau das gleiche Problem wie DCF77, zumindest solange man handelsübliche Empfänger wie TSOPxxx verwenden will. Auch diese Empfänger sind recht schmalbandig und verzögern folglich das Signal deutlich. Im Zusammenspiel mit der AGC wird man außerdem noch einen deutlichen Einfluß der Umgebungshelligkeit auf diese Verzögerung beobachten können. Diese Verzögerung hab ich beobachten können. Aus der Antwort lese ich heraus, dass diese Verzögerung abhängig ist von vielen Faktoren. Ich kann diese also nicht als konstant hinnehmen? Danke für die Anregungen.
Tim schrieb: > Ich möchte eine einfache Messung einer Signallaufzeit zwischen zwei > Mikrocontroller durchführen. Bist Du der TO? Das ist jetzt aber nicht Dein Ernst, oder?!?! Komplizierter geht es ja nicht mehr! Gruss Chregu
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.