Forum: Projekte & Code reziproker Frequenzzähler, GPS-stabilisiert, ATmega162


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von m.n. (Gast)


Angehängte Dateien:

Lesenswert?

In letzter Zeit wurden hier einige reziproke Frequenzzähler vorgestellt, 
die mit unterschiedlicher Hardware umgesetzt wurden. Bei allen ist die 
Genauigkeit/Auflösung in erster Linie von der Stabilität der 
Referenzfrequenz 'Fref'(=Taktfrequenz des Prozessors) abhängig. Wenn es 
sehr genau sein soll, reicht ein einfacher Quarz mit bis zu 50ppm Drift 
nicht mehr aus; ein TCXO bietet maximal 0,5ppm über einen bestimmten 
Temperaturbereich, altert allerdings auch mit bis zu einigen ppm/Jahr. 
Vorgeheizte OCXO sind einiges teuerer und brauchen permant Heizleistung.
Verwendet man hingegen eine der vielen hochstabilen Frequenzen, die in 
der 'Luft' frei verfügbar sind, könnte man daraus eine langzeitstabile 
'Fref' ableiten.

Typische Werte für 'Fref' liegen bei 10MHz und darüber. Um 'Fref' aus 
einer hochfrequenten Senderfrequenz abzuleiten, bedarf es eines 
stabilen, ungestörten Empfangs und einer PLL, die 'Fref' auf 
Soll-Frequenz nachregelt.
Zu geringen Kosten und mit wenig Aufwand (fertige Baugruppe) bietet sich 
ein 1pps (1 Puls pro Sekunde) GPS-Signal an, welches einige GPS-Module 
zur Verfügung stellen. Dieses 1Hz-Signal über eine PLL auszubereiten, 
würde allerdings zu sehr langen Einschwingzeiten führen, sobald es 
einmal abgeschaltet/unterbrochen war, was eine mobile Anwendung 
erschweren würde. Nachfolgend wird eine andere Lösung beschrieben.


Die Schaltung:
Die obige Schaltung zeigt einen reziproken Frequenzzähler, der zunächst 
nur die Genauigkeit des Quarzoszillators des µC aufweist. Das Besondere 
ist ein weiterer Frequenzzähler-Eingang, der anhand eines 1pps 
GPS-Signals die aktuelle Taktfrequenz jede Sekunde neu ermittelt und 
diese bei der Berechnung der Eingangsfrequenz 'Fin' berücksichtigt. Bei 
Frequenzschwankungen durch Temperatur/Versorgungsspannung/Alterung muß 
keine PLL nachgeregelt werden.

Dafür benötigt wird ein Prozessor, der zwei Frequenzen gleichzeitig 
hochgenau erfassen kann.
Angelehnt an eine vorhandene Schaltung 
(Beitrag "einfache Drehzahlmessung mit ATmega88"), bietet sich ein 
Atmega162 an, der einen weiteren Timer (T3) mit 16bit Auflösung und 
Capture-Eingang aufweist und im DIL-Gehäuse einen einfachen Nachbau 
erlaubt. Andere ATmega64/128/... oder ATmega1284P gibt es nur im 
TQFP-Gehäuse oder sind schwer zu beschaffen.
Als GPS-Modul wird ein EM-406A mit 1pps-Ausgang verwendet. 
http://www.dpcav.com/data_sheets/EM-406A_Product_Guide1_1.pdf

Das Programm:
Wegen der Übersichtlichkeit bietet das .c-Programm nur die wesentlichen 
Funktionen. Die eigentliche Frequenzmessung findet in main() statt und 
wertet die Ereignisse von T1_CAPT und T1_OVF aus.
In ähnlicher Weise wird das 1pps-Signal per T3_CAPT und T3_OVF in einer 
separaten Funktion bewerte_referenz_frequenz() gemessen und über 4s 
gleitend gefiltert. Berücksichtigt wird es aber nur dann, wenn die 
vorgegebene Taktfrequenz (16MHz) plausibel ist und nicht mehr als 
+/-100ppm vom Sollwert abweicht. Fällt das GPS aus, wird mit dem letzten 
Wert der Ist-Frequenz weitergemessen.

