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