reziproker Frequenzzähler mit STM32F4Discovery

[m.n. (Gast)]

Bislang bieten sich für kostengünstige reziproke Frequenzzähler 
AVR-Prozessoren an, die mit max. 20MHz Taktfrequenz bei einer Messrate 
von 2 Mess./s 7-stellige Ergebnisse liefern können. Dazu gibt es in 
diesem Forum diverse Schaltungs- und Programmbeispiele. Eine 
Beschreibung der Funktionsweise findet sich hier: 
http://www.mino-elektronik.de/fmeter/fmeter.htm#funk
Folgt man den angegebenen Links, finden sich weitere Schaltungen und 
Beispielprogramme für unterschiedliche Anwendungen.

Die µC STM32F4xx bieten mit 168MHz eine sehr hohe Rechenleistung. Zudem 
sind einige der internen Timer in der Lage mit dieser hohen Frequenz 
ohne einschränkende Vorteiler umzugehen. Gegenüber einem 20MHz AVR läßt 
sich eine um grob Faktor 10 höhere Auflösung der Messung erreichen – bei 
gleicher Messzeit von 2 Mess./s.
Genau genommen müßte man die max. Meßrate auf 1,68Mess./s einstellen, 
was anzupassen jedem Anwender freisteht. Ein 'runder' Faktor 10 im 
Vergleich zum AVR ist allerdings werbewirksamer :-)

Das STM32F4-Discovery-Board bietet in Verbindung mit einem IAR 
Kickstart-Embedded-Workbench eine kostengünstige Möglichkeit, Schaltung 
und Programm zu erproben. Für die Messwertausgabe wird hier ein 4,3" 
TFT-Display verwendet, was auch noch Platz für die Anzeige der internen 
Zählerstände bietet. Für eigene Versuche muß die Ausgabe auf die 
vorhandene Anzeige angepaßt werden. Oder man übergibt die Werte per 
RS232/USB an einen Rechner, um sie dort anzuzeigen.

Das angehängte Programm 'f_mess.c' wertet die Frequenz an PE5 aus, wobei 
die Eingangsimpulse per Interrupt gezählt und die exakten Zeitpunkte 
über das Capture-Register1 vom Timer9 erfasst werden. Timer9 läuft dazu 
mit den maximalen 168MHz.
Ohne weiteren Vorteiler lassen sich direkt an PE5 Frequenzen von 0,05Hz 
– 2,5MHz messen. Verwendet man den internen Vorteiler /8 der 
Capture-Einheit, verschiebt sich der Meßbereich auf 0,4Hz – 20MHz. Da 
durch den Vorteiler mindestens 8 Eingangsimpulse für einen 
Capture-Impuls eintreffen müssen, eignet sich der Vorteiler erst ab >= 
20Hz Eingangsfrequenz.

Für ein 8-stelliges Ergebnis ist eine hinreichend konstante HSE-Frequenz 
notwendig. Die Testschaltung verwendet einen 20MHz TCXO, eine 
konstantere Taktquelle wäre besser. Für erste Versuche reicht aber auch 
der vorhandene 8MHz Quarz, wobei allerdings R68 (auf der 
Platinenunterseite) entfernt werden aollte.
Timer9 hat eine 2. Capture-Einheit, die mit PE6 getriggert werden kann. 
Hier könnte man ein externes, hochgenaues GPS-Signal auswerten und einen 
Korrekturwert zum TCXO ermitteln, wie dies auch hier gemacht wird: 
Beitrag "reziproker Frequenzzähler, GPS-stabilisiert, ATmega162"

Das angehängte Foto der TFT-Anzeige zeigt neben Frequenz und 
Periodendauer auch die Zählerstände Nin und Nref bei der Taktfrequenz 
von 168MHz, sowie die Dauer der Messung. Ein buntes Bild animiert 
vermutlich eher zum Nachbau als die nüchterne Beschreibung :-)

[Peter D. (peda)]

m.n. schrieb:
> Für ein 8-stelliges Ergebnis ist eine hinreichend konstante HSE-Frequenz
> notwendig.

Es wäre mal interessant, wie sich der Jitter der PLL auf die 
Meßgenauigkeit auswirkt.
D.h. wie konstant die 168Mhz sind, die aus den 20MHz erzeugt werden.



Peter

[m.n. (Gast)]

Peter Dannegger schrieb:
> Es wäre mal interessant, wie sich der Jitter der PLL auf die
> Meßgenauigkeit auswirkt.

Das hat mich natürlich auch sehr interessiert.

