welche Signalfilterung für meine Messdaten?

Simple moving average oder exponential moving average.

SP90 schrieb:
> Anbei ein beispielhafter Verlauf der Drehzahl (oben) und der
> Interrupts (unten).

Jetzt fehlt nur noch eine vernünftige Zeitachse, um beurteilen zu 
können, wie die Dynamik der Daten in Relation zu deiner gewünschten 
Zeitauflösung steht. Was verwendest du als Interruptquelle?
Und warum zählst du nur die Interrupts, statt jedem Interrupt einen 
Timestamp zuzuordnen?

Du musst Dir klar werden, warum die Messwerte zappeln.

Ein Verlorener Interrupt geht gar nicht --> dann ist die Messung 
wertlos.

Vermutlich musst Du Dich mit "Fehlerrechnung" bzw. "Auflösung" 
beschäftigen.

Meist zappeln die Werte, weil die Auflösung der Messung (z.B. 1ms) und 
der Messjitter (z.B. Verzögerung des Interrupts) zu groß sind. Dass 
musst Du herausfinden/messen und Dir vergegenwärtigen 
(ausrechnen/aufmalen). (Was macht eine Einheit mehr oder weniger aus)

(Der Mess-Jitter ist etwas anderes als Genauigkeit, da der Wert in der 
einen loop zu lang, in der nächsten dann vermutlich zu kurz wird)

Glätten kannst Du erst dann und nur nachdem Du Dir klar wirst, was Du 
sehen willst und was nicht.

SP90 schrieb:
> Gibts da eine zielführendere Methode der Signalfilterung?

Kannst du akausale Filter verwenden oder muss der geglättete Wert für 
die Drehzahl live zur Verfügung stehen?

SP90 schrieb:
> Ich glaube das kommt daher, dass man von
> einem sehr kurzen Zeitraum in dem man die Interrupts zählt (ca. 100-150
> ms) auf eine Minute hochrechnet

Dann ist schon die Messung ungeeignet, da helfen Filter nicht mehr viel. 
In so einem Fall zählt man nicht Impulse, sondern misst den Abstand 
zwischen den Impulsen - also Periodendauer statt Frequqnz, das macht man 
auch bei Frequenzmessungen so. Die Periodendauer lässt sich praktisch 
beliebig genau messen, das hängt nur von der Hardware ab, während die 
Zählung von Perioden in einem festen Intervall prinzipiell beschränkt 
ist durch die Dauer des Intervalls und die Zahl der darin auftretenden 
Impulse, daran kann man nichts ändern ausser längere Intervalle zu 
nehmen.

Georg

Hallo,

und vielen Dank für die zahlreichen Antworten. Ich werd versuchen das 
genauer zu erklären bzw. drauf einzugehen.

Mein Programm ist in C# programmiert und läuft als UWP auf Windows IoT 
am Raspberry. Ich verwende einen DispatcherTimer um die GUI zu 
refreshen. Der ist nicht allzu genau, muss er dazu aber auch nicht. 
Daher kommt mein Intervall von ca. 100-150 ms. Daher läuft eine (genaue 
bzw. genauere) Stopwatch. Diese misst die Zeit zwischen den Timer-Ticks 
und wird mit jedem Tick wieder auf Null gesetzt und gestartet. Aus 
dieser Zeit und den Interrupts wird die Drehzahl in U/Min berechnet.


A. S. schrieb:
> (Was macht eine Einheit mehr oder weniger aus)

Ein Interrupt mehr oder weniger macht bei dem Intervall 200-300 U/Min 
aus.

MaWin schrieb:
> Simple moving average oder exponential moving average.

Das werd ich auf jeden Fall mal ausprobieren

Wolfgang schrieb:
> Jetzt fehlt nur noch eine vernünftige Zeitachse, um beurteilen zu
> können, wie die Dynamik der Daten in Relation zu deiner gewünschten
> Zeitauflösung steht.

Ja stimmt, die Zeit würde nicht schaden. Da aber der Intervall in etwa 
konstant ist würde sich die Achse nur als ganzes dehnen oder stauchen. 
Die Aufzeichnung war nur gedacht zur Bestimmung der Dämpfung des 
Tiefpassfilters. Werde ich noch ergänzen.

Wolfgang schrieb:
> Was verwendest du als Interruptquelle?

