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 :-)
Angehängte Dateien:
-
AVR_Fmeter_GPS.png
13 KB
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!
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.
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.
Es wurde oben von 7 Stellen gesprochen. Mit double ist es etwas Anderes, double bringt 15-16 dezimale Stellen.
> 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 :-)
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
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.
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!
oops, sorry, da habe ich die capture-routine falsch verstanden. Gruß Micha
Angehängte Dateien:
-
AVR_Fmeter_GPS.png
16 KB
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.
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
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:-)
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.
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.
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.
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.
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.
Angehängte Dateien:
-
fmgps_brd_1_1.jpg
150 KB
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 :-)
Thread beobachten
Seitenaufteilung abschaltenBitte 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.