8-stelliger Frequenzzähler, reziprok, STM32F7xx

[Mi N. (msx)]

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.

[Apollo M. (Firma: @home) (majortom)]

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!

[Mi N. (msx)]

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"

[Johannes S. (Gast)]

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.

[Mi N. (msx)]

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.

[Johannes S. (Gast)]

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 :)

[Mi N. (msx)]

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.

[Johannes S. (Gast)]

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.

[Mi N. (msx)]

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.

[Johannes S. (Gast)]

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.

[Mi N. (msx)]

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.

[Mi N. (msx)]

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.

[MaWin (Gast)]

Mi N. schrieb:
> Das LCD

D0-D3 gehört nicht an Masse, schon gar nicht wenn RW umgeschaltet werden 
kann..

[W.S. (Gast)]

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.

[Benedikt S. (Gast)]

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

[Hans-Georg L. (h-g-l)]

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 ;-)

[Benedikt S. (Gast)]

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

[Hans-Georg L. (h-g-l)]

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 ?

[Benedikt S. (Gast)]

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.

[Hans-Georg L. (h-g-l)]

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 ;-)

[Mi N. (msx)]

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!

[Benedikt S. (benedikt_s)]

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

[Mi N. (msx)]

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.

[Hans-Georg L. (h-g-l)]

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.

[Mi N. (msx)]

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.

[Hans-Georg L. (h-g-l)]

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.

[Benedikt S. (Gast)]

Hans-Georg L. schrieb:
> Auch ein STM103 (Fake?) läuft bei mir stabil.

Nein ein stm32f767zi nucleo Board direkt von Mouser Daten kommen 
nachher.

[Hans-Georg L. (h-g-l)]

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.

[Hans-Georg L. (h-g-l)]

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

[Hans-Georg L. (h-g-l)]

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.

[Mi N. (msx)]

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?

[Hans-Georg L. (h-g-l)]

Hier erst einmal ein Bildchen und die Messdaten dazu.

[Benedikt S. (Gast)]

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.

[Hans-Georg L. (h-g-l)]

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 ?

[Hans-Georg L. (h-g-l)]

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 ;-)

[Mi N. (msx)]

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.

[Hans-Georg L. (h-g-l)]

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.

[Benedikt S. (Gast)]

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?

[Hans-Georg L. (h-g-l)]

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.

[Hans-Georg L. (h-g-l)]

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.

[Hans-Georg L. (h-g-l)]

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

[Benedikt S. (Gast)]

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

[Hans-Georg L. (h-g-l)]

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 ;-)

[Hans-Georg L. (h-g-l)]

Ein identisches Board ohne ST-Link und mit externem 10Mhz HSE Takt 
ergibt das Bild im Anhang ohne Sägezahn.

[Mi N. (msx)]

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!

[Hans-Georg L. (h-g-l)]

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 ;-)

[Mi N. (msx)]

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.

[Henrik V. (henrik_v)]

Was einige Countermodule noch bieten ist ein Frequenz-Offset (ggf. über 
DIs um-/zuschaltbar). Um zB. ZF-Frequenzen berücksichtigen zu können.

[Am Chiemsee (Gast)]

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.

[Mi N. (msx)]

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ß!

[Hans-Georg L. (h-g-l)]

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 ...

[Mi N. (msx)]

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.

[Mi N. (msx)]

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.

[Benedikt S. (Gast)]

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

[Mi N. (msx)]

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!

[Peter D. (peda)]

Ist schon kraß, welche Unterschiede es beim 74AUP1G74 gibt.
TI: typisch 190MHz
NXP: typisch 619MHz

[Mi N. (msx)]

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?

[Mi N. (msx)]

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.

[Mi N. (msx)]

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

[Mi N. (msx)]

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 ;-)

[Sinus T. (micha_micha)]

Eine ein bischen OT-Frage: mit welcher Software wurden denn die 
Allan-Plots erstellt? Das sieht ja wesentlich besser aus als Stable32

[Bernd (Gast)]

Sinus T. schrieb:
> mit welcher Software wurden denn die
> Allan-Plots erstellt?
TimeLab:
http://www.miles.io/TimeLab/beta.htm

[Sinus T. (micha_micha)]

@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.

[Mi N. (msx)]

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).

[Benedikt S. (Gast)]

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

[Mi N. (msx)]

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.

[Pieter (Gast)]

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

[Mi N. (msx)]

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!

[Mi N. (msx)]

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.

[Ralf S. (ralf_s572)]

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)

[Einfach kündigen (Gast)]

@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.

[Ralf S. (ralf_s572)]

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.

[Einfach kündigen (Gast)]

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.

[Mi N. (msx)]

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.

[Ralf S. (ralf_s572)]

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.

[Ext clock fast (Gast)]

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?

[Max001 (Gast)]

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

[Ralf S. (ralf_s572)]

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.

[Ext clock fast (Gast)]

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.