Verbesserungen:
Als erste Verbessung könnte die Ist-Frequenz alle 10 Minuten im EEPROM 
abgelegt und beim nächsten Einschalten als Vorgabe verwendet werden.
Auch ein automatisch zugeschalteter Vorteiler fehlt hier noch und sollte 
nachgerüstet werden. Die maximale 'Fin' kann damit leicht auf >50MHz 
erhöht werden.
Auf der Anzeige werden Frequenz und Periodendauer mit 7-stelliger 
Auflösung angezeigt; mehr gibt das float-Format nicht her.
#define TEST_LAUF ersetzt in der Anzeige die Periodendauer durch die 
ermittelte 'Fref'. Hier kann man erkennen, wie sich die Quarzfrequenz 
ändern kann, das Ergebnis aber konstant bleibt: 1pps-Signal an 'Fin' 
legen.

Das Programm ist hinreichend kommentiert und seine Funktion sollte 
verständlich sein. In der gezeigten Form werden Eingangsfrequenzen von 
0,004Hz – 250kHz verarbeitet.
Das ist der optimale Bereich, um Blinkfrequenzen von 
Weihnachtsdekoration exakt auf Sollwert zu kontrollieren :-)

von Hauke R. (lafkaschar) Benutzerseite


Lesenswert?

Interessantes Projekt, ich hab shcon bie den anderen Frequenzzählern 
mitgelesen, aer die Idee mit GPS ist echt gut, hab hier noch n haufen 
GPS Empfänger mit 1pps ausgang. Mit einem Vorteiler hat man dann ein 
echt brauchbares Gerät!

von Purzel H. (hacky)


Lesenswert?

Wer braucht portable so eine Genauigkeit ? Naja moeglicherweise gibt's 
jemanden. Die Idee ist auf all Faelle gut. Zur Implementation. Wenn man 
sich auf Float beschraenkt hat man verloren, denn 32bit-Float bietet nur 
5-6 digits, das reicht nicht mal die Genauigkeit eines TCXOs 
darzustellen. Fuer einen OCXO benoetig ich schon mal 8 digits. Und fuer 
die mit GPS erreichbar Genauigkeit sollte man sich schon 9 digits plus 
goennen. Der 100ppm 16MHz Quarz fuer 15 cents ist Quatsch. Fuer ein paar 
Euro kriegt man einen 0.5ppm TCXO. Dann sollte man gleich mit dem 
beginnen.

von m.n. (Gast)


Angehängte Dateien:

Lesenswert?

Es ist ein beliebter Spaß, float zu zerreden: ich kann auch anders :-)

Das Programm läßt sich auch mit einem kostenlosen IAR-Kickstart Paket 
übersetzen, da die Größe unter 4kB bleibt. Die 64-bit double habe ich 
dabei schon aktiviert. Bei Optimierung auf min. Größe sind es 3670 
Bytes; Code für den Vorteiler passt noch locker dazu.

von Purzel H. (hacky)


Lesenswert?

Es wurde oben von 7 Stellen gesprochen. Mit double ist es etwas Anderes, 
double bringt 15-16 dezimale Stellen.

von m.n. (Gast)


Lesenswert?

> Es wurde oben von 7 Stellen gesprochen.

Richtig, und zwar von 7 Stellen Auflösung. Diese ist notwendig, um bei 
einem Anzeigewert von "1.000001" die letzte Stelle mit der gleichen 
Wertigkeit anzuzeigen wie bei "999.999".

> Fuer einen OCXO benoetig ich schon mal 8 digits.

Hier sind Ursache und Wirkung vertauscht.

> Der 100ppm 16MHz Quarz fuer 15 cents ist Quatsch.

Bei mir laufen auch Schaltungen mit TCXO und OCXO. Wer einen TCXO hat, 
kann ihn natürlich verwenden. Ein Quarz ist bei der obigen Schaltung 
aber ausreichend, da er hinreichend kurzzeitstabil ist. Attacken mit 
Lötkolben und Kältespray im Sekundentakt sollte man aber unterlassen :-)

von Constanze H. (warteschleife)


Lesenswert?

die ganze Diskussion ist sowieso hier überflüssig.
Bei dieser Messmethode ist alles über 1,6 Hz Eingangsfrequenz
nicht mehr mit 7 digits genau erfassbar. Da braucht man über
float oder double prcision garnicht mehr zu reden.

Bei nur 5kHz Eingangsfrequenz sieht es schon so aus:

5kHz mit 16MHz Referenz = 3200 counts

3199 counts = 5001,56Hz
3200 counts = 5000,00Hz
3201 counts = 4998,44Hz

Gruß
Micha

von Christian K. (Gast)