Die ersten Versuche hatte ich mit dem vorhandenen 8MHz Quarz gemacht, 
wobei sich herausstellte, dass R68 unbedingt entfernt werden muß. 
Zyklische Schwankungen der Ergebnisse (ca. 1ppm) im ca. 10 Sekundentakt 
waren nach dem Auslöten verschwunden. R68 hat wohl garkeine Funtkion und 
ist absoluter Müll für stabiles Timing!

Dann hatte ich einen GPS-Empfänger EM-406 mit 1pps-Ausgang angeschlossen 
und hatte Aussetzer von rund 60ns alle 2-10 Sekunden. Nachdem ich 
vergeblich die störenden 10 Befehlszyklen (10 x 6ns = 60ns), die ich 
vermutete, im Programm nicht finden konnte, nahm ich Jitter des 
Oszillators/des Controllers als Ursache an.

Also, 20MHz TCXO angebaut, Faktor M auf 10 eingestellt (PLL mit 2MHz 
Basistakt) und - die Schwankungen waren immer noch vorhanden. Das wäre 
fast das vorzeitige Ende des Experimentes gewesen.

Erst ein angelegtes 1kHz Signal, heruntergeteilt von einem OCXO, 
lieferte ein sehr überzeugendes Ergebnis. Nach ein paar Minuten 
Aufwärmzeit wurde die Periodendauer mit 999.99983ms angezeigt (Messrate 
temporär auf 1 Mess./s reduziert), wobei die letzte Ziffer über Minuten 
hinweg '3' oder '4' anzeigte. Da kam dann Freude auf :-)

Fazit: beim beschriebenen Meßverfahren ist kein Jitter des µC 
festzustellen; GPS dagegen jittert sehr, was man auch vielfach im I-net 
nachlesen kann.
Es gibt noch mehr Erfahrungswerte aus meiner Spielerei, aber das würde 
hier zu weit führen.

[m.n. (Gast)]

Um die Messwerte auch mit einem einfachen LCD-Modul 2x16 anzuzeigen, 
habe ich das Programm angepaßt und als 'f_mess_lcd.c' angefügt. Damit 
das Anzeigeformat paßt, ist die Anzahl der Stellen auf 7 reduziert und 
die Messrate auf 5 Mess./s erhöht.
Die Ansteuerung der LC-Anzeige ist hier zu finden: 
Beitrag "LCD-Modul 2x16 am STM32F4Discovery-Board"

Bevor die Meßfunktion 'f_mess()' aufgerufen wird, muß mit 'lcd_init()' 
die LCD-Ausgabe vorbereitet werden. Ich hoffe, die Programmteile lassen 
sich auch mit anderen Compilern (!= IAR-Kickstart) problemlos verwenden.

[ansel (Gast)]

m.n. schrieb:
> R68 hat wohl garkeine Funtkion und
> ist absoluter Müll für stabiles Timing!

Bin ich auch schon drauf reingefallen: 
Beitrag "stm32f4discovery: HSE-XO frequenzmoduliert?"

Peter Dannegger schrieb:
> Es wäre mal interessant, wie sich der Jitter der PLL auf die
> Meßgenauigkeit auswirkt.
> D.h. wie konstant die 168Mhz sind, die aus den 20MHz erzeugt werden.

Ich verwende mein F4-Discovery-Board als VFO für einen 
I/Q-Kurzwellenmischer, und war nach der genannten Anpassung positiv 
überrascht.  Bei anderen PLLs aus der Bastelkiste wurde es um 0Hz herum 
meist ziemlich hässlich, oder sie "rülpsten" gelegentlich. Bei der PLL 
im stm32f4 konnte ich bisher keinen Unterschied zum Quarzbetrieb 
feststellen.

[m.n. (Gast)]

ansel schrieb:
> Bei der PLL
> im stm32f4 konnte ich bisher keinen Unterschied zum Quarzbetrieb
> feststellen.

Normalerweise überschlage ich Seiten im Datenblatt, wo interne Daten 
aufgeführt sind, die durch eine äußere Beschaltung eh nicht zu verändern 
sind. Eher zufällig bin ich daher im Datenblatt des STM32F407 auf nähere 
Angaben zur PLL gestoßen, die in Bezug auf die Taktgüte doch sehr 
hilfreich sind.

In Tabelle 32 auf Seite 90 wird der max. Jitter der PLL mit +/- 0,2ns 
angegeben. Bei HF-Anwendungen, die den Prozessortakt als Referenz 
einbeziehen, kann man sicherlich irgendein Rauschen darauf zurückführen. 
Hier jedoch sind 0,2ns bezogen auf die ca. 6ns Periodendauer (und hier 
der Auflösung der Messung) ein vernachlässigbarer Wert.

Ich denke, die Angabe im Datenblatt schafft abschließende Klarheit.