Hallo zusammen, nachdem ich quasi noch nie eine RTC an einem STM32 "genau" hinbekommen habe und das immer nur irgendwie pseudo-mäßig hingepfuscht habe, hatte ich mir vorgenommen, das mir mal systematisch anzuschauen. Mein Mess-"Setup" sieht so aus: - STM32 hängt über USB (CDC) am PC - auf dem PC läuft ein Programm, das folgendes macht: - wartet auf eine neue Sekunde - ruft ein Kommando auf dem STM32 auf mit dem Parameter der aktuellen Zeit + 2 Sekunden. - STM32 meldet per USB erst zurück, wenn die RTC die Zeit erreicht hat (ist quasi sowas wie Long-Polling, wenn man es mit HTTP vergleichen würde). - das PC Programm hat gemessen, wie lange es dauert, bis der STM32 zurückmeldet, dass er die Zeit erreicht hat. - das wird Protokolliert - Abweichung ist gemessene Zeit minus 2 Sekunden. (negative Werte: RTC zu schnell, positive Werte: RTC zu langsam) Das ganze sieht man im Bild über einen Zeitraum von 58668s (16Std 17Min in etwa). Was mich daran irritiert ist die Kurvenform - die sieht sehr nach einer Lade- und Entlade-Kurve von Kondensatoren aus. Ich würde mich sehr freuen, wenn jemand eine Erklärung für mich hätte, wieso das so seltsam aussieht und die Frequenz der RTC sich so e-förmig ändert :) Vielen Dank! Mampf
Angehängte Dateien:
:
Bearbeitet durch User
2aggressive schrieb: > Zeitkonstante der Software-pll aufm PC? > https://de.wikipedia.org/wiki/Network_Time_Protocol Interessante Idee! D.h. ich müsste nur den systemd-timesync service mal abschalten und dann nochmal einen Run machen :)
Mampf F. schrieb: > Das ganze sieht man im Bild über einen Zeitraum von 58668s (16Std 17Min > in etwa). Vielleicht kehrst du mal die Achsen im Diagramm um, also die Zeit (am besten zusätzlich reale Uhrzeit) auf X und die Abweichung auf Y, hier am besten im log. Maßstab?
Mampf F. schrieb: > nur den systemd-timesync service mal abschalten und dann > nochmal einen Run machen :) Jein. Dann biste von der "Eieruhr" Linux (nebenbei: die RTC aufm Mainboard hat im laufenden Betrieb nichts damit zu tun) abhängig, das kann gewaltig daneben liegen; bei dem Rechner auf dem ich gerade schreibe etwa 2s pro Tag. Um den Zweck (dein STM, oder irgendeine andere Uhr) des Zeitvergleichs zu erfüllen halte ich folgendes für besser: den aktuellen offset deiner PC-Systemzeit bei der Erstellung des Diagramms berücksichtigen, die PTB ist dabei dein Freund; $ ntpdate -q ptbtime2.ptb.de Ausserdem: du sammelst viel zu viele Daten, einmal alle 100 (1000) Sekunden reicht völlig. Sekundentakt spielt die PTB nicht mit.
Des Spasses halber könntest du:
$ while [ 1 ]; do ntpdate -q ptbtime2.ptb.de | grep delay | awk -F ","
'{print $3}'; sleep 100; done
für ein paar Stunden laufen lassen, dann siehst du, wie dein
"systemd-timesync" regelnderweise reingreift; das war ja deine
eigentliche Frage.
Sorry wegen der missglückten Formatierung, ich probiers nochmal; In der Shell:
1 | while [ 1 ]; do ntpdate -q ptbtime2.ptb.de | grep delay | awk -F "," '{print $3}'; sleep 100; done
|
Was hast Du denn für ne Zeitbasis auf dem STM32? LSE + Uhrenquarz oder etwas anderes? Hast Du Dir den Takt davon mal am MCO ausgeben lassen und mal mit nem Frequenzzähler angeschaut? Wenn kein Frequenzzähler vorhanden, wäre eine billige Alternative ein Logicanalyzer zu nehmen und MCO sowie auf einem anderen Kanal das 1 PPS Signal von einem GPS gleichzeitig über längere Zeit aufzunehmen und die dann zu vergleichen. Durch einen solchen Vergleich schließt Du den PC, NTP etc. als Ursache aus.
Gerd E. schrieb: > Was hast Du denn für ne Zeitbasis auf dem STM32? LSE + Uhrenquarz Jup, genau das :) > Hast Du Dir den Takt davon mal am MCO ausgeben lassen und mal mit nem > Frequenzzähler angeschaut? Hmm, ich meine gesehen zu haben, dass man den LSE-Takt nicht direkt wieder ausgeben kann. Ich hab jetzt aber mal NTP eingebaut - Glonass/GPS Zeit-Quelle sollte genau genug sein :) Den darf ich nur nicht so bruteforcen (zum finden des Starts der nächsten Sekunde), wie ich das mit meiner lokalen RTC gemacht hab^^ Mal schauen, wie es bis morgen aussieht :)
:
Bearbeitet durch User
und welcher STM32? bei den neueren Serien ist das mit dem LSE Quarz komplizier, da kann man den drive level per Software einstellen. Ein Quarz der mehr Power braucht läuft mit den defaults nicht oder instabil.
Mampf F. schrieb: > Gerd E. schrieb: >> Was hast Du denn für ne Zeitbasis auf dem STM32? LSE + Uhrenquarz > > Jup, genau das :) Bist Du mal die AN2867 von ST genau durchgegangen? Da stehen ein paar wichtige Punkte zur Berechnung der Kapazitäten, Drive-Level etc. drin. >> Hast Du Dir den Takt davon mal am MCO ausgeben lassen und mal mit nem >> Frequenzzähler angeschaut? > > Hmm, ich meine gesehen zu haben, dass man den LSE-Takt nicht direkt > wieder ausgeben kann. Huh, sicher? Ich hab das mal für so eine Messung gemacht. Hängt vermutlich vom genauen Modell Deines STM32 ab was da an Clock-Routing möglich ist. Was hast Du für ein genaues Modell von STM32? > Ich hab jetzt aber mal NTP eingebaut - Glonass/GPS Zeit-Quelle sollte > genau genug sein :) Also NTP auf Deinem PC? Dann hast Du halt immer noch den PC, Dein Programm, den Treiber für die Schnittstelle, USB, ... was da noch mit rumspuken kann und Dir hübsche Artefakte in Deiner Messung hinterlassen kann.
Gerd E. schrieb: > Mampf F. schrieb: >> Gerd E. schrieb: >>> Was hast Du denn für ne Zeitbasis auf dem STM32? LSE + Uhrenquarz >> >> Jup, genau das :) > > Bist Du mal die AN2867 von ST genau durchgegangen? Da stehen ein paar > wichtige Punkte zur Berechnung der Kapazitäten, Drive-Level etc. drin. Die AN2867 hab ich gewissenhaft mehrmals durchgeackert und hab mir dann einen Quartz (12.5pF) besorgt, der da als kompatibel aufgeführt war. Es handelt sich um einem STM32F302. >>> Hast Du Dir den Takt davon mal am MCO ausgeben lassen und mal mit nem >>> Frequenzzähler angeschaut? >> >> Hmm, ich meine gesehen zu haben, dass man den LSE-Takt nicht direkt >> wieder ausgeben kann. > > Huh, sicher? Ich hab das mal für so eine Messung gemacht. Hängt > vermutlich vom genauen Modell Deines STM32 ab was da an Clock-Routing > möglich ist. Oh du hast recht - ich hatte zuletzt in CubeMX den Clock-Ausgang auf der rechten Seite des Clock-Configurations-Dialogs gesucht ... dabei ist er ganz unten links und man kann für MCO auch den LSE auswählen. Danke, da hätte ich nicht nochmal geschaut! >> Ich hab jetzt aber mal NTP eingebaut - Glonass/GPS Zeit-Quelle sollte >> genau genug sein :) > > Also NTP auf Deinem PC? Dann hast Du halt immer noch den PC, Dein > Programm, den Treiber für die Schnittstelle, USB, ... was da noch mit > rumspuken kann und Dir hübsche Artefakte in Deiner Messung hinterlassen > kann. Hmm ja stimmt - ich schau mal, dass ich mein Oszi an den MCO angeklemmt bekomme. Direkt am Quartz kann man ja unmöglich messen und ich fand es doof, dass man den LSE-Clock nicht aus den STM32 bekommt - aber es geht ja doch :)
Angehängte Dateien:
So, es gibt ein neues Bild (sowas 13,5h) und ich muss sagen, das sieht ganz gut aus. Jittert zwar viel - vmtl durch Netzwerk, dem recht groben Polling auf die neue Sekunde usw -, aber man kann wunderbar eine Ausgleichsgerade durchlegen. So reicht mir das :) Vielen Dank nochmal für euren Input! Jetzt muss ich dann die Cs noch ein bisserl kleiner machen und hoffe dann, dass ich die geschätzt 500ms pro Tag Abweichung noch etwas niedriger bekomme.
:
Bearbeitet durch User
Warum hängst du nicht direkt den 1PPS-Impuls von einem GPS-Modul an den STM und vergleichst die Phasenlage mit dem Sekundentakt deiner RTC (z.B. per Timer Capture). Dann bist du unabhängig vom PC/Netzwerkkram und Jitter. Den Gang deiner RTC kannst du dann innerhalb von einer Minute bestimmen.
Wolfgang schrieb: > Warum hängst du nicht direkt den 1PPS-Impuls von einem GPS-Modul > an den > STM und vergleichst die Phasenlage mit dem Sekundentakt deiner RTC (z.B. > per Timer Capture). Dann bist du unabhängig vom PC/Netzwerkkram und > Jitter. Den Gang deiner RTC kannst du dann innerhalb von einer Minute > bestimmen. Hmm, das ist eine gute Idee ... eventuell hab ich noch eins dieser 10eur-GPS-Modülchen irgendwo rumliegen. Soweit ich weiß, geben die an den Ausgang direkt eine digitale Version des DCF-Signals ohne sonst noch was daran aufzubereiten. Den 1Hz-Takt kriegt man so ja glaube ich direkt als high-low-Flanke.
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.