Lesenswert?

Michael H. schrieb:
> Bei dieser Messmethode ist alles über 1,6 Hz Eingangsfrequenz
> nicht mehr mit 7 digits genau erfassbar. Da braucht man über
> float oder double prcision garnicht mehr zu reden.
>
> Bei nur 5kHz Eingangsfrequenz sieht es schon so aus:
>
> 5kHz mit 16MHz Referenz = 3200 counts

Dieser Zähler wertet bei 5 kHz nicht nur eine Periode aus, sondern zählt 
ca. 410 ms lang volle Perioden.

Das Funktionsprinzip ist auf der Website beschrieben:
http://www.mino-elektronik.de/fmeter/fmeter.htm#funk

Christian.

von Tany (Gast)


Lesenswert?

Michael H. schrieb:
> die ganze Diskussion ist sowieso hier überflüssig.
> Bei dieser Messmethode ist alles über 1,6 Hz Eingangsfrequenz
> nicht mehr mit 7 digits genau erfassbar. Da braucht man über
> float oder double prcision garnicht mehr zu reden.
>
> Bei nur 5kHz Eingangsfrequenz sieht es schon so aus:
>
> 5kHz mit 16MHz Referenz = 3200 counts
>
> 3199 counts = 5001,56Hz
> 3200 counts = 5000,00Hz
> 3201 counts = 4998,44Hz
>
> Gruß
> Micha

Man..man!

von Constanze H. (warteschleife)


Lesenswert?

oops, sorry,
da habe ich die capture-routine falsch verstanden.


Gruß
Micha

von m.n. (Gast)


Angehängte Dateien:

Lesenswert?

Die ursprüngliche Schaltung habe ich um einen Vorteiler erweitert, der 
den Frequenzbereich nach oben auf >50MHz erweitert. Der Vorteiler 
schaltet sich automatisch ab 100kHz zu und unter 50kHz wieder ab. 
Passend zur Jahreszeit wird dies mit einer separaten LED angezeigt.
Eine weitere LED gibt Information über das GPS-Signal. Wird dieses 
erkannt, blinkt die LED bis es für 4 Zyklen konstant anliegt. Danach 
bleibt sie dauerhaft eingeschaltet.

Die Rechnerei mit 64-bit double habe ich beibehalten. Trotzdem bleibt 
der Code mit <3800 Bytes sehr kompakt und läßt noch Erweiterungen selbst 
dann zu, wenn das genannte Kickstart-Paket verwendet wird. Wer keine 
eigenen Programmerweiterungen braucht, kann auf die fmgps.hex 
zurückgreifen.