Am Ende der Schaltung is ein Transistor BC547B.

Wolfgang schrieb:
> Kannst du akausale Filter verwenden oder muss der geglättete Wert für
> die Drehzahl live zur Verfügung stehen?

Ich brauch die Drehzahl möglichst in Echtzeit.

Gerd E. schrieb:
> Vorschlag: nimm einen Mikrocontroller, z.B. irgendeinen kleinen STM32
> den Du grad zur Hand hast. Dort auch keine Interrupts nehmen, sondern 2
> Timer. Der eine als Referenz, hochgezählt mit dem Takt des
> Mikrocontrollers (oder einem Teiler davon), der andere zählt immer bei
> Deinen Umdrehungspulsen eins hoch. Dann alle n Events des
> Referenzzählers den Umdrehungszähler auslesen und an den Raspi senden
> (z.B. per UART).

War ursprünglich der Plan, den Arduino zu verwenden. Zusammen mit 
anderen Messdaten kommt der Wert über UART aber viel zu langsam (dürfte 
ein Windows Problem sein). Daher jetzt direkt am Raspi.

Rolf M. schrieb:
> SP90 schrieb:
>> ch glaube das kommt daher, dass man von
>> einem sehr kurzen Zeitraum in dem man die Interrupts zählt (ca. 100-150
>> ms) auf eine Minute hochrechnet.
>
> Das denke ich auch. Wenn sich dein Hauptbereich der Interrupts in so
> einem Zeitintervall im Bereich 5 bis 10 abspielt, ist das einfach eine
> zu geringe Auflösung. Das wirst du mit Filterung nur sehr begrenzt
> kompensieren können. Die Frage ist, ob du mechanisch dafür sorgen
> kannst, dass nicht nur ein Interrupt pro Umdrehung ausgelöst wird.

Ja stimmt, die Auflösung ist zu gering. Ich bekomm aber Systembedingt 
nur zwei Interrupts pro Umdrehung.

Georg schrieb:
> SP90 schrieb:
>> Ich glaube das kommt daher, dass man von
>> einem sehr kurzen Zeitraum in dem man die Interrupts zählt (ca. 100-150
>> ms) auf eine Minute hochrechnet
>
> Dann ist schon die Messung ungeeignet, da helfen Filter nicht mehr viel.
> In so einem Fall zählt man nicht Impulse, sondern misst den Abstand
> zwischen den Impulsen - also Periodendauer statt Frequqnz, das macht man
> auch bei Frequenzmessungen so. Die Periodendauer lässt sich praktisch
> beliebig genau messen, das hängt nur von der Hardware ab, während die
> Zählung von Perioden in einem festen Intervall prinzipiell beschränkt
> ist durch die Dauer des Intervalls und die Zahl der darin auftretenden
> Impulse, daran kann man nichts ändern ausser längere Intervalle zu
> nehmen.
>
> Georg

Das klingt sehr interessant. Da wären wir wieder beim Vorschlag von 
Wolfgang jedem Interrupt einen Timestamp zuzuordnen, oder? Bzw. bei der 
"reziproken Frequenzmessung"? Nur wie mach ich das programmtechnisch? Da 
müsst ich mit der Stopwatch die Zeit zwischen den Interrupts messen und 
hab dann die Zeit pro halber Umdrehung die ich dann wieder in U/min 
umrechnen kann.

Lothar M. schrieb:
>> Das Problem ist, dass die Messwerte sehr stark zappeln.
> Welche Sensorik hast du denn? Was für Werte bekommst du, wenn sich die
> Geschwindigkeit nicht ändert? Und was sagt ein Oszilloskop zum
> Sensorsignal?

Ein Transistor, der den Pegel zwischen GND und 3,3 V schaltet. Genau so 
schauts am Oszi auch aus, also das passt soweit. Auch bei konstanter 
Drehzahl hab ich das "gezapple".


Und alles zum Thema Jitter übersteigt jetz mein Verständnis leider ein 
wenig.


Vielen Dank und schöne Grüße!

SP90 schrieb:
> Bzw. bei der
> "reziproken Frequenzmessung"? Nur wie mach ich das programmtechnisch?

