Hallo zusammen,
wollt in Erfahrung bringen, ob der Fehler meines Counters im normalen
Toleranzbereich liegt oder ob der Fehler mein Verschulden ist.
Anwendung: Frequenz/Periodendauer messen.
Messmethode: Flanken dedektieren und Zeit dazwischen messen.
uC: ATmega16 (Unter Verwendung der "Input Capture Unit" im uC)
(Fehler-)Beschreibung: Die Software die ich dazu geschrieben hab, gibt
mir immer einen um 10 Zählerschritte zu niedrigen Wert aus (Geprüft am
Oszilloskopen). Getesteter Frequenzbereich 100-1000Hz.
Ausgeschlossenes: An der Laufzeit meines Programs liegt es denke ich
nicht. Dafür ist der Fehler zu konstant. Und bei Laufzeitfehlern müsste
der Zählerwert höher sein und nicht niedriger.
Vermutung: Quarz zu langsam oder interner Oszilator zu langsam.
<<Und hier nochmal meine Frage: Normaler Toleranzbereich?>>
PS: Denke es kommen jetzt erst einmal mehr Fragen als Antworten. :D
Spielt der "Noise Canceler" eine Rolle?
Könnte Da eine Hysterese ein Rolle spielen?
Messe doch mal zwischen den jeweils entgegengesetzen Signalflanken?
poste doch einfach mal den Code!
Wenn es bei jeder Frequenz 10 Schritte (also Taktzyklen) sind, dann
liegt es vermutlich am Programm.
Wenn es Unterschiede bei den Frequenzen gibt, oder Abweichungen bei
einer Frquenz, dann müsste es mit der Takterzeugung zutun haben.
Erst mal danke für das rege Interesse und eure Hilfsbereitschaft.
Also...
Jan: Es sind immer 10 Schritte. Egal ob ich 100Hz(Zählerstand= 9990),
110Hz(9080) ... 990Hz (1000) oder 1000Hz(990) messen will. Prozentual
gesehen, steigt mein Fehler mit der Frequenz. Beäugt man es schlicht
und einfach, zählt er mir immer 10 zu wenig. uC-Clock= 8MHz (Quarz) und
Prescaler=8 macht pro Zählschritt 1us.
Werner: Ich denke nicht, dass der Noise Canceler eine Rolle spielt. Zum
einen hab ich den nicht aktiviert und zum anderen würde mein Zählerstand
denke ich grösser ausfallen und nicht kleiner.
An eine Hysterese hab ich auch gedacht. War´s aber leider nicht. Hab
die Anstiegszeiten mit dem Oszi. gemessen. liegt im ns-Bereich. Ist
denke ich zu vernachlässigen, da ich im us-Bereich zähle.
Das mit den entgegengesetzten Signalflanken probier ich mal.
Mark: Es ist eine Rechteckspannung (TTL-Pegel).
Rahul: Das mit dem Code posten kann ich leider erst morgen machen.
Nach euren Aussagen, heisst das wohl, dass das nicht normal ist.
Dann heisst das für mich wohl auch, weiter mit der Fehlersuche.
Gruß,
Leo
wenn die Abweichung konstant (absolut) ist, dann ist der Fehler doch
erst bei Frequenzen relevant, für die die 10 Schritte ein Fehler im
Prozentbereich (>1000Hz) bedeuten.
Und ich vermute den Fehler eher im Programm.
Würde es am Quarz oder so liegen, dann würde die Abweichung schwanken.
Hallo,
Vermutung: 10 Takte zwischen Interrupt-Aufruf und löschen des Timers?
Aber ohne Deinen Code zu kennen ist es unmöglich zu erkennen wo die 10
Zählschritte (80 Takte?) versickern.
Ciao,
Werner
Das vermute ich auch. Die 10 Takte können vergehen durch
Intterrupt-Respnse-Time und Sprung zur ISR.
Man sollte bei ICP den Timer keinesfalls löschen, sondern die Differenz
zum vorherigen "Zeitstempel" berechnen (den man sich natürlich merken
muss). Das wird dann sehr genau. Und zusätzlich kann man noch die
Output-Compare-Interrupts nutzen, ohne ICP zu beeinrtächtigen.
...
Tach zusammen....
Rahul: Ganz genau erkannt. Will auf 1Hz genau messen. Bei 100Hz ist es
noch kein Problem (Fehler= 0,1Hz). Bei 1kHz ist es dann unaktzeptabel
(Fehler= 10Hz).
Rahul&Werner: Ob dass nun am Programm liegt, wollt ich eigentlich
ausschliessen. Hab mir meinen Code im AVRStudio angeschaut
(Disassembler) und die Befehle gezählt. Passt!
Hab die die dazugehörige Interrupt Service Routine mal angehängt.
Gruß,
Leo
Hi
wie Hannes geschrieben hat: Du solltest niemals das Timer-Zählregister
löschen. Input Capture funktioniert auch ohne dieses Löschen wenn du
die Differenz zwischen zwei Capture-Events berechnest.
Matthias
Hallo,
ich denke, dat is it.
>>> Intterrupt-Resp"o"nse-Time und Sprung zur ISR. <<<
Hab zum Testen ´nen Portpin in der ISR gesetzt. Hab dann darauf
getriggert und siehe da: Zwischen Flanke des Eingangssignal und dem
Peak vom Portpin ein schönes konstantes Delay. Werde jetzt (erstmal)
ein Korrekturwert zu meinem Zähler dazu addieren und weiter coden.
Hoffe das es so gut geht.
Dank&Gruß an alle, lesen von einander,
Leo
Hallo Werner,
hab mir deine Version mal angeschaut. Gefällt mir ganz gut.
Aber was passiert wenn der Zähler überläuft und wieder von 0 an gezählt
wird (temp < dutycycle_value)?
Deine Erklärung als Kommentarzeilen hab ich leider nicht verstanden.
Gruß,
Leo
Eine eigene Frage?
Dieser Thread ist über 20 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.