Die Referenzfrequenz zyklisch ins EEPROM zu packen, werde ich bei 
Gelegenheit noch ergänzen. Auch bei einem Ausfall des GPS-Signals bleibt 
dann die Schaltung automatisch abgeglichen. Da ich schon diverse 
Programme und Schaltungen zusammengefasst habe 
(http://www.mino-elektronik.de/fmeter/fm_software.htm), werde ich 
Updates aber wohl dort einstellen.

Vielleicht macht sich jemand die Arbeit, das EEPROM für die Ablage der 
Referenzfrequenz zu nutzen. Die Speicherung manuell zu aktivieren, wäre 
der erste Schritt. Ein 'unsigned long' Wert würde ja schon reichen.

von Peter D. (peda)


Lesenswert?

Michael H. schrieb:
> die ganze Diskussion ist sowieso hier überflüssig.
> Bei dieser Messmethode ist alles über 1,6 Hz Eingangsfrequenz
> nicht mehr mit 7 digits genau erfassbar. Da braucht man über
> float oder double prcision garnicht mehr zu reden.

Stimmt fast.
Der CPU-Takt und die Meßzeit bestimmen die maximal möglich Auflösung.
Bei 16MHz und 0,5s Meßzeit kann man nur bis 8.000.000 auflösen. Alles 
darüber ist sich in die eigene Tasche zu lügen.

Bei hohen Signalfrequenzen wird das sogar noch ungenauer, da während der 
Programmlaufzeit für das Auslesen der Timerregister weitere 
Input-Capture erfolgen können.

Die Input-Capture-Logik ist nicht richtig durchdacht. Das gesetzte 
Interrupt-Flag müßte weitere Capture sperren, sodaß immer nur der erste 
Capture-Zählerstand gelesen wird.


Peter

von m.n. (Gast)


Lesenswert?

Bei Problemen mit der Capture-Logik bei AVRs empfiehlt es sich, die 
Diskussion mit dem Hersteller zu suchen. Bei der hiesigen Schaltung ist 
deren Funktion über den gesamten Frequenzbereich voll in Ordnung.

Den Unterschied von Auflösung und Genauigkeit hatte ich eigentlich als 
bekannt vorausgesetzt und weiter oben kurz darauf hingewiesen, warum 
eine 7-stellige Anzeige hier genau richtig ist.
Das Programm liegt als Quelltext vor und bietet damit die Möglichkeit, 
es seinen eigenen Bedürfnissen anzupassen.

Für feinere Anpassungen von Messdauer und Auflösung gibt es eine fertige 
Lösung: http://www.mino-elektronik.de/fmeter/neue_versionen.htm#a9
Per RS232 kann man z.B. die Messdauer in ms-Stufen vorgeben, und - 
meinem Vorredner zum Trotz - sogar die Anzahl der angezeigten Stellen 
'mutwillig' erhöhen. Die Schaltung arbeitet mit 20MHz etwas höher hier 
der ATmega162, was aber für ein Rechenbeispiel nicht von Belang ist.


Die Anzahl der angezeigten Stellen wird normalerweise automatisch der 
Messzeit angepasst. Dazu ein Beispiel:
99 Hz Messfrequenz bei kürzester Messzeit ergibt eine Messdauer von 10,1 
ms mit ca. 202000 Referenzimpulsen. Dies führt zu einer automatischen 
5-stelligen Anzeige von 99,000 Hz.
Wie man sieht, ist die Auflösung höher als der angezeigte Wert und damit 
voll in Ordnung.
Misst man hingegen 101 Hz ist die Messdauer 9,9 ms mit 198000 
Referenzimpulsen und die wiederum 5-stellige Anzeige zeigt 101,00 Hz.
Bei dieser Messung wird jetzt eine ganze Stelle 'unterschlagen'.
101,000 Hz würde das Ergebnis immer noch optimal aufgelöst darstellen.
Und für diesen Fall ist es sinnvoll und korrekt hier eine 6-stellige 
Anzeige zu erzwingen!

Wer Sinn und Zweck begriffen hat und sich diese Schaltung nachbauen 
möchte, bekommt bei mir das Programm kostenlos dazu. Irgendwie muss man 
das ja belohnen:-)

von Tany (Gast)


Lesenswert?

Peter Dannegger schrieb:
> Stimmt fast.
>
> Der CPU-Takt und die Meßzeit bestimmen die maximal möglich Auflösung.

Auch nur fast. Nur die Meßzeit bestimmt die maximale Auflösung.

von m.n. (Gast)


Lesenswert?

Mit der zusätzlichen Speicherung des Abgleichwertes im internen EEPROM 
ist das Programm weitgehend fertig. Die Filterung des 1pps-Signals habe 
ich auf 10 s erhöht, die max. Messrate auf 1,6/s gesenkt und dem 
GPS-Signal noch eine Totzeit von 5 s gegeben, bevor es gefiltert wird. 
Wie angekündigt habe ich es in meine Programmsammlung aufgenommen. 
http://www.mino-elektronik.de/fmeter/fm_software.htm#bsp2

Die Codegröße läßt mit <4000 Bytes immer noch Platz für eigene 
Anpassungen. Ein ATmega1284 könnte regulär mit 20MHz laufen und wäre 
damit 25% schneller. Aus Jux hatte ich den ATmega162 mal mit 50% 
übertaktet - keine Probleme. Faktor 2 könnte man noch herausholen, wenn 
man den Vorteiler nicht verwenden möchte und die Interrupt-Routinen in 
Assembler schreibt.
Die vielen freien µC-Pins könnte man für ein Umschalten der min. 
Messzeit oder Umrechnung in Drehzahl o.ä. verwenden. Wenn man mit 
6-stell. Anzeige leben kann, würde auch das AVR-Studio mit seinen 
float-Berechnungen ausreichen, wobei dann auch die Codegröße nicht mehr 
limitiert wäre. Oder man verwendet für die Berechnungen 64-bit 
integer-Routinen, wie es an anderer Stelle in der Codesammlung gemacht 
wird.
Soweit.

von Christian K. (at90s2313)


Lesenswert?