Ich würde bei so einer Aufgabe einen Controller programmieren, 
wahrscheinlich mit einer Interruptroutine in Assembler, insofern kann 
ich dir mit Raspbi und C nicht viel weiterhelfen. Die Aussage mit der 
reziproken Frequenzmessung bleibt aber richtig, ergänzt um die Aussage 
dass der Raspbi zur Frequenzmessung weniger geeignet ist als so ziemlich 
jeder andere Microcontroller.

Daher findet man auch wenig zum Thema, aber hier ist die letzte Antwort 
interessant:
https://forum-raspberrypi.de/forum/thread/39413-frequenzmessung-mit-dem-raspberry-pi/

Ob der Raspbi eine Funktion hat zur Messung von Periodendauern, die 
nicht von Taskwechseln beeinträchtigt wird, weiss ich nicht, anscheinend 
nicht, sonst hätte das jemand erwähnt. Die meisten empfehlen einen 
anderen Controller oder einen eigenen kleinen Controller für die 
Frequenzmessung.

Georg

Georg schrieb:
> Die meisten empfehlen einen anderen Controller oder einen eigenen kleinen
> Controller für die Frequenzmessung.

Bei so seltenen Ereignissen kommt man mit einer Frequenzmessung nicht 
weiter. Es ist besser, den Zeitabstand der Pulse zu messen und die 
Frequenz daraus zu berechnen.

SP90 schrieb:
> Und alles zum Thema Jitter übersteigt jetz mein Verständnis leider ein
> wenig.

Hausaufgabe für Dich:

Du schreibst ein kleines Test-Progrämmchen, das z.B. für 20 Sekunden 
alle Interrupts sammelt. Bei jedem Interrupt liest Du Deinen (Mess-) 
Timer aus. Der Timer läuft ungestört durch. Du stoppst ihn nicht. Du 
merkst Dir also für jeden Interrupt den Zeitpunkt. D.h. Du sammelst eine 
Liste von Zeitstempeln.

Dann misst Du für die gewünschte Zeit eine konstante Drehzahl.

Diese Zeitstempel überführst Du nun in Dein gnuplot, Matlab, Python oder 
was auch immer Du benutzt. Dazu berechnest Du zu jedem Zeitstempel die 
Differenz zum vorherigen Zeitstempel (Delta). Du bekommst natürlich eine 
Differenz weniger, als Zeitstempel vorhanden sind.

Nun plotest Du auf der X-Achse mit der Zeit, zu jedem Zeitstempel auf 
der Y-Achse das Delta (Differenz zum vorhergehenden Zeitstempel).

Das was Du nun siehst, ist der Jitter. Wäre nett, wenn Du das hier auch 
postest.

Wolfgang schrieb:
> Bei so seltenen Ereignissen kommt man mit einer Frequenzmessung nicht
> weiter

Was genau verstehst du an "reziproker Frequenzmessung" nicht?

Georg

Faulenzer schrieb:
> Nun plotest Du auf der X-Achse mit der Zeit, zu jedem Zeitstempel auf
> der Y-Achse das Delta (Differenz zum vorhergehenden Zeitstempel).

Ach Blödsinn.

Einfach auf der X-Achse für alle Zeitstempel das Delta auf der Y-Achse 
plotten. Also nicht die X-Position eines Punktes aus dem Wert des 
Zeitstempels bestimmen, sondern aus seiner laufenden Nummer.

SP90 schrieb:

> Mein Programm ist in C# programmiert und läuft als UWP auf Windows IoT
> am Raspberry.

OMG. Hier kommen zu den Unwägbarkeiten des Task-Scheduling des OS 
(generelles Problem im Userspace) ja auch noch die Unwägbarkeiten des 
temporal extrem nichtdeterministischen Backends der Mono-Runtime hinzu.

Dieses Konstrukt ist völlig unbrauchbar zur Erfassung von Messwerten im 
für dich relevanten Bereich zeitlicher Auflösung.

Zumindest in dieser Form. Du musst entweder die eigentliche Messung auf 
externe Hardware auslagern oder irgendwas von der intern verfügbaren 
Hardware des Raspi (UART oder SPI) mit deterministischem Timing 
zweckentfremdet verwenden.

Anders geht's nicht.

Georg schrieb:
> Ich würde bei so einer Aufgabe einen Controller programmieren,
> wahrscheinlich mit einer Interruptroutine in Assembler

