Jan W. schrieb:
> Weiß nicht genau ob ich das richtig verstehe. Ich bin da auf eine
> Messfrequenz von ca. 50Hz gekommen, ohne wirklich große Latenz.
Das Problem ist das: du hast einen Hardwaretimer, der tatsächlich mit
10ms Abstand einen Interrupt auslöst:
1 | timer 0 10ms 20ms 30ms 40ms ....
|
2 | überlauf | | | | |
|
Normalerweise wird diese Interruptanforderung auch recht zügig
bearbeitet:
1 | timer 0 10ms 20ms 30ms 40ms ....
|
2 | überlauf | | | | |
|
3 | interruptbearb. # # # # #
|
Bis dann das Betriebssystem kommt und noch "wichtigere Dinge" zu tun hat
oder fertig machen muss (einfach mal im Hintergrund Dateien kopieren,
Netzwerktraffic aufbauen oder zufällig den USB-Stick einstecken). Dann
wird auf einmal dein Code mit 5ms Verzögerung bearbeitet. Weil der
nächste Timerüberlauf wieder pünktlich kommt und der Interrupt wieder
schnell bearbeitet wird, "stolpert" dein Timing:
1 | timer 0 10ms 20ms 30ms 40ms ....
|
2 | überlauf | | | | |
|
3 | interruptbearb. # # # # #
|
Nun bist du aber bei deinem Messungen von gleichen 10ms Zeitabständen
ausgegangen und hast aus den 10ms Zeitabständen und dem
Abstandsdifferenzen die aktuelle Geschwindigkeit ausgerechnet. Klar ist
das Objekt aber in den realen 15ms und 5ms weiter oder weniger weit
gefallen und du bekommst dadurch Schwankungen in der Kennlinie.
Probiere das einfach mal aus: toggle aus deinem Programm mit 100Hz einen
EA-Pin. Schließe an diesen Pin ein digitales Oszilloskop an. Und jetzt
zeige einen vollen Impulszyklus auf dem Oszilloskop an und stelle die
Nachleuchtzeit auf "unendlich".
Im Idealfall sollte das am nächsten Morgen so aussehen:
1 | Trigger
|
2 | V
|
3 |
|
4 | .----------------. .--------------
|
5 | | | |
|
6 | | | |
|
7 | | | |
|
8 | | | |
|
9 | -------' '----------------'
|
Wenn dabei dann einmal der oben beschriebene Fehler aufgetreten ist,
sieht es z.B. so aus:
1 | Trigger
|
2 | V
|
3 |
|
4 | .----------------. .-------.------
|
5 | | | | |
|
6 | | | | |
|
7 | | | | |
|
8 | | | | |
|
9 | -------' '---------'-------'
|
Was du aber vermutlich sehen wirst, ist so etwas:
1 | Trigger
|
2 | V
|
3 |
|
4 | .------------......... .........------------
|
5 | | ||||||||| |||||||||
|
6 | | ||||||||| |||||||||
|
7 | | ||||||||| |||||||||
|
8 | -------' '''''''''---------'''''''''
|
Das zeugt dann davon, dass ständig solche "Ungenauigkeiten" aka. Jitter
auftreten. Dann gilt es abzuschätzen, inwiefern das für die Erfassung
und die zuverlässigkeit der Messwerte schlecht ist.
Und im schlimmsten Fall passiert es, dass die Linien oben und/oder unten
ganz durchgehen:
1 | Trigger
|
2 | V
|
3 |
|
4 | .------------.........---------.........------------
|
5 | | ||||||||| |||||||||
|
6 | | ||||||||| |||||||||
|
7 | | ||||||||| |||||||||
|
8 | -------' '''''''''---------'''''''''
|
Dann ist der Interrupt während eines kompletten Zimerzyklus nicht
bearbeitet worden und ging "verloren". Das "Übersehen" von
Interruptanforderungen kann in den allermeisten Fällen nicht toleriert
werden.
War jetzt viel Text, ist aber auch kein ganz einfaches Thema. Es
bedeutet lediglich: du musst dein System und seine Grenzen kennen, vor
du ihm über den Weg traust und den gemessenen Werten glaubst.
