Frequenzzähler mit 8-Bittern gibt es viele, die für die meisten Anforderungen ausreichen. Geht es jedoch darum höhere Auflösungen oder besonders hohe Messraten zu erreichen, stößt man damit schnell an Grenzen. Nachfolgende Schaltung/Programm zeigen einen reziproken Frequenzzähler mit einem schnellen µC, der ohne große ext. Beschaltung 8-stellige Messwerte/s im Bereich 0,1 Hz – 100 MHz liefert. Wird diese hohe Auflösung nicht benötigt, ermöglicht die hohe Rechengeschwindigkeit auch 'locker' 1000 Messungen/s mit 5-stell. Auflösung. Das alles mit gerigem Aufwand, zu geringen Kosten. Hardware: Die gezeigte Schaltung ist auf die Funktionen/Bauteile reduziert, die notwendig sind, um eine beispielhafte Messung über den Eingang F2 zu zeigen. Von oben nach unten sieht man den Spannungsregler 5 -> 3,3 V. Weiterhin den SWD-Steckverbinder zur Programmierung und den RS232 Treiber für die ser. Schnittstelle USART3. Das Eingangssignal geht über den Inverter IC13 an das D-FF IC3, welches zur Synchronisierung der Auswertung mit den Eingangsimpulsen benötigt wird. Abschließend erzeugt ein TCXO die 10 MHz Referenzfrequenz für den µC. (Ein genauer Abgleich ist mit einem VCTCXO und 10-Gang Trimmer möglich.) Das gekappte Sinussignal wird über einen Inverter aufbereitet und dann auf den Takteingang PH0 des µCs geführt. Der gezeigte Multiplexer IC14 wird nicht benötigt und kann durch Verbinden von Pin3 und Pin4 überbrückt werden. Abweichend von der Beschriftung ist das nachfolgende Programm für STM32F7xx geschrieben, wobei als Minimalversion ein STM32F730 reicht. Andere Controller der F7xx-Reihe sind pin- und funktionskompatibel. Nach Programmanpassung können auch µCs der H75x-Reihe verwendet werden, die pinkompatibel sind. Software: Die Software mißt die Frequenz an Eingang F2 reziprok und lückenlos mit einer Auflösung von 8 Stellen/s. Die Ausgabe der Ergebnisse erfolgt per RS232 mit 115200 Baud. Die angehängte .zip-Datei zeigt ein Projekt mit einer IAR-IDE V8.xx für ARM Controller. Mit der kostenlosen Demoversion sollte sich das Projekt direkt aufrufen und bearbeiten lassen. Die Codebeschränkung auf 32 kB stellt hier kein Hindernis dar. Aktuell werden ca. 12 kB benötigt. Andere IDEs/Compiler sollten kein Problem sein, wobei darauf geachtet werden muß, die Dateien "main.c", "F2_messung.c" und "usart3.c" nebst einigen .h-Files für den STM32F730 einzubinden. Das Projekt baut auf der von STM32CubeMX erzeugten "main.c" auf. Die Hauptaufgabe von "main.c" besteht darin, Caches und Interrupts zu konfigurieren und die Taktfrequenz des Systems von ext. 10 MHz auf 216 MHz (SystemCoreClock) einzustellen. Das HAL-Zeugs ist ohne Belang und wird im weiteren Programmablauf ignoriert. In main() wird einmalig die Frequenzmessung mit F2_messung(1) gestartet und in einer Dauerschleife mit Aufruf von F2_messung(0) fortgeführt. In "F2_messung.c" werden ca. 1,5 Messungen/s mit 8-stelliger Auflösung gemacht. Die benötigte Hardware (IO-Ports, Timer) wird mit direkten Registerzugriffen initialisiert und die notwendigen Konstanten sind am Anfang der Quelldatei definiert. Die Beschreibung nebst Kommentaren im Programm sollten die Funktion verdeutlichen. "usart3.c" erledigt die ser. Ausgabe der Messwerte über USART3 und muß nicht weiter beachtet werden. Wie gesagt, wird hier nur ein Teil einer bestehenden Schaltung gezeigt. Prinzipiell wäre auch ein Demoboard (STM32 Nucleo) verwendbar, um den mechanischen Aufbau einfach zu halten. Es müßten jedoch ext. Lösungen für den TCXO und das D-FF gefunden werden. Alternativ ist für Interessierte eine unbestückte Leiterplatte verfügbar. Damit wären direkte Erweiterungen möglich wie LC-Anzeige, EEPROM zur Speicherung der internen Konstanten, ein weiterer Eingangskanal mit Eingangskomparator, Anschluß einer ext. Referenzfrequenz, Taster + LEDs. Die STM32F7xx sind recht schnell, sodaß bei höheren Eingangsfrequenzen einige 10000 Messungen/s möglich sind. Das kann man dazu nutzen, per statistischer Berechnung die Auflösung um zwei weitere Stellen auf zehn zu erhöhen. Bei Interesse und genügend Zeit, könnte ich das vorliegende Programm schrittweise ergänzen.
Angehängte Dateien:
-
Fmeter_H750_reduziert.png
130 KB
Mi N. schrieb: > Bei Interesse und genügend Zeit, könnte ich das vorliegende > Programm schrittweise ergänzen. Mach bitte weiter mit dem Projekt, dann kann ich wiedermal was dazu lernen!
Es gibt eine erweiterte Version, die auch ein paar Kleinigkeiten korrigiert hat. Das Programm "F2_messung_reg.c" bietet eine höhere Auflösung mit bis zu 11 Stellen abhängig von der Eingangsfrequenz. Maximal werden 500000 Einzelintervalle/s gemessen und per linearer Regression ausgewertet. Die Datei finde sich hier: http://www.mino-elektronik.de/progs/Fmeter_F730/Fmeter_F730_V2.zip Die Grundauflösung ist wie gehabt 8-stellig, steigt jedoch mit Wurzel aus der Anzahl der Einzelintervalle mit zunehmender Eingangsfrequenz. Bei 1 s Messzeit sind folgende Auflösungen zu erwarten: 0,1 Hz - 50 Hz: 8-stellig 50 Hz - 5 kHz: 9-stellig 5 kHz - 500 kHz: 10-stellig über 500 kHz: 11-stellig Erhöht man die Messzeit auf 10 s erhält man eine weitere Stelle Auflösung hinzu. Zu beachten ist, daß für derartige Ergebnisse äußerst stabile Signale für Eingangs- und Referenzfrequenz benötigt werden. Die weitere Funktionsbeschreibung findet sich im Quellcode. Neben der Ausgabe auf RS232 kann der Messwert auch auf einem 16x2 LCD-Modul angezeigt werden: "Fmeter_F730_LCD.c"
:
Bearbeitet durch User
hast du TXCO + 74AUP1G74 übrig die du verkaufen würdest? Ansonsten habe ich diesen 10 MHz bei Mouser gefunden, passt der? https://www.mouser.de/ProductDetail/Fox/FOX924B-10000?qs=Omyi%252BwOkBJXDHwx3N7H2ew%3D%3D Ich habe noch einige F407 oder H743 Boards, damit würde ich das gerne mal aufbauen.
F407 sollte kein Problem sein und fast 1:1 funktionieren. Man muß beachten, daß beim F407 kein TIMPRE Bit existiert und die Timer 6, 7 und 13 nur mit halber "Kern"frequenz arbeiten. Ab dem F427 gibt es dann aber doch die volle Taktfrequenz. Beim H743 muß man bei gleicher Portbelegung andere Timer verwenden: Timer15 statt Timer9 und Timer16 statt Timer10. Ganz wichtig ist jedoch die Initialisierung der GPIOs. Nach einem Reset sind die MODER auf "Analog mode", wobei beide Bits auf 1 gesetzt sind. Um Portpins auf einen anderen Modus einzustellen, müssen diese Bits zuvor explizit gelöscht werden. Das hatte ich ursprünglich in meinem Code mit drin, wegen der Übersichtlichkeit aber wieder entfernt. Zudem werden Timer/GPIO unter Umständen an anderen Bussen betrieben als beim F4/F7: Das Referenzhandbuch ist sehr lesenswert ;-) Ich habe auch Boards mit F407/429 und H750 zu liegen und passende Programme dazu. Vielleicht mache ich dafür auch noch kleine .zip-Projekte. Erfahrungsgemäß sind die F407 auf Grund niedrigerer Taktfrequenz etwas langsamer als der F730, der ja auch noch keine double-Funktionen per Hardware bietet. Der H750 bietet double per Hardware, was ihn aber wider Erwarten beim vorliegenden Programm garnicht so "zündend" schnell macht. Vorteil ist bei deren letzten Revisionen eher die höhere CPU-Taktfrequenz mit 480 bzw. 550 MHz und die damit auch schnelleren Timer (240 bzw. 275 MHz). Anbieten kann ich Dir ein "Set" aus VCTCXO (0,5 ppm, Datenblatt im Anhang) und 74AUP1G74 für einen Euro. Diese freihändig zu verdrahten dürfte aber wegen deren Größe (3,2 x 2,5 mm²) bzw. VSOP8 (0,5 mm Raster) schwierig sein. Falls Du eine Leerplatine für die Schaltung haben möchtest, kann ich Dir diese zu drei Euro anbieten. Für den Briefversand müßten 80 Cent ausreichen. Um die Funktion zu testen, würde ich aber zunächst möglichst wenig Aufwand treiben. Das bedeutet, der vorhandene Quarz (muß ja nicht unbedingt 10 MHz haben) ist gut genug und als D-FF reicht auch ein 1/2 74HCT74. Das bekommt man per Hand an jedes Board "gepappt" und hat so schneller ein Erfolgserlebnis.
:
Bearbeitet durch User
ja, habe auf deiner Website noch einiges gelesen. Sehr schön das du alles gut dokumentiert hast und zur Verfügung stellst. Die Boards die habe sind die fertigen Chinaboards, da müsste dann nur die zusätzliche HW für TCXO, FF und evtl. Einangsstufe dran. Die vorhande Platine ist mit µC geplant wie ich das auf deiner Website sehe, die könnte man teilbestücken, wäre dann viel Platzverschwendung. Dann werde ich wie vorgeschlagen erstmal mit einfachem Quarzoscillator testen. So extreme Anforderungen habe ich nicht, ich kam darauf weil ich gerade Probleme mit dem LSE clock beim H743 hatte und wollte mal den Uhrenquarz messen. Aber dafür reichte bisher ein High End Aneng AN8009 mit 4 Stellen :)
Johannes S. schrieb: > ich kam darauf weil ich > gerade Probleme mit dem LSE clock beim H743 hatte Das habe ich aufmerksam verfolgt. Die vielen Fallen beim H7 sind Dir dann ja schon begegnet ;-) Für 32 kHz und 1 ppm Auflösung/Genauigkeit würde aber schon ein ATmega48 ausreichen. Für ein F407 Discovery-Board hatte ich hier vor Jahren ein Beispiel gezeigt: Beitrag "Re: reziproker Frequenzzähler mit STM32F4Discovery" Und wenn Du ein F429 Discovery-Board mit TFT-Anzeige hast, gibt es das gleiche auch in bunt: Beitrag "STM32F429-Discovery Recycling: 90 MHz Frequenzzähler mit TFT", falls es hilft.
Angehängte Dateien:
-
MiNo-FMeter.jpg
200 KB
Mi N. schrieb: > Und wenn Du ein F429 Discovery-Board mit TFT-Anzeige hast, jo, liegt auch in meiner Sammlung und lief mit deiner PnP Version auf Anhieb.
Angehängte Dateien:
-
Fmeter_H750_minimal.jpg
220 KB
Johannes S. schrieb: > jo, liegt auch in meiner Sammlung und lief mit deiner PnP Version auf > Anhieb. Das freut mich. Wenn Karneval mal ausfällt, merkt man, daß die "ollen Kamellen" auch noch schmecken können ;-) Mittlerweile habe ich noch Programmversionen für den F407 und den H750 angepaßt: http://www.mino-elektronik.de/progs/Fmeter_F730/Fmeter_F407_V2.zip http://www.mino-elektronik.de/progs/Fmeter_F730/Fmeter_H750_V2.zip Abschließend noch ein Bild einer minimal bestückten Platine mit H750 ohne Display. Von links nach rechts, oben nach unten: TCXO mit Inverter; µC mit SWD Steckverbinder; Spannungsregler, RS232-Treiber, Eingangsinverter und D-FF; Steckverbinder 5V-Versorgung, RS232, Eingangsbuchse.
ich habe auch noch das Trimmpoti für den Abgleich angeklemmt und den TXCO habe ich bei Mouser mitbestellt. Ist zwar ein 'schlechter' mit 2 ppm, aber der wird immer noch besser als der org. Quarz sein. Das F750 board hätte ich ja eher direkt mit USB ausgerüstet, auch wenn die 115 kBit schnell genug sind um den Messwert zyklisch zu senden. Mit der Messmöglichkeit mit dem Board bin ich aber erstmal zufrieden.
Johannes S. schrieb: > Das F750 board hätte ich ja eher direkt mit USB ausgerüstet, Es gibt auch Versionen mit Anschlüssen für USB, CAN und SPI sowie mit TFT-Anzeige. Daran kann man dann programmieren bis der Arzt kommt. Mit geht es primär um ein möglichst effizientes Messverfahren, und da würde ich zunächst an anderen Schrauben drehen.
Angehängte Dateien:
-
Fmeter_G431.png
81 KB
Die eingangs gezeigte Schaltung war in der 1. Version mit einem F407 im 100 pol. LQFP Gehäuse aufgebaut. Bei der Umstellung auf die leistungsfähigeren F7xx und H7xx ist es beim 100 pol. Gehäuse geblieben, wobei leichte Layoutänderungen notwendig waren. Wenn man höchste Leistung braucht, sollte man einen >= H730 einsetzen, der aktuell mit 575 MHz rennt. Das LQFP100 ist dann das kleinste verfügbare Gehäuse. Daran kann man nichts ändern. Auf der Suche nach einer Vereinfachung der Schaltung (und damit auch einfacher Bestückung des µC) bin ich auf den STM32G431K im LQFP32 gestossen. Mit einem "großzügigen" Pinabstand von 0,8 mm ist er genau so groß wie ein ATmega328-AU. Laut Datenblatt kann man ähnliche Rechenleistung wie von einem F407 erwarten. CPU, RAM und Timer laufen ungebremst mit 170 MHz. 128 KB Flash und 32KB RAM sind völlig ausreichend. Da ich eh noch einige Schaltungsvarianten testen wollte, habe ich ein neues Layout gemacht, zu dem ich derzeit die Leiterplatten "dringend" erwarte. Folglich habe ich meine Programmierung auf die neue Schaltung (siehe Schaltplan) ausgerichtet. Auf µC, RS232-Treiber, EEPROM (FRAM), 3,3 V Spannungsregler und 2x16 LC-Anzeige muß ich nicht weiter eingehen. Das LCD teilt sich die Datenleitungen mit den Bedientastern '+', '-' und 'init'. Der Referenztakt wird mit einem lokalen 10 MHz VCTCXO erzeugt. Dieser kann in der einfachsten Form per Mehrgang-Poti abgeglichen werden. Eine bessere Genauigkeit erzielt man, wenn am 1-pps-Eingang das entsprechende Signal eines GPS-Empfängers erkannt wird. Damit wird ein fortlaufender Korrekturwert gebildet und jedes Messergebnis passend umgerechnet. Die beste Genauigkeit bietet ein hochstabiles, externes 10 MHz Referenzsignal an EX.REF eingespeist, deren Vorhandensein an EXREF_ON erkannt wird. Der µC verwendet diese Referenz mit höchster Priorität. Die Korrekturwerte für interne und externe Referenzfrequenz lassen sich per RS232 oder manueller Einstellung mit Bedientastern anzeigen/eingeben/ändern. Bei der Eingangsschaltung gehe ich einen anderen Weg als sonst. Hier ist kein Komparator vorgesehen, der von DC bis zur max. Eingangsfrequenz arbeitet. Für saubere Sinus- oder Rechtecksignale braucht man ihn nicht unbedingt; bei Bedarf kann man ihn ext. ergänzen. IC8 arbeitet als Vorverstärker für kleine Signale und IC9 liefert an seinem Ausgang ein steilflankiges Rechtecksignal. D-FF IC10 liefert auf Anforderung das Capture Signal für Ereignisse und Zeitmessung. Experimentell soll IC11 als 2:1 Vorteiler für den Ereigniszähler dienen und durch sein 50% Ausgangssignal die Eingangsfrequenz auf die max. Timerfrequenz bringen. Über D-FF IC12 wird der Zustand des Vorteilers zum Auslesen eingefroren und liefert das LSB des Ereigniszählers. Ich hoffe, daß das so klappt, sofern das interne Timing des G431 dies zuläßt. Wenn es nicht klappt, können IC11 und IC12 entfallen; J3 überbrückt dann den Vorteiler. Wann und in welcher Ausführung das Progamm fertig sein wird, hängt von der fertigen Hardware ab.
Mi N. schrieb: > Das LCD D0-D3 gehört nicht an Masse, schon gar nicht wenn RW umgeschaltet werden kann..
Mi N. schrieb: > Wenn man höchste > Leistung braucht, sollte man einen >= H730 einsetzen, Ach du mal wieder.. Eigentlich bevorzugt man ja möglichst niedrige Leistung, wenn's an das Verbraten selbiger geht. Und das alles für 170 MHz? tss tss... W.S.
verwendest du die interne PLL des STM32 als zur Erzeugung der Zeitbasis deines Counters? Wenn ja, diese hat eine eine Sägezahnförmige drift mit einer Periodendauer von 5-30 sek (abhänig von den PLL Params n und m) und einem Hub von etwa 10 Hz. Beste grüße Bene
Angehängte Dateien:
-
Stm32F7_PLL.PNG
54 KB
Benedikt S. schrieb: > verwendest du die interne PLL des STM32 als zur Erzeugung der Zeitbasis > deines Counters? > Wenn ja, diese hat eine eine Sägezahnförmige drift mit einer > Periodendauer von 5-30 sek (abhänig von den PLL Params n und m) und > einem Hub von etwa 10 Hz. Hallo Benedikt, sind das Erfahrungswerte von dir und andere Ursachen ausgeschlossen ? Im Datenblatt wird davon nichts erwähnt ;-)
Ja das sind Erfahrungswerte von mir. Ich habe eine Atom stabilisierte 1 PPS Referenz mit input capture eingelesen und so den uC clock überwacht. https://www.google.com/amp/s/blog.dan.drown.org/gps-module-measurements/amp/ Hier wird das Verhalten gut beschreiben, das Verhalten zeigen sowohl F1, F2, F4, F7, L0 und H7 stm32 F3 habe ich nicht getestet. Mann kann aber an PH0 und PH1 schnell clocks anlegen und diese direkt als CPU clock nehmen. Dies ist nur bis 50 MHz spezifiziert ich habe aber schon 72 MHz an nem L0 getestet. Beste Grüße Bene
Benedikt S. schrieb: > Ja das sind Erfahrungswerte von mir. Ich habe eine Atom stabilisierte 1 > PPS Referenz mit input capture eingelesen und so den uC clock überwacht. > > https://www.google.com/amp/s/blog.dan.drown.org/gps-module-measurements/amp/ > > Hier wird das Verhalten gut beschreiben, das Verhalten zeigen sowohl F1, > F2, F4, F7, L0 und H7 stm32 F3 habe ich nicht getestet. > > Mann kann aber an PH0 und PH1 schnell clocks anlegen und diese direkt > als CPU clock nehmen. Dies ist nur bis 50 MHz spezifiziert ich habe aber > schon 72 MHz an nem L0 getestet. Ist deine 1ppm Referenz der direkte 1ppm Ausgang vom einem GPS Empfänger oder stammt er von einem GPSDO ?
Meine PPS Referenz ist eine durch 1e7 geteilte Cäsiumstabilisierte 10 MHz clock. Die als quasi drift frei angenommen werden kann. Jitter liegt im Bereich deutlich unter 5ns. Verwendet man ein GPS PPS kann man zusätzlich zum sagezahn noch jitter vom gps Modul sehen.
Benedikt S. schrieb: > Meine PPS Referenz ist eine durch 1e7 geteilte Cäsiumstabilisierte 10 > MHz clock. > > Die als quasi drift frei angenommen werden kann. Jitter liegt im Bereich > deutlich unter 5ns. > > Verwendet man ein GPS PPS kann man zusätzlich zum sagezahn noch jitter > vom gps Modul sehen. Alles klar :-) Da kann ich nicht mit halten ich habe nur 20Mhz Rubidiums und 10Mhz OCXOs ;-)
Da ich hier gerade die Schaltung mit H750 zu liegen habe (siehe Foto weiter oben), habe ich die 10 MHz TCXO-Frequenz gemessen. Der Referenztakt mit 480 MHz kommt von der internen PLL. Damit man den Sägezahn gut erkennen kann, habe ich die Anzeige auf 15 Stellen erweitert, obwohl auf Grund des Messverfahrens nur 11-12 Stellen relevant sind. Die log-Datei über 4:30 m im Sekundentakt findet sich im Anhang. Zunächst wollte ich zur Verdeutlichung des Sägezahns aus den Einzelwerten noch eine Grafik generieren. Aber ich denke, wenn man eine gerade Linie auf Papier haben möchte, reicht auch ein gutes Lineal. Falls jemand den Sägezahn findet - er kann ihn behalten!
:
Bearbeitet durch User
Mi N. schrieb: > Falls jemand den Sägezahn findet - er kann ihn behalten! In deinen Daten kann man den Sägezahn mit einem 10 MHz Test Signal nicht finden dafür bräuchte man schon sehr stabile 100 MHz. Du schreibst in deinem sehr gut dokumentierten (danke dafür) Sourcecode folgendes: >Die Frequenz wird aus den Eingangsimpulsen/Zeit errechnet. Dazu werden die >Timer9 und Timer10 verwendet. Als Zeitbasis für alle Messungen dient die >interne Frequenz SystemCoreClock mit (hier) 216 MHz. >Timer9 zählt am Eingang TIM9_CH1 (PE5) forlaufend die Eingangsimpulse. >Timer10 zählt fortlaufend die interen Impulse von SystemCoreClock (216 MHz). >Beide Zähler werden einmalig gestartet und dann weder gestoppt noch >gelöscht. >Timer6 erzeugt das Timing für die Messdauer im 1 ms Raster. Dieses verfahren hat einen Vorteil--> du kannst tatsächlich mit 50 oder 100 KHz Abtastrate Frequenzen mit vernünftiger Auflösung messen. Nachteilig daran ist eine Unsicherheit von +-0.99 Cycles des Einagnssignals bezogen auf die Messdauer. Da du den tatsächlichen Zeitpunkt der ersten letzten Flanke nicht kennst (es sei denn ich habe etwas übersehen). Abhilfe könnte schaffen das eingangs Signal auch noch in tim10 zu leiten und dort per DMA den Zeitpunkt der ersten und später der letzten Flanke zu lesen und diese Zeit dann für die Berechnung der Frequenz heran zu ziehen. Wenn Interesse besteht kann ich mal die Counter Rohdaten von der PPS Referenz hochladen Beste Grüße Bene
Benedikt S. schrieb: > Nachteilig daran ist eine Unsicherheit von +-0.99 Cycles des > Einagnssignals bezogen auf die Messdauer. Da du den tatsächlichen > Zeitpunkt der ersten letzten Flanke nicht kennst (es sei denn ich habe > etwas übersehen) Du hast das Entscheidene übersehen: die Messungen sind lückenlos! Dabei ist die 1. Flanke der neuen Messung die letzte Flanke der vorherigen Messung. Meine erste Schaltung mit eigener Leiterplatte war diese: http://www.mino-elektronik.de/FM_407/fmeter_407.htm#a1 Egal, was ich damals oder im Nachhinein gebaut und programmiert hatte, ein Problem mit Drift oder Jitter der internen PLL gab es nie. Andernfalls hätte ich die Lösung gleich wieder verworfen. Benedikt S. schrieb: > In deinen Daten kann man den Sägezahn mit einem 10 MHz Test Signal nicht > finden dafür bräuchte man schon sehr stabile 100 MHz. Nein. Die 10 MHz sind Eingangsfrequenz und Basistakt der PLL und damit exakt gleich: stabiler geht es nicht. Würde nun die PLL wackeln, dann müßten die von Dir genannten 10 Hz Abweichung bezogen auf 480 MHz ab spätestens der 8. Stelle sichtbar sein. Da ist aber nichts. Daß ab der 13. Stelle eine Abweichung zum Idealwert sichtbar wird, liegt nach meiner Vermutung an der Rechengenauigkeit über 1E6 Einzelintervalle. Um dies zu verifizieren hätte ich zwar noch die Möglichkeit, mit 128 Bit Integer zu rechnen, aber irgendwo muß man auch einen Punkt machen.
Ich habe hier gerade ein F411CE China Blackpill Board mit einem 25Mhz Wald und Wiesen Quarz, mit der PLL auf 100Mhz gebracht und gebe die Frequenz über den MCO Pin heraus. Dahinter mein Frequenzzähler und der zeigt stabil 100002313,xxxx Hz mit 0,2 Hz Peak-Peak Abweichung nach ein paar Minuten an. Deine Größenordnung von 10 Hz kann ich so auch nicht nach vollziehen.
Und auch beim G431 liefert die PLL ein sehr stabiles Signal. Mit 10 MHz VCTCXO als Referenztakt, 170 MHz PLL und externem 16 MHz XO @ 100000 Einzelmessungen/s driften die Messwerte ab der 9. - 10. Nachkommastelle, je nach Richtung, in die sich die Aerosole bewegen. Das sieht sehr gut aus.
Ich habe mir nochmal den Blog von Dan Drown durchgelesen und da kommt kein Cäsium Normal vor sondern da ist nur von GPS Empfängern die Rede. Deshalb war ja mein erster Verdacht, das die Ursache die Sägezahn artigen Phasenschwankungen des 1pps Signales sind. Ich bin auf die Daten, den Messaufbau und den source code für die STM32F gespannt. Auch ein STM103 (Fake?) läuft bei mir stabil.
:
Bearbeitet durch User
Hans-Georg L. schrieb: > Auch ein STM103 (Fake?) läuft bei mir stabil. Nein ein stm32f767zi nucleo Board direkt von Mouser Daten kommen nachher.
Benedikt S. schrieb: > Hans-Georg L. schrieb: >> Auch ein STM103 (Fake?) läuft bei mir stabil. > > Nein ein stm32f767zi nucleo Board direkt von Mouser Daten kommen > nachher. Gut Danke :-) Das Fake bezog sich nicht auf dein Board, sondern mein Bluepill F103 Board. Ein Nucleo F746Zg und ein H743Zi (auch von Mouser) hätte ich auch noch zum probieren.
Angehängte Dateien:
-
DBGMCU.PNG
13 KB -
STM32F_Device_revision.PNG
79 KB
Ich kann das von Benedikt beschriebene Verhalten auf meinem Nucleo-F746Zg nach vollziehen. Wenn ich Sysclock mit PLL auf 200Mhz setzte, durch 2 dividiere und über MCO2 ausgebe, habe ich ca 20Hz Abweichung mit einem Sägezahn artigen Verlauf. Mein Nucleo Bord is markiert als : MB1137 Rev. B-01 Der Chip hat die ID= 446 und die Revision 1001 = Z oder 1
:
Bearbeitet durch User
Sorry für die Mehrfach Bilder, aber es wurde nichts als Anhang angezeigt und deshalb habe ich es mehrfach probiert. In der Debugger Anzeige ist noch ein Fehler Rev_ID müsste 16:31 sein.
:
Bearbeitet durch User
Hans-Georg L. schrieb: > Wenn ich Sysclock mit PLL auf 200Mhz > setzte, durch 2 dividiere und über MCO2 ausgebe, habe ich ca 20Hz > Abweichung mit einem Sägezahn artigen Verlauf. 20 Hz bezogen auf 100 MHz sind 0,2 ppm. Das bedeutet, daß diese Abweichungen in den Messwerten ab der 7. Stelle sichtbar sein müßten. Wie gesagt, konnte ich das bei keinem der verwendeten F4, F7, H7 und G4 Controller sehen. Die Datenblattwerte für Jitter sind ja mit unter 100 ps RMS richtig gut. Was ich nie gemacht habe, den MCO-Ausgang zu aktivieren und zu nutzen. Könnte der Effekt erst durch Verwendung von MCO entstehen?
Mi N. schrieb: > Die Datenblattwerte für Jitter sind ja mit unter 100 ps RMS richtig gut. > Was ich nie gemacht habe, den MCO-Ausgang zu aktivieren und zu nutzen. > Könnte der Effekt erst durch Verwendung von MCO entstehen? Ich habe den sägezahn gemessen in dem ich mit input capture den timerstand von tim2 bei jeder steigenden Flanke der PPS Signal erfasst habe. Dann ist die Differenz zwischen zwei counter standen direkt der Systemclock. Wenn du den mit einem sehr schnellen scope auf das 10 MHz Signal triggerst und auf dem zweiten Kanal das Mo signal betrachtest. Kannst du sehen, dass die Phasenlage des MCO sich kontinuierlich ändert. Diese Phase Änderung integriert ist die Frequenzänderung. Der Jitter zwischen zwei pulsen ist immer unter 100 ps.
Mi N. schrieb: > Hans-Georg L. schrieb: >> Wenn ich Sysclock mit PLL auf 200Mhz >> setzte, durch 2 dividiere und über MCO2 ausgebe, habe ich ca 20Hz >> Abweichung mit einem Sägezahn artigen Verlauf. > > 20 Hz bezogen auf 100 MHz sind 0,2 ppm. Das bedeutet, daß diese > Abweichungen in den Messwerten ab der 7. Stelle sichtbar sein müßten. > Wie gesagt, konnte ich das bei keinem der verwendeten F4, F7, H7 und G4 > Controller sehen. > > Die Datenblattwerte für Jitter sind ja mit unter 100 ps RMS richtig gut. > Was ich nie gemacht habe, den MCO-Ausgang zu aktivieren und zu nutzen. > Könnte der Effekt erst durch Verwendung von MCO entstehen? Der MCO ist ja nur ein Multiplexer, mit dem man einen Clock auswählt und auf einem Port ausgibt und bei dem F411 gab es ja auch keine Probleme. Allerdings ist da ein Bug in der CUBEIDE der Ausgangs Pin wird zweimal initialisiert, beim 1. mal richtig und beim 2. mal dann auf Low-Speed das ist natürlich Unsinn und es kommt nichts heraus. Den MCO habe ich nicht im Verdacht aber das es die PLL direkt ist bin ich mir mir auch sicher. Der F7 hat mehrere PLL ich schau mal ob man die anderen auch ausgeben kann und den H7 kann ich auch noch testen muss da aber erst noch Stiftleisten einlöten. @ Benedikt und Michael benutzt ihr auch die CubeIde und das Grundgerüst zu erstellen ?
Benedikt S. schrieb: > Mi N. schrieb: >> Die Datenblattwerte für Jitter sind ja mit unter 100 ps RMS richtig gut. >> Was ich nie gemacht habe, den MCO-Ausgang zu aktivieren und zu nutzen. >> Könnte der Effekt erst durch Verwendung von MCO entstehen? > > Ich habe den sägezahn gemessen in dem ich mit input capture den > timerstand von tim2 bei jeder steigenden Flanke der PPS Signal erfasst > habe. Dann ist die Differenz zwischen zwei counter standen direkt der > Systemclock. > > Wenn du den mit einem sehr schnellen scope auf das 10 MHz Signal > triggerst und auf dem zweiten Kanal das Mo signal betrachtest. Kannst du > sehen, dass die Phasenlage des MCO sich kontinuierlich ändert. Diese > Phase Änderung integriert ist die Frequenzänderung. > > Der Jitter zwischen zwei pulsen ist immer unter 100 ps. Ich möchte jetzt erst mal bei dem STM und seinem Clock Eingang und dem PLL Ausgang bleiben und nicht noch eine weiteres Signal einführen. Ist bei dir der HSE clock und das 1pps Signal aus der gleichen Cäsium Kiste, abgeleitet ? Ein sehr schnelles Oszi ist relativ ... Ich habe ein Rigol DS1054 und ein Tek 2467B falls ich dem ersteren nicht so traue ;-)
Tja, was soll ich sagen? Gut für mich - schlecht für Euch? Liegt es vielleicht an den Faktoren der PLL? Hans-Georg L. schrieb: > @ Benedikt und Michael benutzt ihr auch die CubeIde und das Grundgerüst > zu erstellen ? Teil- und testweise. Im Betrieb mess ich den HSE-Takt und stelle dann die PLL entsprechend ein. Vorläufiger Code ist im Anhang.
Was mir gerade eingefallen ist, der F7 kann "spread spectrum clock generation" das müsste dann aber kein Sägezahn sondern ein dreieckige Manipulation sein. Wenn ich mit dem Debugger das entsprechende Register anschaue sollte es aber deaktiviert sein... Im Errata steht davon nichts.
Hans-Georg L. schrieb: > Was mir gerade eingefallen ist, der F7 kann "spread spectrum clock > generation" das müsste dann aber kein Sägezahn sondern ein dreieckige > Manipulation sein. Das war bei meinen Experimenten definitiv deaktiviert. Wo hast du die Information mit dem Dreieck bei spread spectrum gefunden?
Benedikt S. schrieb: > Hans-Georg L. schrieb: >> Was mir gerade eingefallen ist, der F7 kann "spread spectrum clock >> generation" das müsste dann aber kein Sägezahn sondern ein dreieckige >> Manipulation sein. > > Das war bei meinen Experimenten definitiv deaktiviert. > Wo hast du die Information mit dem Dreieck bei spread spectrum gefunden? Du willst ja das Spektrum wegen EMI nach beiden Seiten spreizen um die Peaks abzuschwächen und da ist ein Dreieck sinnvoll. Ich habe das vor meiner Rente mal bei einem Atmel ARM7 gemacht damit er den EMI Test besteht und das ist mir gerade eingefallen. Im Datenblatt nach "spread" suchen, da ist es genau erklärt. Die Register dazu findest du im RM. Das ist default auch deaktiviert. Wenn das Teil einen BUG hat und los läuft könnte es so einen Effekt erzeugen.
:
Bearbeitet durch User
Mi N. schrieb: > Teil- und testweise. Im Betrieb mess ich den HSE-Takt und stelle dann > die PLL entsprechend ein. Vorläufiger Code ist im Anhang. So als Info ;-) Der VCO Eingang sollte nach Möglichkeit 2MHz haben für minimalen Jitter ... so steht es in einem Kommentar im HAL RCC Code. Im Datenblatt habe ich das noch nicht gelesen.
Ich habe einfach mal das Register RCC_SSCGR nach abschalten der PLL nochmal explizit auf 0 gesetzt bevor sie wieder gestartet wird. Hat aber leider auch nichts gebracht. Hier noch eine App note dazu wie es funktioniert. https://www.st.com/resource/en/application_note/dm00281138-stm32-mcus-spreadspectrum-clock-generation-principles-properties-and-implementation-stmicroelectronics.pdf
Hans-Georg L. schrieb: > Im Datenblatt habe ich das noch nicht gelesen. Ich auch nicht den Kommentar hatte ich auch gelesen. Könnte in cubemx auch ruhig angezeigt werden. Default ist es auch so eingestellt. Hans-Georg L. schrieb: > Du willst ja das Spektrum wegen EMI nach beiden Seiten spreizen um die > Peaks abzuschwächen und da ist ein Dreieck sinnvoll. Das ist natürlich logisch, ich hatte gedacht das währe ggf. Raffinierter, wenn ich die Zeit finde versuche ich das mal zu messen. @Hans-Georg L. Hast du einen funktionsgenerator zur Hand mit dem du den uC System lock erzeugen kannst? Ich habe das bis 72 MHz mit einem L0 aus probiert. Sprich obwohl unzulässig ist den uC auf 72 MHz HSE konfiguriert und dann mit 72 MHz 3.2 Vpp+1.6V DC in den clock input im bypass mode. Hohefrequenzen habe ich noch nicht getestet. So gespeist verschwindet die Sägezahnmodulation komplett was für mich den Pll VCO als Ursache logisch werden lässt. Falls der uC mit dem zu schnellen HSE nicht hoch kommt, hilft es dem clock langsam zu streigern ( ich habe einfach am fgen die frequenz hoch gedreht ca 5 MHz/s). Beste Grüße Benedikt
Benedikt S. schrieb: > Hans-Georg L. schrieb: >> Im Datenblatt habe ich das noch nicht gelesen. > > Ich auch nicht den Kommentar hatte ich auch gelesen. Könnte in cubemx > auch ruhig angezeigt werden. Default ist es auch so eingestellt. > > Hans-Georg L. schrieb: >> Du willst ja das Spektrum wegen EMI nach beiden Seiten spreizen um die >> Peaks abzuschwächen und da ist ein Dreieck sinnvoll. > > Das ist natürlich logisch, ich hatte gedacht das währe ggf. > Raffinierter, wenn ich die Zeit finde versuche ich das mal zu messen. > > @Hans-Georg L. Hast du einen funktionsgenerator zur Hand mit dem du den > uC System lock erzeugen kannst? > Ich habe das bis 72 MHz mit einem L0 aus probiert. > Bin ich gerade am bauen ;-) > Sprich obwohl unzulässig ist den uC auf 72 MHz HSE konfiguriert und dann > mit 72 MHz 3.2 Vpp+1.6V DC in den clock input im bypass mode. > Hohefrequenzen habe ich noch nicht getestet. > > So gespeist verschwindet die Sägezahnmodulation komplett was für mich > den Pll VCO als Ursache logisch werden lässt. Diese Spread Geschichte wird auch vom VCO Eingang gesteuert könnte auch mit zunehmender Frequenz friedlicher werden ... > > Falls der uC mit dem zu schnellen HSE nicht hoch kommt, hilft es dem > clock langsam zu streigern ( ich habe einfach am fgen die frequenz hoch > gedreht ca 5 MHz/s). > Das Board will ich so lassen, aber ich habe noch ein 2.tes F746 Nucleo ohne ST-Link, da muss ich so oder so einen externen Clock einspeisen. Das baue ich gerade auf und dann probiere ich es aus. Ich habe in den letzten Jahren wenn ich was dringend brauchte das "gesparte" Mouser Porto in Nucleos investiert ;-)
Angehängte Dateien:
-
PLM_TST_EXT_10Mhz.PNG
14 KB
Ein identisches Board ohne ST-Link und mit externem 10Mhz HSE Takt ergibt das Bild im Anhang ohne Sägezahn.
Hans-Georg L. schrieb: > mit externem 10Mhz HSE Takt Da hast Du wohl den Wohltäter gefunden. Der Übeltäter ist das MCO-Signal, was bei den Nucleo-Boards vom ST-Link kommt. Hierzu wird (typischerweise) ein STM32F103 eingesetzt, der vielleicht auf Grund seines Alters noch eine recht bescheidene Stabilität hat. Nur eine Vermutung, die aber erklärt, warum ich nie Probleme hatte. Selber habe ich immer Quarz oder TCXO eingesetzt. Kleine Bemerkung zum Nucleo-G431 Board. Hier wird ebenfalls HSE vom MCO des ST-Link erzeugt. Entgegen der Beschreibung sind es nicht die 25 MHz vom Quarz des F723, sondern die 2:1 geteilte HSI mit 8 MHz. Das ist richtig übel!
Das war auch mein erster Gedanke, deshalb habe ich den Frequenzzähler an den ST-Link MCO vom ersten Board gehängt aber da gibt es auch keinen Sägezahn. Benedikt hat bestimmt auch noch etwas dazu zu sagen ;-)
Bescherung ist erst in ein paar Tagen, aber ein Türchen vom Kalender kann man ja jeden Tag öffnen ;-) Die angehängte Beschreibung ist noch als "Entwurf" zu sehen, der in ein paar Tagen mit dem endgültigen Programm abgeglichen werden muß. Die Schaltung ist die kleine Schwester einer anderen, steckerkompatiblen Schaltung (http://www.mino-elektronik.de/download/FMeter-407-TDC-V1.1.pdf). Die Funktionen sind reduziert, aber für den "Hausgebrauch" auch völlig ausreichend. Hans-Georg L. schrieb: > Das war auch mein erster Gedanke, deshalb habe ich den Frequenzzähler an > den ST-Link MCO vom ersten Board gehängt aber da gibt es auch keinen > Sägezahn. Benedikt hat bestimmt auch noch etwas dazu zu sagen ;-) Mich interessieren ja nach wie vor die PLL-Einstellungen. Anders kann man die Bilder ja nicht bewerten.
Was einige Countermodule noch bieten ist ein Frequenz-Offset (ggf. über DIs um-/zuschaltbar). Um zB. ZF-Frequenzen berücksichtigen zu können.
Gut das es die Möglichkeit gibt, den GHz Vorteiler ab zu trennen. Das schafft die Möglichkeit einen anderen Vorteiler zu verwenden. Ich dachte an einen Teiler der auch für 5 oder 10GHz geeignet ist. Der hier verwendete Teiler schafft gerade mal so 1,6 GHz.
So, heute noch ein Türchen: http://www.mino-elektronik.de/fmeter/fm_software.htm#bsp_G431 Programm und Beschreibung werden noch ein wenig angepaßt werden, sollten aber hinreichend klar beschrieben sein. Viel Spaß!
Am Chiemsee schrieb: > Gut das es die Möglichkeit gibt, den GHz Vorteiler ab zu trennen. > Das schafft die Möglichkeit einen anderen Vorteiler zu verwenden. > Ich dachte an einen Teiler der auch für 5 oder 10GHz geeignet ist. > > Der hier verwendete Teiler schafft gerade mal so 1,6 GHz. Bei wechselbaren Vorteilern könnte man darüber nachdenken ob die über ihre Fähigkeiten berichten könnten ... kleines i2c Eprom oder so ...
Angehängte Dateien:
-
Fmeter-G431-Musteraufbau.jpg
140 KB
Hans-Georg L. schrieb: > Bei wechselbaren Vorteilern könnte man darüber nachdenken ob die über > ihre Fähigkeiten berichten könnten ... kleines i2c Eprom oder so ... Ich denke, die Sache mit dem Vorteiler wird überbewertet. Weder Auflösung noch Genauigkeit werden dadurch vermindert, sodaß ein individuelles Nachrüsten möglich ist. Wer ihn tatsächlich braucht, baut ihn sich dazu, stellt den Teilerfaktor entsprechend ein und die Sache ist abgehakt. Wer ihn nicht braucht hat einen einzigen, hochohmigen Eingang. Der obige Link verweist auf den Quellcode. Wer einen Frequenz-Offset benötigt kann ihn sich dazustricken. Die aktuelle Programmversion belegt nur rund 26 kB FLASH-Speicher. Als kleiner Appetitanreger ein Foto vom Musteraufbau. Für die Hardware kann man als Basis auch ein Nucleo-G431-Board verwenden. (Damit hatte ich die Wartezeit auf die Platinenlieferung überbrückt.) Lötfreudige Bauteile aus der 74LVX- oder 74VHC-Serie im SOIC-14 Gehäuse sind nicht ganz so schnell wie die 74AUP1Gxx dafür aber einfacher zu verwenden und reichen für die meisten Anwendungen aus. Den STM32G431KBT6 mit 128 kB FLASH gibt es sogar bei Reichelt zu einem moderaten Preis.
:
Bearbeitet durch User
Hans-Georg L. schrieb: > Ein identisches Board ohne ST-Link und mit externem 10Mhz HSE Takt > ergibt das Bild im Anhang ohne Sägezahn. Hat sich wegen des "rauschenden Sägezahns" noch irgendetwas ergeben? Wenn der Effekt einmal da ist und einmal nicht, wäre es nicht verkehrt, die Ursache dafür künftig auszuschließen.
Mi N. schrieb: > Wenn der Effekt einmal da ist und einmal nicht, wäre es nicht verkehrt, > die Ursache dafür künftig auszuschließen. Ich bin leider familiär für eingespannt gerade und kann daher nicht versprechen, wann ich es schaffe, aber ich werde das auch noch mal unabhängig validieren. Ich halte es für möglich, dass der sägezahn durch einen Effekt der beiden PLLs entsteht. Ich werde dies noch mal mit einer externen taktquelle validieren. Beste Grüße Bene
Angehängte Dateien:
-
MCO-HSE.png
9,6 KB
Hans-Georg L. schrieb: > Ich kann das von Benedikt beschriebene Verhalten auf meinem > Nucleo-F746Zg nach vollziehen. Wenn ich Sysclock mit PLL auf 200Mhz > setzte, durch 2 dividiere und über MCO2 ausgebe, habe ich ca 20Hz > Abweichung mit einem Sägezahn artigen Verlauf. > > Mein Nucleo Bord is markiert als : MB1137 Rev. B-01 > Der Chip hat die ID= 446 und die Revision 1001 = Z oder 1 Wie es das Leben so will, habe ich das gleiche Nucleo-Board. Zunächst sehe ich unabhängig von Faktor N, daß der PLL-Takt an MCO2 langsam ansteigt und schlagartig wieder abfällt. Ich sehe, daß die ausgegebene HSE-Frequenz dasselbe Verhalten aufweist. Und ganz zum Schluß zeigt sich, daß der MCO-Takt vom STM32F103, der HSE liefert genauso wackelt. Etwa 1,5 Hz. Die Kurve wurde mit 5 Messungen/s aufgezeichnet. Mi N. schrieb: > Der Übeltäter ist das > MCO-Signal, was bei den Nucleo-Boards vom ST-Link kommt. Das hat sich damit bestätigt!
Ist schon kraß, welche Unterschiede es beim 74AUP1G74 gibt. TI: typisch 190MHz NXP: typisch 619MHz
Peter D. schrieb: > Ist schon kraß, welche Unterschiede es beim 74AUP1G74 gibt. Bislang hatte ich wegen der höheren Taktfrequenz immer NXP verwendet. Bei meinem Musteraufbau nun auch TI, was sich nicht negativ auswirkt. Bei nächster Gelegenheit werde ich noch mit NXP-Typen vergleichen, ob sich diese bei >= 200 MHz ähnlich verhalten. Das Datenblatt von TI ist nicht ganz schlüssig. Zur Kompensation von der "schlechten" Fmax gibt es einen SN74AUC1G74, der Laut Datenblatt mit Fclock max. 275 MHz @ 2,5 V getaktet werden darf. Ein paar Zeilen weiter findet man die Angabe zu Fmax mit min. 275 MHz @ 2,5 V. Was soll man davon nur halten?
So, heute nun die letzte Tür und damit die Bescherung ;-) Einige (Tipp)fehler im Programm konnte ich noch entfernen, ein paar Funktionen noch ändern und schließe die Sache damit erst einmal ab. Wer an einem Nachbau interessiert ist, lade sich bitte die letzte Version von Programm und Beschreibung herunter. Zum µC gibt der Hersteller die max. ext. Eingangsfrequenz zu den Timern mit TimerClock/2 an. Zusammen mit dem 1G74-Vorteiler müßte sie demnach 170 MHz betragen - 50% Taktverhältnis vorausgesetzt. Zunächst wurden nur 160 MHz erreicht und bei der abschließenden Prüfung noch 150 MHz. Um die Grenzen zu testen hatte ich mit erhöhten Taktfrequenzen gespielt. Mit internem HSI Takt lief der 170 MHz Controller noch mit 290 MHz. Mit HSE geht es noch bis 260 MHz. Um die max. Messfrequenz experimentell auf 200 MHz zu erhöhen, gibt es jetzt noch eine Option dazu. Ein 3k3 Widerstand zwischen den LCD-Leitungen RS und R/W (Pin 4 und 5) aktiviert einen "Turbo"-Modus, beim dem die Taktfrequenz vom µC auf 240 MHz gesetzt wird. Die zusätzliche Stromaufnahme ist mit 10 mA minimal. Wer es unbedingt braucht, kann es probieren, wer nicht, belässt es bei der Grundeinstellung! Wie oben schon angedeutet ist eine weitere Schaltung mit STM32H730 in Arbeit, der dann erwartungsgemäß 230 MHz ohne Trickserei messen und noch eine Stelle/s mehr liefern kann.
Mittlerweile habe ich Schaltungen mit den 74AUP1G74 von TI und NXP aufgebaut und getestet. Da zeigt sich, daß ab 200 MHz die NXP Teile die bessere Wahl sind. Beim FMeter-G431 erhöht sich die max. Eingangsfrequenz mit NXP D-FFs von 150 auf 160 MHz und bei Übertaktung von 200 auf 220 MHz. Wenn man dies braucht, sollte man bei der Bestellung auf NXP achten. Allerdings gibt es bei machen Anbietern nur TI Teile. Dann habe ich jetzt auch eine Version für den STM32H730 "testfertig", die ich gleich mit NXP bestückt habe. Die max. Eingangsfrequenz liegt bei > 250 MHz (von theoretisch 275 MHz) bei einem bescheidenen Testsignal. (MCO-Signal von einem übertakteten F746 über 25 cm Flachbandleitung.) Für die G431 Platine ist jetzt auch eine .zip-Datei verfügbar, mit der man sich Leiterplatten selbst bestellen kann. Die Gerber-Dateien können auf jeden Fall von Elecrow und JLCPCB direkt verwendet werden. Alles ist - wie gehabt - hier zusammengefasst: http://www.mino-elektronik.de/fmeter/fm_software.htm#bsp_G431
Angehängte Dateien:
-
mino_FMeter-G431-ADEV1.gif
68 KB -
mino_FMeter-G431-ADEV2.gif
60 KB
Das Programm für den G431 hat sich weiterentwickelt. Die ursprüngliche, feste Referenzfrequenz (Fref) von 170 MHz hat sich als nachteilig erwiesen, sobald Fref/Fin in einem ganzzahligen Verhältnis zueinander stehen. Gerade für vielfach gemessene Eingangsfrequenzen von 10 MHz mit kleinsten Differenzen zu Fref kann es im Ergebnis periodische Ausreißer geben. Daher wurde Fref auf 525/3 = 173,3… MHz leicht angehoben. Um nicht erneut ein ganzzahliges Verhältnis zu Fin zu erhalten, wird zusätzlich das Frequenzverhältnis bewertet und Fref ggf. auf einen Wert von < 170 MHz umgeschaltet. Dazu gibt es einen neuen Modus "F1 Auflösung: optimiert", der die Umschaltung bei Bedarf schnell (1-2 ms) und unbemerkt im Hintergrund ausführt. Anwender, die keine besonders stabilen Eingangssignale messen, werden keine Veränderungen feststellen. Wer jedoch eines der Programme für F407, F730 oder H750 mit Regressionsberechnung verwendet, sollte darauf achten, die PLL so einzustellen, daß kein phasenstarres Frequenzverhältnis auftreten kann. Soviel zu einem ganz speziellen Problem. Ein Kollege hier (Benutzer 'bnzf') hat einige Anregungen gegeben, viele Messungen durchgeführt und auch einige Grafiken erstellt, die als "bunte Bilder" zeigen, welche Messergebnisse vom FMeter-G431 zu erwarten sind. Das 1. Bild zeigt Kurven mit unterschiedlichen Fin, wobei die Referenzfrequenz aus dem verwendeten HF-Generator stammt. Die Kurven für 10 MHz zeigen erwartungsgemäß die besten Ergebnisse. Alle anderen Frequenzen werden mit < 1E-10 gemessen. Die Kurven des 2. Bildes zeigen Messwerte mit fester Fref 525/3 MHz (Modus "F1 Auflösung: hoch"). Selbst bei 0,1 s Messintervall sind die Werte besser 1E-9. Interessant ist auch die Kurve ganz unten mit 10 s Messintervall. Die Regressionberechnung kann durch viele Einzelintervalle das Ergebnis gegenüber dem Mittelwert aus vielen Einzelmessungen deutlich verbessern. Mittendrin ist auch noch eine Vergleichsmessung mit einem FA2, der sich ganz passabel schlägt ;-)
Eine ein bischen OT-Frage: mit welcher Software wurden denn die Allan-Plots erstellt? Das sieht ja wesentlich besser aus als Stable32
Sinus T. schrieb: > mit welcher Software wurden denn die > Allan-Plots erstellt? TimeLab: http://www.miles.io/TimeLab/beta.htm
@Bernd: Vielen Dank! Die Seite kannte ich zwar, habe aber irgendwie nicht gecheckt, dass die Software universell verwendbar ist, dachte, die wäre nur Instrument-spezifisch.
Angehängte Dateien:
-
FMeter-H730_Rauschen.png
76 KB
Mi N. schrieb: > Wie oben schon angedeutet ist eine weitere Schaltung mit STM32H730 in > Arbeit, der dann erwartungsgemäß 230 MHz ohne Trickserei messen und noch > eine Stelle/s mehr liefern kann. Es hat nun von Weihnachten bis kurz vor Ostern gedauert. Die ADEV-Kurven zeigen einen Vergleich zwischen verschiedenen Messraten beim H730 und einem Test vom G431. Dabei wurde jeweils die lokale 10 MHz-Referenz gemessen. Durch entsprechende (automatische) Einstellung der internen Pll, stehen beide Frequenzen nicht in einem harmonischen Verhältnis zueinander. Was nicht direkt ersichtlich ist, daß der H730 um eine Größenordnung besser auflöst. Es sind >= 11 Stellen/s. Die Auflösung steigt deutlich, wenn man eine längere Messzeit verwendet (3 s bzw. 10 s).
Vielen Dank das du deine Ergebnisse hier zeigst. Ich konnte auch noch einmal validieren, das der Sägezahn im Systemclock nur bei Nucleo-boards und nicht bei externen Taktquellen auftritt. Mi N. schrieb: > Das 1. Bild zeigt Kurven mit unterschiedlichen Fin, wobei die > Referenzfrequenz aus dem verwendeten HF-Generator stammt. Damit meinst du die HSE Clock Frequenz mit der du den STM32 Betreibst oder? Beste Grüße Bene
Benedikt S. schrieb: > Damit meinst du die HSE Clock Frequenz mit der du den STM32 Betreibst > oder? Ja, abgegriffen am Ausgang des Inverters hinter dem TCXO. Dadurch ist die Drift der abs. Frequenz ausgeklammert.
moin, hat jemand schon mal die Software auf einem STM32F103C8 / Blue Pill laufen lassen? Meine Portierung ( allerding in Pascal ) sollte so richtig sein. Das Messergebnis (1..5kHz) geht von "steht und stimmt" bis "wackelt und daneben" Peter
Pieter schrieb: > Das Messergebnis (1..5kHz) geht von "steht und stimmt" bis "wackelt und > daneben" Das wird an den verwendeten Timern liegen. Zum einen müssen deren Interrupts die gleiche Priorität besitzen und zum anderen sollte der Capture-Interrupt bevorzugt gegenüber dem Überlauf-Interrupt abgearbeitet werden. Je nach STM32 kann es notwendig sein, die Prioritäten anzupassen. Selber bin ich nur mit STM32 >= F4xx vertraut, wobei sich gezeigt hat, daß es günstiger ist, einen weiteren, freien Compare-Kanal mit TIM_SR_CCxIF zu verwenden als das TIM_SR_UIF. Da hat man die Reihenfolge der Verarbeitung voll im Griff. Daß es an Pascal selber liegt, wäre wegen der unterschiedlichen Zählweise (zum Beispiel 1 - 10 anstatt 0 - 9 in C) denkbar, aber eher unwahrscheinlich. Viel Erfolg!
Angehängte Dateien:
-
FM-AS6501-sch.png
78 KB -
FM-AS6501.jpg
240 KB -
FM-AS6501_166_KHz_Abtastrate_loopback.png
39 KB
Aus den zuvor gezeigten Schaltungen/Programmen hat sich mittlerweile eine neue Schaltung ergeben, die mit einem schnellen STM32H730 und einem TDC AS6501 arbeitet: siehe Schaltplan. Es werden zwei Eingangskanäle mit bis zu 12 Digits/s gemessen. Das Rauschen der Messung (Allan Deviation) wurde mit der internen Referenzfrequenz ermittelt. Keine Frage, nur wenige Anwender haben hochstabile Oszillatoren und brauchen diese hohe Auflösung. Wie man sehen kann, ist der Aufwand dennoch nicht sonderlich hoch.
Habe ich das laut Datenblatt richtig erfasst? Der Chip kann maximal 120 MHz als externen timer clock (ohne prescaler, vorteiler, etc.)? (6.3.36 Timer characteristics)
@Ralf ich meine ja. Achtung der ext clock wird über flip-flops mit dem sysclock synchronisiert deshalb darf er auch max halb so schnell sein.
Ich meine jetzt nur den rohen Chip-Meßeingang ohne die ganze Beschaltung aussen herum. Normalerweise können die, die halbe CPU-Taktfrequenz. Könnte aber auch weniger sein (z.B. 4 Takte -> f/4). Man müsste das Datenblatt durchackern, wozu ich jetzt nicht den Intellekt habe. Deshalb meine Frage, ob das schon jemand praktisch verifiziert hat.
Ralf S. schrieb: > Ich meine jetzt nur den rohen Chip-Meßeingang ohne die ganze Beschaltung > aussen herum. Ja ich auch die Synchronisierung findet im stm32 statt damit wenn ein register gelesen wird immer solide Zustände herrschen.
Ralf S. schrieb: > Ich meine jetzt nur den rohen Chip-Meßeingang ohne die ganze Beschaltung > aussen herum. Normalerweise können die, die halbe CPU-Taktfrequenz. Bei den neueren STM32Fxxx können die Timer in der Regel mit dem CPU-Takt laufen und die max. Eingangsfrequenz beträgt wegen der internen Synchronisierung 1/2 dieser Frequenz. Bei den STM32H7xx beträgt der Timertakt maximal 1/2 CPU-Takt und die max. Eingangsfrequenz dann nur noch 1/4 vom CPU-Takt. > Man müsste das > Datenblatt durchackern, wozu ich jetzt nicht den Intellekt habe. Die Angaben findet man im Datenblatt unter "Functional overview/Timers and watchdogs". Nicht irritieren lassen: "Max. Interface Clock" gibt an, wie schnell auf die Timerregister zugegriffen werden kann. > Deshalb meine Frage, ob das schon jemand praktisch verifiziert hat. Ja. Da das Eingangssignal aber nur selten als exakt 50:50 Rechtecksignal anliegt, ist die max. Eingangsfrequenz einige Prozent niedriger. Beim reziproken Zähler kann man getrost einen Vorteiler verwenden, ohne die Auflösung zu verschlechtern. Nachteilig ist ein Vorteiler nur im Hz-Bereich, wo sich die Messzeit verlängert, da immer eine ganze Periode gemessen werden muß. Beispielsweise dauert mit einem 1/4 Vorteiler die Messung von 1 Hz dann 4 s.
Mi N. schrieb: > Bei den neueren STM32Fxxx können die Timer in der Regel mit dem CPU-Takt > laufen und die max. Eingangsfrequenz beträgt wegen der internen > Synchronisierung 1/2 dieser Frequenz. > Bei den STM32H7xx beträgt der Timertakt maximal 1/2 CPU-Takt und die > max. Eingangsfrequenz dann nur noch 1/4 vom CPU-Takt. > Danke, sehr aufschlussreich. Ist nicht die H-Serie die schnellere und damit der Timer schneller? https://www.st.com/en/microcontrollers-microprocessors/stm32-high-performance-mcus.html 3.28 -> The maximum timer clock is up to 480 MHz depending on TIMPRE bit in the RCC_CFGR register and D2PRE1/2 bits in RCC_D2CFGR register.
:
Bearbeitet durch User
Moin, hat jemand von euch schon mal aus probiert den HSE Eingang zu übertakten? Sprich z. B. LVPECL 200 MHz clock dierekt an die HSE pins oder 200 MHz 3.3 V Cmos im bypass clock mode. Die Pll im uC wird überbrückt und dierekt HSE als sysclock genommen. Mann kann 200 MHz als HSE clock einstellen cube MX meckert zwar das ganze kompiliert aber. Ich vermute man braucht Pegel satt um den Eingang sicher zu treiben, aber ich sehe sonst nichts warum das nicht funktionieren sollten. Habt ihr da Erfahrungen?
Gut und schön, aber zuviel aufwand. Ich habe den gebaut und der läuft und läuft. Mit vergleichmessung war keine Abweicheung zu sehen: https://web.archive.org/web/20130402211324/http://sprut.de/electronic/pic/projekte/frequenz/freq_uni_628.htm
Ext clock fast schrieb: > Moin, > hat jemand von euch schon mal aus probiert den HSE Eingang zu > übertakten? > > Sprich z. B. LVPECL 200 MHz clock dierekt an die HSE pins oder 200 MHz > 3.3 V Cmos im bypass clock mode. > > Die Pll im uC wird überbrückt und dierekt HSE als sysclock genommen. > Mann kann 200 MHz als HSE clock einstellen cube MX meckert zwar das > ganze kompiliert aber. > > Ich vermute man braucht Pegel satt um den Eingang sicher zu treiben, > aber ich sehe sonst nichts warum das nicht funktionieren sollten. > > Habt ihr da Erfahrungen? Die PLL wird doch von HSE angetrieben ? und da reichen scheinbar 8MHz für 550MHz cpu clock.
Ralf S. schrieb: > Die PLL wird doch von HSE angetrieben ? Ja. Man kann die pll deaktivieren und dierekt HSE als sysclock verwenden. Ich habe das bei einem L432 mit 80 MHz auch getest und das funktioniert auch.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.