Hi, ich stehe wieder mal vor einem Problem. Hat irgendjemand eine Idee wie ich die Genauigkeit eines Quarzes bestimmen kann? Folgendes Problem: Ich habe eine Schaltung mit Atmega8 und Uhrenquarz. Diese Schaltung muss genau alle 176,5 Sekunden ein Datentelegramm per Funk senden. Nun überlege ich, wie ich messen kann ob die Schaltung auch wirklich exakt alle 176,5 Sekunden sendet, oder nicht doch eher alle 176,5124 Sekunden. Sprich mit der Zeit nach irgendwo abdriftet. Die erste Idee, die ich auch schon oft umgesetzt habe: Kleines Delphi-Programm geschrieben, welches über RS232 Datensätze entgegen nimmt. Beginnt der Datensatz mit "#" dann wird ein Timer, welcher mit 0,25 Sekunden Genauigkeit läuft, gestartet und die Zeit seit dem letzten Datensatz in eine Textfeldkomponente geschrieben. Noch im Timerinterrupt des Atmega wird die Zählvariable bereits auf 1 zurück gesetzt und von neuem im Timerinterrupt hochgezählt, so dass hier eigentlich keine Beeinflussung durch die RS232-Ausgabe stattfinden dürfte. Im Idealfall sollte über Stunden hinweg, immer eine Zeit von 176,5 gemessen werden. In diesem Ansatz gibt es nur 2 Unbekannte: Wie genau läuft der interne Timer des Computers und beeinflusst die Datenausgabe über RS232 den aktiven Timer des Atmegas dennoch? Über Ideen und Tips bin ich sehr Dankbar.
:
Bearbeitet durch User
Hallo, exakt gibt es nicht, du musst festlegen, was die größte zulässige Abweichung ist (1ms, 1ns, 1ps oder was auch immer). Dann kannst du entweder in das Datenblatt von deinem Quarz schauen, wie genau der ist. Wenn du es Messen willst brauchst du einen Zeitbasis, die genauer ist, als deine maximale Abweichung. Da der PC auch nur einen Quarz hat wird der nicht besser sein, als dein Quarz, sprich, du musst dir schon was genaueres zulegen. Hier ein Video, das dein Problem behandelt. http://www.youtube.com/watch?v=0UksWKuVFFo Gruß Kai
:
Bearbeitet durch User
Stefan S. schrieb: > wie ich messen kann ob die Schaltung auch wirklich exakt > alle 176,5 Sekunden sendet Wie genau soll es denn sein (Delta bei 176,5s)? Als Beispiel: eine Quarzabweichung von 100ppm ergibt bei 176,5s eine Abweichung von 17,65ms. rgds
Denke mal, 10ms sollten reichen. Es soll ein Wettersensor werden. Die empfangene Basis schaltet wegen Batteriebetrieb den Empfänger nur dann ein, wenn auch wirklich ein Sensor sendet. Hab das Gefühl, dass Timing müsste sich irgendwo zwischen 250 und 500 Millisekunden befinden. Für diese Zeit scheint der Empfänger aktiv zu sein. Weiterhin betreibt die Basis mind. 2 mal täglich Sensorsuche. Soll heißen, auf 12 Stunden darf das Sendeintervall um maximal +-125 Millisekunden abweichen. Ich werde es erstmal mit meiner alten Methode (Pc und RS232) versuchen. Dort werde ich mal den Timer des Delphiprogramms herunterskalieren. Dachte auf 10 Millisekunden Auflösung und dann schauen wie hoch die Abweichungen sind.
@ Stefan S. (engi) >Denke mal, 10ms sollten reichen. Das sind weniger als 100ppm. Hmm. > Es soll ein Wettersensor werden. Die >empfangene Basis schaltet wegen Batteriebetrieb den Empfänger nur dann >ein, wenn auch wirklich ein Sensor sendet. Da sollte man eingrößeres zeitfenster vorsehen. > Hab das Gefühl, dass Timing >müsste sich irgendwo zwischen 250 und 500 Millisekunden befinden. Eben.. >Basis mind. 2 mal täglich Sensorsuche. Soll heißen, auf 12 Stunden darf >das Sendeintervall um maximal +-125 Millisekunden abweichen. Das sind 2,9ppm! Dafür braucht man einen SEHR guten TCXO! Ob das dem Problem angemessen ist? Wieviel Energie wird "verschwendet", wenn der Funk 500ms länger aktiv ist?
Denk bei dem Delphi-Programm daran, daß du NICHT die Timer-Komponente verwendest. Die ist nur dafür da, ein ungefähres Zeitraster vorzugeben. Wenn es genau werden soll, nimm die Systemzeit (ticks) und werte die aus. Ich hatte das früher auch mal mit der Timer-Komponente gemacht, selbst eine Stoppuhr ging schon nach ein paar Minuten(!) völlig falsch.
Hi >Denk bei dem Delphi-Programm daran, daß du NICHT die Timer-Komponente >verwendest. Die ist nur dafür da, ein ungefähres Zeitraster vorzugeben. >Wenn es genau werden soll, nimm die Systemzeit (ticks) und werte die >aus. Oder Multimedia Timer: http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&ved=0CEcQFjAD&url=http%3A%2F%2Fblubplayer.de%2Ftutorials%2FTimerTutorial.pdf&ei=LrYEU4uQLIHpsAa_0IHADw&usg=AFQjCNEsfGAyCkkWn73kz6l6OvnFE6oOCQ&bvm=bv.61535280,d.Yms&cad=rja MfG Spess
Stefan S. schrieb: > Die empfangene Basis schaltet wegen Batteriebetrieb den Empfänger > nur dann ein, wenn auch wirklich ein Sensor sendet. Woher weiß der Empfänger, der gerade nicht an ist, daß ein Sensor in kürze wirklich etwas senden will, um sich rechtzeitig einzuschalten? MfG Klaus
Synchronisier die Zeiten bei jedem Empfang, dann setzt Du jedes Mal die Abweichung wieder auf Null und mußt nur die Abweichung in den 176,5 Sekunden abfangen.
Falk Brunner schrieb: >>Basis mind. 2 mal täglich Sensorsuche. Soll heißen, auf 12 Stunden darf >>das Sendeintervall um maximal +-125 Millisekunden abweichen. > > Das sind 2,9ppm! Dafür braucht man einen SEHR guten TCXO! Ob das dem > Problem angemessen ist? Wieviel Energie wird "verschwendet", wenn der > Funk 500ms länger aktiv ist? Natürlich würde man nicht das Zeitraster für einen ganzen Tag vorgeben. Sondern sobald man einmal ein Telegramm vom Sensor empfangen hat (etwa bei einer Sensorsuche) die Pause bis zum nächsten Empfangsversuch ab diesem Zeitpunkt laufen lassen. Mit jedem empfangenen Telegramm synchronisiert sich die Basis also wieder neu mit dem Sender. Wenn der Sender langsam wegdriftet, dann driftet die Basis mit. Da man den Empfänger sowieso einige 10..100ms vorher einschalten muß, damit sich alle Arbeitspunkte einstellen, Quarze anschwingen etc. kann man ja genügend Puffer vorsehen, um einen "zu früh" sendenden Sensor trotzdem zu erwischen. Und entsprechend ein Timeout von einigen 100ms bevor man den Empfänger bei fehlendem Signal abschaltet und "Sensor tot" diagnostiziert. Übermäßig genau muß der Krempel also gar nicht sein. Ein billiger Quarz mit einer Toleranz von 100ppm reicht bei weitem. XL
Der Link mit dem Timer in Delphi war klasse. Ich nehme die Zeit jetzt mittels "gettickcount". Ist schon sehr viel präziser als der Standart-Timer aus Delphi. Hier hab ich jetzt auch herausgefunden warum mein Sensor Marke Eigenbau bisher immer zeitlich weglief. Er sendete immer rund 250ms zu früh. Jetzt kann ich die Zeiten genau abstimmen. Nochmal kurz zum Projekt: Die verwendete Wetterstation ist eine Ws2500, welche seit 2008 nicht mehr produziert wird. Daher sind Ersatzteile entweder bei Stationsauflösungen oder nur im Eigenbau erhältlich. Ich versuche mich hier gerade im zweiten Punkt. Um das die Wetterstation nicht dauerhaft das Empfangsmodul unter Strom setzen muss (Batteriebetrieb), wird per Funkprotokoll jedem Sensor ein genaues Zeitfenster zugewiesen, in welchem er zu senden hat. Hält er diese Zeit nicht ein, ist das Funkmodul bereits wieder aus und das Datenpaket geht ins leere und die Station meldet "Sensor nicht empfangen".
Angehängte Dateien:
-
receiver.JPG
20 KB
So, jetzt stimmt alles. Bin jetzt auf wenige Millisekunden an den geforderten Sendezeiten dran. Bei 175,5 Sekunden bin ich bei 175,493 Sekunden. Hab das Programm mal etwas vereinfacht und auf meiner Homepage geladen, um dass auch Ihr es nutzen könnt. Hier der Link: http://engi.bplaced.net/RS232-Receiver.exe Um es nutzen zu können, muss als Startzeichen eine # gesendet werden, nachfolgend können noch Nutzdaten gesendet werden. Die unten rechts laufende Zeit ist ein einfacher Delphi-Timer, die gemessene Zeit, welche ins Textfeld eingetragen wird, ist aber mittels "gettickcount" gemessen und damit deutlich präziser als der einfache Timer. Im Anhang noch ein kurzer Screenshot vom Programm in Aktion. Und damit Euch allen noch einen angenehmen Abend gewünscht.
Kai S. schrieb: > Da der PC auch nur einen Quarz hat wird der nicht besser sein, als > dein Quarz, sprich, du musst dir schon was genaueres zulegen. Du vergißt die Netzwerkfähigkeit der meisten PCs. Damit kommt der über ausreichend lange Meßzeit auf erheblich höhere Genauigkeit als so ein Feld-Wald-und-Wiesen-Quarz. Sonst hilft ein GPS Empfänger, der genauso gut, wie er den Standort bestimmt, auch die genaue Zeit berechnen kann. Zusammen mit EGNOS sind i.A. 3m Ortsgenauigkeit entsprechend 10ns Zeitgenauigkeit zu erwarten. Der 1PPS Ausgang läßt sich wunderbar zum µC führen, so dass der selber seine Quarzfrequenz messen kann.
Mr. Tom schrieb: > Du vergißt die Netzwerkfähigkeit der meisten PCs. Ich vermute, du redest davon ein Zeitsignal per Internet zu hohlen. Dabei muss man aber schon wieder bedenken, das auf den wenigsten PCs Echtzeitbetriebssysteme laufen und zudem für das Zeitsignal per Netzwerk noch die Latenz des Netzwerksignals kommt. Somit sind schon wieder sehr viele Kontrollpunkte und somit eine lange Zeit nötig, um eine statistisch langzeitstabile Zeitbasis zu bekommen. Dazu kommt noch, das die Hardwareschnittstellen nur mit wenigen kHz aktuallisiert werden, was für die eigentliche Messung auch wieder Messunsicherheiten produziert. GPS ist eine präzise Möglichkeit, eine weitere ist das DCF77 Signal, das stammt ebenfalls von einer Atomuhr. Ich persönlich würde vermutlich die Gelegenheit ergreifen und mir selbst eine Atomuhr zulegen, da es gebrauchte Rubidiumfrequenzstandards verhältnismäßig preiswert zu kaufen gibt. Wir diskutieren hier aber im Submillisekundenbereich, die den TO nicht weiter interessieren und sein Problem eh gelöst zu sein scheint. Von daher ist es jetzt auch uninteressant Zeitmessungen weiter zu zerpflücken. Gruß Kai
Moin. Jo, richtig. Dank der Verbesserung des Delphi-Programms, scheinen die eingestellten Zeiten nun auch problemlos zu funktionieren. Jetzt muss ich allerdings erstmal gucken ob der Sensor nun wirklich dauerhaft korrekt empfangen wird. Ich habe so die Vermutung, die beiden Kondensatoren am Uhrenquarz haben dessen Takt etwas runter gezogen, so dass dieser um 0,25 Sekunden zu langsam läuft.
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.