Frequenzmessung per ICP

[Liquidator]

Hallo liebe Gemeinde,

heute wende ich mich mit einem erneuten Problem zu euch
Es geht um die Frequenzmessung mit einem ATmega8 per ICP mit Siebensegment-Anzeige.

Der Code ist fertig, aber es sind wohl Fehler oder Optimierungen nötig - mir fällt nichts mehr ein. Das Problem ist, dass die Frequenz zu sehr schwankt, so sehr, dass man die Zahlen kaum erkennen kann, was ja eigentlich nicht passieren darf. Sind hauptsächlich Einer-und Zehnerstellen der 4Segmente beteiligt.
Ist der 16Mhz Quarz wirklich so ungenau?

Danke schonmal.
Lg

[markusj]

Welche Frequenz misst du? Dein gewählter Ansatz ist sehr präzise bei niedrigen Frequenzen, bei höherfrequenten Signalen bekommst du aber schnell einen mehr oder wenig starken Jitter-Effekt. Dagegen könntest du die gemessene Frequenz noch über einen Mittelwert glätten. Eine andere übliche Lösung besteht darin, die Abtastrate zu reduzieren, also nicht ständig neue Werte aufs Display zu legen sondern nur noch alle 0,2s oder so. Und dann bist du schon fast bei einer Lösung für hochfrequente Signale: Innerhalb eines bestimmten Zeitintervalls Flanken zählen.

Grüße,
Markus

[Liquidator]

Mein Problem ist, dass ich den o.g. "Jittereffekt" mehr oder weniger schon in meinem Messbereich, 1-2000Hz, bekomme - was eigentlich nicht sein dürfte. Weshalb ich auch von einem Programmierfehler meinerseits ausgehe. Es flackern immer die Zehner-und Einerstellen, manchmal gibt es sogar einen 100Hz-Sprung zwischendurch! Für diese niedrigen Frequenzen habe ich, ehrlich gesagt, mehr Genauigkeit von ICP erwartet. Wo ist der Denkfehler?

Da ich möglichst keinen Offset in der Messung haben möchte, würde ich nur ungerne Torzeiten einsetzen... Ist diese Ungenauigkeit üblich?

MfG,
Nik

P.S: Eine hohe Genauigkeit ohne Schwanken erlebe ich bis zu 80Hz, aber da schwankt es stark.

[markusj]

Ist diese Ungenauigkeit üblich?

Nein, da stimmt was nicht. Ich versuche Mal deinen Quelltext etwas zu kommentieren:

Zeile 83-90: Welchen Zweck haben HighByte und LowByte?
Davon abgesehen ist es falsch den Overflow-Interrupt vorzuziehen. Entweder gab es bis zum Auftreten des Capture-Ereignisses keinen Überlauf und dann darf z nicht inkrementiert werden, oder es kam zeitgleich oder kurz bevor der Capture-Interrupt abgearbeitet wurde zu einem Überlauf und dann machst du nur einen kleinen Fehler. Ziehst du den Capture dagegen vor machst du einen Fehler von bis zu 2^16.
Zeile 94: Die Flags werden nur gelöscht wenn der zugehörige Interrupt ausgeführt wird. Wenn der Code nicht sowieso falsch wäre, müsstest du das Flag also tatsächlich hier manuell löschen.
Zeile 114: Die Berechnung ICR1 - Startzeit funktioniert nur solange du mit 16-Bit rechnest. So führst du bei einem Überlauf eine ungewollte Subtraktion durch.
Zeile 111, 122-123 : Unnötig

Grüße,
Markus

[Besserwessi]

Auch wenn der gemessene Wert nur geringfügig schwankt, kann da von auch die 100er Stelle betroffen sein, z.B. zwischen 199 Hz und 200 Hz.


An sich kann ich da keinen Fehler mehr erkennen (wohl aber noch Verbesserungspotential). Bei 2000 Hz. hat man noch etwa 8000 Taktzyklen für eine Periode. Das sollte eigentlich noch für 1 Hz Auflösung reichen.

Die Frage ist auch etwas wo kommt das gemessene Signal her, und wie ist die Wandlung in ein Digitales Signal. Auch da können noch Störungen (z.B. 50 Hz) reinkommen und ggf. einen Jitter bzw. eine scheinbare Frequenzmodulation erzeugen.

- - - Aktualisiert - - -

Das selten Vorziehen des Timer overflow interrupts hat schon seine Berechtigung:

