Vor längerer Zeit wurde hier über einen 10-12 stelligen Zähler diskutiert, was dann auch in einer Version mit Zeitinterpolation umgesetzt wurde. Beitrag "Re: DIY Frequency Counter mit 10 bis 12 Digits?" Ganz zum Schluß gab es noch Beiträge dazu, daß eine lineare Regression wider Erwarten keine höhere Auflösung gebracht hat. Passend zur Jahreszeit gibt es nun einen neuen Beitrag, bei dem ein hochauflösender Zähler grob beschrieben wird: Beitrag "Frequenzzähler BG7TBL FA-2 mein Weihnachtsgeschenk ist da ;-)" Einen Schaltplan dazu gibt es nicht, aber aus den Angaben in der Bedienungsanleitung läßt sich vermuten, daß es sich um einen reziproken Zähler mit 100 MHz Referenztakt handelt. Bei 1 Hz Eingangssignal werden 8 gültige Stellen gemessen. Ein Interpolator für die Zeitmessung ist daher wohl nicht vorhanden. Mit steigender Eingangsfrequenz steigt auch die Auflösung, die bei 10 MHz rund 11 Stellen beträgt. Da intern ein schnelles CPLD werkelt, kann dieser Zähler wohl auch Einzelintervalle bis zur max. Eingangsfrequenz erfassen und per Statistik auswerten, um dadurch höhere Auflösung zu erreichen. Das war für mich Anlaß, bei einem reziproken Zähler noch einmal einen Versuch mit Einzelintervallmessungen ("time stamp") und statistischer Auswertung zu machen. Gegenüber dem damals verwendeten STM32F407 kommt aktuell ein STM32H750 zum Einsatz, der mit 480 MHz Takt- und 240 MHz Timerfrequenz arbeitet. Double-Variablen verarbeitet eine Recheneinheit per Hardware, die sehr schnell >= 15-stellige Ergebnisse liefert. Der hier gezeigte 1. Versuch ist ein reziproker Zähler, der mit 240 MHz Referenzfrequenz problemlos 8-stellige Ergebnisse/s liefert (siehe Programm: F2_messung.c). Timer15 arbeitet als Ereigniszähler (PE5) mit Capture-Funktion (PE6). Timer16 zählt die interne Referenzfrequenz die per Capture-Eingang PB8 die genaue Zeitmessung erledigt. Der Referenztakt kommt von einem 10 MHz TCXO und wird an den Eingang PH0 weitergeleitet. Der µC erzeugt per PLLs die internen Takte. Das Schaltbild (siehe oben) ist auf die benutzen Bereiche reduziert. Das Eingangssignal F2 geht über den Inverter IC13 als Signal EREIG2 zum CLK-Eingang von D-FF IC3 und zum Eingang PE5 des µC, der als Zählereingang von Timer15 dient. Nach Ablauf der vorgegeben Messzeit (typ. 1 s) wird das Signal TRIG2 gesetzt, sodaß die nächste aktive Flanke vom D-FF den Q-Ausgang setzt, welches als Capture-Signal CAP2 zum einen auf PE6 (Capture-Eingang von Timer15) und zum anderen auf PB8 (Capture-Eingang Timer16) geht. Mit diesem Signal wird eine Messung synchron zum Eingangssignal abgeschlossen und die nächste Messung ohne Wartezeit gestartet. Danach wird TRIG2 wieder passiv, bis die nächste Messzeit abgelaufen ist. So läuft eine normale reziproke Einzelmessung ab. Um für die Regressionsberechnung nun möglichst viele Zeitstempel zu erfassen, wird per Timer17 der Ausgang TRIG2 jede µs gesetzt. Die nächste Eingangsflanke führt dann zum Abschluß bzw. Neustart der nächsten Messung. Bei 1 Hz Eingangssignal, ist nach wie vor nur eine Messung/s möglich. Bei höheren Frequenzen steigt die Messrate auf max. 1 MS/s. Eine Auswertung der Einzelmessungen wird aber erst nach 1 s Gesamtzeit durchgeführt. Bei einem Eingangssignal von 10 MHz werden rund 1E6 Einzelintervalle gemessen, wobei der Ereigniszähler (Timer15) typ. den Wert 10 und der Referenzzähler (Timer16) typ. den Wert 240 aufweisen. Da Eingangssignal und Referenzfrequenz nicht synchron sind, streuen diese typischen Werte um +/- 1. Berechnet man die Frequenz (F2_ergebnis) nach 1 s Messzeit aus den Summen der Zähler (reg_xi bzw. reg_yi mit 1E7 bzw. 2,4E8), so sind nur die Phasenabweichungen der 240 MHz Referenzfrequenz beim Start/Stopp relevant. Eine Änderung um +/- 1 geht in das Ergebnis nach einer Sekunde nur zu 1 / 2.4E-8 (ca. 4,2E-9) ein, was erst in der 9. Stelle sichtbar wird. (Zum Verständnis: Eine Änderung der Ereignisse ist nicht relevant, da die Messung immer synchron dazu abläuft und sich entsprechend die Anzahl der Referenzimpulse ändert.) Berechnung mit linearer Regression In der ISR TIM15_IRQHandler() werden zu jedem Messintervall die Einzelwerte vorverarbeitet: Anzahl reg_n, Zeitpunkt reg_yi zum Ereignis reg_xi und die Summen reg_sum_xiyi und reg_sum_xi². Zum Abschluß der Messung nach typ. 1 s wird aus den Zwischenwerten die Regressionsgerade errechnet, wobei zunächst die Steigung reg_b errechnet wird, aus der sich dann auch reg_a ergibt. Bei 1E6 Einzelintervallen könnte sich (lt. Theorie) eine Verbesserung der Auflösung um drei Stellen ergeben, was aus den ursprünglichen 8-stell. Ergebnissen dann 11 Stellen zaubern würde. zur Praxis Die Datei "lokal_10MHz_PWM.log" zeigt die Ergebnisse einer vom µC selbst erzeugten Frequenz im 1 s Abstand. Dabei ist das 1. Ergebnis erwartungsgemäß sehr stabil. Das 2. Ergebnis aus der Regressionsberechnung weicht mit "5" erst in der 12. Stelle vom idealen Wert ab. Bei Rundung auf 11 Stellen wären 1. und 2. Wert identisch. Den 2. Test zeigt "lokal_1MHz_ISR.log", wobei wiederum der µC seine eigene per ISR erzeugte Frequenz misst. Obwohl hier mehr Jitter im Signal vorhanden sein muß, sind die Ergebnisse beider Messungen identisch. Soweit so schön. Die 3. Datei "extern_26MHz_OCXO.log" zeigt bei der Messung per Regression ein um eine Stelle schlechteres Ergebnis, als es die normale reziproke Messung mit 2.60000331E+07 liefert. Beide Oszillatoren sind warmgelaufen und der OCXO liefert mit einem anderen 10-stell. Zähler stabile Werte, die zwar langsam in der 10 Stelle driften aber nicht hin und her springen. Mit der Regressionsmessung hätte ich ein zumindest gleichwertiges, 10-stell. Ergebnis erwartet. Wie würdet Ihr die Ergebnisse interpretieren?
Angehängte Dateien:
-
Fmeter_H750_reduziert.png
130 KB
Lineare Regression bringt nur etwas bei Fehlern mit gaußscher Verteilung. Bei Dir kommt der Fehler durch den Jitter des Referenztakts und die endliche Torzeit zustande. Der einzige Faktor, der gaußsch sein könnte, ist ersteres. Wenn der Fehler durch die Torzeit größer als der durch Rauschen ist, bringt Dir die Regression nichts. Nachtrag: Wir sind ja noch analog....also ersetze "Jitter" durch "Phasenrauschen". Der Rest der Aussage bleibt aber bestehen.
:
Bearbeitet durch User
Ein IRQ Handler ist nun nicht ganz die hohe Schule des Zaehlens. Schmeiss weg und komm mit einem CPLD/FPGA.
Joggel E. schrieb: > Ein IRQ Handler ist nun nicht ganz die hohe Schule des Zaehlens. Der Trick am Capture-Interrupt ist ja, daß es keine Rolle spielt, wann genau man das Captureregister ausliest. Es muß nur vor der nächsten gleichen Flanke des Eingangssignals erfolgen.
Ja,ja. Wenn die Signalkonditionierung passt. Sonst hast du Fehltriggerungen und zuviele Interrupts.
Walter T. schrieb: > Bei Dir kommt der Fehler durch den Jitter des Referenztakts > und die endliche Torzeit zustande. Der Jitter im µC liegt unter 1 ns. Im o.g. 2. Link ist zu sehen, daß es prinzipiell funktioniert. Die Randbedingungen sind dort ähnlich. Naja schrieb: > Fehltriggerungen und zuviele Interrupts. Keine Sorge! Da Interrupts nur freigegeben werden, wenn wieder Zeit dafür ist, gibt es derer weder zu viele noch Fehltriggerungen. Man kann es im Programm nachverfolgen; ich wollte im Text nicht jedes Detail ansprechen - der ist schon lang genug.
Walter T. schrieb: > Lineare Regression bringt nur etwas bei Fehlern mit gaußscher > Verteilung. Bei Dir kommt der Fehler durch den Jitter des Referenztakts > und die endliche Torzeit zustande. Die Lösung wäre, über mehrere Torzeiten zu integrieren. Senkt den Jitter und auch den Samplefehler.
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.