Wozu solche Künsteleien. Eigentlich fast jeder uC besitzt Timer, mit 
denen man per Input Capture den Zeitpunkt eines Impulses erfassen kann - 
ganz ohne Software. Danach hat man alle Zeit der Welt, um das 
Timerregister auszulesen. Man muss es nur rechtzeitig vor dem nächsten 
Impuls erledigt haben.

Wolfgang schrieb:

> Wozu solche Künsteleien. Eigentlich fast jeder uC besitzt Timer, mit
> denen man per Input Capture den Zeitpunkt eines Impulses erfassen kann -
> ganz ohne Software.

Ja, nur ist halt das Target des TO ein RaspBerry Pi. Und der hat sowas 
halt leider nicht. Zumindest ist es nicht "leicht benutzbar". Ich bin 
fast sicher, dass die Hardware das könnte. Aber davon ausgesperrt zu 
sein, ist halt das Los all derer, die irgendwelche Abstraktionen der 
Hardware benutzen, sei es im Kontext eines OS-Treibers oder irgendeines 
dubiosen "Framework"s auf dem Level unterhalb eine eines richtigen OS.

Wer alles aus der Hardware herausholen will, muss 
BareMetal-Programmieren. Und wer dann auch noch alles aus der Software 
herausholen will, muss Assembler programmieren.

Es geht bei diesen beiden Ansätzen natürlich jeweils "etwas" Komfort 
verloren...

Christian F. schrieb:
> einen billigen uC

Der braucht keinen externen Zähler, der kann das gut selber.

Georg

Christian F. schrieb:
> Dann einfach bei jeder Anfrage den ic
> auslesen und die Drehzahl ausrechnen und dann die Zähler zurück setzen.

Wozu den Zähler zurück setzen?
Der ausgelesene Zählerstand ist bereits der Bezugszeitpunkt für die 
nächste Messperiode. Eine Subtraktion wird der auslesende uC doch wohl 
hin kriegen ;-)

Hallo Leute,

ich hab jetzt mal die Software umgeschrieben und das Ergebnis schaut 
schon mal gut aus :)

Vorher hatte ich in der Interrupt-Methode ja nur einen Zähler 
hochgezählt. Die Stopwatch lief im Timer der GUI. Die hat eigentlich nur 
die Zeit der Timer-Ticks gestoppt, in denen die gezählten Interrupts 
ausgeweret wurden. Jetz konnte es aber sein, dass während eines Ticks 
genau 5 Interrupts gezählt wurden oder mann schon kurz vorm sechsten 
war. In beiden Fällen aber immer nur 5 Interrupts, aber mit 
unerschiedlichen Zeiten. Das war der Fehler. So hat man quasi bis fast 
einem Interrupt unterschied und das war genau das gezapple um die ca. 
200 U/min.

Jetzt läuft die Stopwatch in der Interrupt-Methode und wird mit jedem 
Interrupt neu gestartet. Also die Dauer seit dem letzten Interrupt wird 
gemessen und aufsummiert wie die Interrupts selbst. Das Ergebnis hab ich 
angefügt. Mit einem leichten Tiefpass schaut das schon mal gut aus, 
obwohl ich noch weitere Test machen muss. Bei den Interrupts scheint es 
manchmal ausreßende Spitzen zu geben, aber das muss von der Hardware 
kommen.

Sicherlich stimmt das was ihr über die Fähigkeiten der Hardware und des 
Betriebssystems schreibt, aber erstmal scheint die Messung genau genug.

Ich werd mich aber doch noch mit den anderen Filtern beschäftigen. Die 
sind durchaus interessant können auch nochmal nützlich sein...

LG

Ich musste oft stark streuende Sensordaten auswerten und die dahinter 
liegenden Zusammenhänge herausfinden. "Fertige" Filterlösungen haben den 
Nachteil, dass sie zwar universell anwendbar sind, aber selten zu der 
aktuellen Aufgabe passen. Als erster Ansatz hat sich bei mir folgende 
Vorgehensweise bewährt:
Ich habe die Messwerte in eine Excel-Tabelle geladen.
Dann habe ich den Mittelwert der Messwerte gebilet.
Weil aber schon ein stark verfälschter Messwert den Mittelwert 
verschiebt, habe ich dann die Streubreite der Messwerte berechnen 
lassen.
Dann habe ich alle die Messwerte, die mehr als die Streubreite vom 
Mittelwert entfernt waren, unberücksichtigt gelassen und den Mittelwert 
der restlichen Messwerte gebildet.
Mit dem Unterschied zwischen den beiden Mittelwerten und der 
Information, wie die Messwerte, die für den zweiten Mittelwert 
unberücksichtigt blieben, habe ich dann das weitere Vorgehen überlegt. 
Interessant ist beispielsweise, ob die unberücksichtigen Messwerte 
verstreut lagen, oder ob sie dicht beieinander lagen. Dann war es 
nämlich keine Messunsicherheit, sondern die Abweichung musste einen 
Grund haben, der irgendwann auftrat und danach wieder verschwunden ist.
Kein Tool kann eigenes Denken und Verständnis ersetzen.