Peter Dannegger schrieb:
> Bei hohen Signalfrequenzen wird das sogar noch ungenauer, da während der
> Programmlaufzeit für das Auslesen der Timerregister weitere
> Input-Capture erfolgen können.
>
> Die Input-Capture-Logik ist nicht richtig durchdacht. Das gesetzte
> Interrupt-Flag müßte weitere Capture sperren, sodaß immer nur der erste
> Capture-Zählerstand gelesen wird.

Ich sehe da eigentlich kein Problem. In main.c steht:
1
Funktionsbereich mit Vorteiler 0,004Hz - >50MHz bei 16MHz Prozessortakt
Ab 100 kHz schaltet sich der 8-bit-Vorteiler zu. Bei 50 MHz 
Signalfrequenz sieht der AVR nur ca. 200 kHz am Input-Capture-Pin. 
Zwischen zwei Input-Captures liegen also 16 MHz / 200 kHz = 80 
Prozessortakte. Das sollte meines Erachtens ausreichen, um in die 
Capture-Interruptroutine zu springen und den Capture-Zählerstand 
auszulesen. Selbst wenn der AVR gerade in der Timer-Overflow-Routine 
steckt, dürften die Takte noch ausreichen. Oder habe ich etwas 
übersehen?

Christian.

von m.n. (Gast)


Lesenswert?

Christian K. schrieb:
> Oder habe ich etwas übersehen?

Nein, genau so und nicht anders :-)
Der ICP1-Eingang wird zudem noch doch D1, C3 und R5 vor einer zu hohen 
Frequenz geschützt, sodass keine Blockade des Prozessors durch zu hohe 
Interruptraten eintreten kann. Ein Umtasten der Eingangsfrequenz 
zwischen beispielsweise 10kHz und 10MHz wird problemlos verarbeitet. Den 
Eingang AIN1 könnte man im Prinzip auch so abblocken, man sieht der 
Anzeige aber schon vorher an, dass die Grenzfrequenz erreicht wird. Auch 
der Vorteiler selbst hat seine obere Grenzfrequenz.
Ein größerer Vorteiler könnte die max. Eingangsfrequenz deutlich 
erhöhen. Ein 74VHC4040 läuft bis 200MHz und teilt maximal durch 4096. 
200MHz würden auf ca. 50kHz reduziert: kein Problem für einen ATmega. Es 
gibt noch eine Menge Möglichkeiten, den Programmablauf zu 
beschleunigen/optimieren. Das Programm wäre dann aber nicht mehr so 
transparent.

Wenn man oben genannte Probleme mit der Capture-Logik hat, kann man 
nachtriggerbare Monoflops vor die ICPx-Eingänge schalten. Die uralten 
xx123 oder die nicht ganz so alten 74HC4538 sind gut dafür geeignet.

von Stephan H. (stephan-)


Lesenswert?

Hallo Michael,

die Platinen möchtest Du aber nur verkaufen ... oder ?
Alles offen, Schaltung, Hex File etc. Nur kein Layout.
Ich fand jedenfalls kein Layout (nur vom alten Model) ABER auch keine 
Preise zu Platinen auf Deiner Seite. :-((

Ist das ein Geheimnis ? Nur auf Anfrage ?

Danke

An sonsten ein schönes Projekt. Auch die Vorgänger davon.
Schön klein, schöne Arbeit.

von m.n. (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Stephan,
ein Bild sagt mehr als 1000 Worte. Die Schaltung kann man locker zu Fuß 
aufbauen.
Was andere Schaltungen angeht, so lasse ich diese als Musterplatinen mit 
fertigen, teilweise auch, um auf die Mindestfläche von 1dm² zu kommen. 
Wenn jemand Interesse daran hat, gebe ich diese zu Selbstkosten weiter. 
Dadurch ergeben sich für die leeren Leiterplatten rund zehn Euro.
Wer selber löten will, bekommt die Programme für Umme in den µC 
gebrannt. Bei DIL-Gehäusen ist das kein Problem.
Geld verdiene ich hiermit nicht und wer ernsthaftes Interesse an den 
Schaltungen hat, meldet sich bei mir. Meine Layouts oder die weiteren 
FM-Programme möchte ich nicht zur Diskussion stellen. Völlig irrsinnige 
Einwände, wie weiter oben (capture-Logik), erspare ich mir dadurch :-)

von Stephan H. (stephan-)


Lesenswert?

o.k. Das kann ich nachvollziehen.

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
Noch kein Account? Hier anmelden.