Der ICP Interrupt hat die höhere Priorität (d.h. wird bei gleichzeitig gesetzten Flags zuerst ausgeführt). Es kann also in eher seltenen Fällen vorkommen, dass der ICP Interrupt aufgerufen wird, obwohl der Overflow Interrupt eigentlich vorher dran wäre. Dieser Fall lässt sich daran erkennen, dass das der Overflow interrupt wartet (TOV1-Flag gestetzt) und gleichzeitig der ICP-Wert klein ist (weil die Flanke so kurz nach dem Overflow kam das keine Zeit für die Ausführung war).

[markusj]

Das selten Vorziehen des Timer overflow interrupts hat schon seine Berechtigung:

Schon klar, "falsch" war vielleicht etwas übertrieben ausgedrückt, aber: Durch unglückliches Timing kann auch der OVF-Flag gesetzt werden nachdem das Capture-Ereignis eingetreten ist. Wenn dann der Overflow vorgezogen wird, kommt es zu einem Fehler in der Größenordnung von 2^16. Der umgekehrte Fall ist weniger Problematisch, die Abweichung durch die höhere Priorität beträgt dann ja nur wenige Takte (Interrupt-Verzögerung).
Es gibt aber mindestens einen Fall in dem du chancenlos bist: Start und Stopp bei TCNT=0. OVF und ICP treten gleichzeitig auf und in dem Fall gibt es einen Fehler von -2^16.

Grüße,
Markus

[sternst]

aber: Durch unglückliches Timing kann auch der OVF-Flag gesetzt werden nachdem das Capture-Ereignis eingetreten ist. Wenn dann der Overflow vorgezogen wird ...

Wird er ja aber nicht, dafür ist schließlich der kleiner-Vergleich da.
OVF gesetzt + ICP ist "klein" -> Overflow vor Capture-Ereignis (mitzählen)
OVF gesetzt + ICP ist "groß" -> Overflow nach Capture-Ereignis (nicht mitzählen)

Der umgekehrte Fall ist weniger Problematisch, die Abweichung durch die höhere Priorität beträgt dann ja nur wenige Takte (Interrupt-Verzögerung).

Nein, DANN hat man einen Fehler von 2^16, weil ein Overflow (und damit ein kompletter Timer-Zyklus) nicht mit eingerechnet wird.

Es gibt aber mindestens einen Fall in dem du chancenlos bist: Start und Stopp bei TCNT=0. OVF und ICP treten gleichzeitig auf und in dem Fall gibt es einen Fehler von -2^16.

Nein, auch der Fall wird durch das gegebene Schema abgedeckt, weil 0 = "klein".

[Besserwessi]

Egal wie man es macht, wenn man beim zählen der Überläufe um einen daneben ist, ist der Fehler 2^16 Zyklen. Man sollte es also schon richtig machen - der mögliche Fehler ist zwar selten, aber wenn dann deutlich.
Wie schon richtig erkannt ist das Problem wenn ICP und Überlauf praktisch gleichzeitig auftreten. Das kann beim ICP Wert von 0 passieren, aber ggf. auch bei einem kleinen ICP Wert bis vielleicht 100, durch die paar Zyklen die es braucht eine Befehl zu Ende auszuführen oder was länger dauert den 3. Interrupt von Timer 2 auszuführen. Wenn beide Interrupts anstehen, wird zuerst der ICP Interrupt ausgeführt, auch wenn eigentlich erst der Überlauf dran wäre. Die IF Anweisung fängt genau diese Fälle ab, ohne einen verbleibenden Fehler. Wenn der ICP Wert klein ist, und gleichzeitig noch ein Overlow Interrupt ansteht heißt das, dass die Flanke kurz nach dem Overflow kam der wartende Overflow Interrupt eigentlich vorher hätte kommen müssen. Der Fall mit ICP=0 ist dabei nicht mal ein Sonderfall, sondern fällt auch in das Schema. Bei der etwas unscharfen Bedingung "ICP klein" hat man recht viel Spielraum: ICP und Overflow fast gleichzeitig passiert halt nur bei sehr kleinen ICP Werten (d.h. in der Regel unter etwa 200, oder wie lang Interrupts maximal gesperrt sind) oder bei sehr großen werten halt ICP so um 65000. Die Grenze mit 128 am High-byte ist da relativ beliebig und unkritisch. Der Fall das das Overflow Ereignis nach dem ICP kommt führt dann zu einen sehr großen ICP Wert, dicht an der oberen Grenze. In dem Fall wird dann der Overflow Interrupt auch nicht vorgezogen.