SP90 schrieb:
> Bei den Interrupts scheint es
> manchmal ausreßende Spitzen zu geben

Klar, weil der Rasbpi bzw. sein Betriebssystem ja nicht echtzeitfähig 
ist. Da müsste man nicht einfach filtern, sondern intelligent 
klassifizieren, wenn wie zu vermuten die meistem Messungen eng 
beieinander liegen und einzelne weit davon weg, weil das System 
dazwischen spuckt. Da könnte z.B. eine 3Sigma-Filterung helfen, die weit 
abweichende Werte eliminiert.

Georg

Georg schrieb:
> Klar, weil der Rasbpi bzw. sein Betriebssystem ja nicht echtzeitfähig
> ist. Da müsste man nicht einfach filtern, sondern intelligent
> klassifizieren, wenn wie zu vermuten die meistem Messungen eng
> beieinander liegen und einzelne weit davon weg, weil das System
> dazwischen spuckt. Da könnte z.B. eine 3Sigma-Filterung helfen, die weit
> abweichende Werte eliminiert.

Genau so etwas habe ich ja vorgeschlagen, aber nicht einfach nur nach 3 
Sigma oder so gefiltert, sondern die Filterung angepasst und vorher 
einzelne "Ausreißer" herausgenommen, da diese die Filterungsergebnisse 
schlechter machen.
Die Streubreite ist übrigens ein "Gütekriterium". Wenn man an der 
Abtastung Änderungen vornimmt, kann man an der Streubreite deren 
Wirksamkeit beurteilen. Und durch Anpassung des Schwellenwertes 
(Abweichung der einzelnen Messwerte vom ersten groben Mittelwert) kann 
man die Vorsiebung schwächer oder stärker machen - je nach Bedarf.

Rolf M. schrieb:
> Läuft da denn ein RT-PREEMPT-Kernel?

Das Prinzip, erstmal lesen was schon alles gesagt wurde, ist wohl aus 
der Mode, wie? Statt dessen einfach mal in der Gegend rumquaken...

Christian F. schrieb:
> Hast recht. Wobei der irgendwann überläuft.
>
> Georg schrieb:
>> Der braucht keinen externen Zähler, der kann das gut selber.
>
> Der externe Zähler hat den Vorteil dass der nie unterbrochen wird und
> von Vorgängen im uC nicht abhängig ist.

Das ist nicht böse gemeint: Ich nehme an, Du hast selber noch nie einen 
fortlaufenden Zähler verwendet. Das ist OK. Falls doch, solltest Du 
Deine Ansichten nochmal durchdenken, zur Not hier fragen.

SP90 schrieb:
> Mein Programm ist in C# programmiert und läuft als UWP auf Windows IoT
> am Raspberry.

Rolf M. schrieb:
> Warum sind hier in letzter Zeit eigentlich so viele Trolle unterwegs,
> die einfach nur andere beschimpfen, ohne selbst überhaupt irgendwas zur
> Diskussion beizutragen? Ist den Kids in der Ferienzeit so langweilig?

Am 11.8. hat "SP90" klargestellt, dass er Windows auf dem RPi verwendet.

Und Du kommst 4 Tage später mit dem Linux-Kernel an?

Preis-Frage: Was nützt das "SP90"

  --> Gar nichts!

Zweite Preis-Frage: Wer ist der Troll der neben seinen Stiefeln läuft?

  --> Du!

Rolf M. schrieb:
> Warum du
> deshalb so aggressiv auftrittst und beleidigend wirst

Sorry. War ein hässlicher Zug von mir. Tut mir leid.