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 :-)
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
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.
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.
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.
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.
FM_STM32F4_1_1.jpg
(360 KB)
