Gleitender Mittelwert Arduino

[HaWe]

ja, Ringpuffer ist natürlich perfekt und auch perfekt auf die Stichprobengröße angepasst.

Angenähert geht es aber auch mit dem gleitenden Mittelwert per Lowpass-Filter, damit bekommt man bis auf ein paar unerhebliche Nachkommastellen das gleiche Ergebnis:

float ETA=0.95; // ETA anfangs festlegen, ggf. noch justieren, kann auch bei 0.90 oder 0.99 liegen=> rumprobieren!
Mittelwert = ETA*(Messwert) + (1-ETA)*Mittelwert;

Dann spart man sich die extrem langsamen Array-Operationen und den Speicher dafür. Allerdings sind es dann nicht exakt 255 Werte, die gemittelt werden, sondern nur größenordnungsmäßig was in der Art.
Aber:
man kann ja auch die obige Formel benutzen, und dabei bis 255 zählen,
dann den Mittelwert ablesen,
und dann wieder neu starten.
Aber: er gleitet, mit minimalem Aufwand.

[Klebwax]

Die Frage ist, was man wirklich machen will. Meist geht es darum, ein verrauschtes Signal etwas zu glätten. In HW würde man da einen Tiefpass einsetzen. Irgendwie hat sich aber die Meinung verbreitet, ein gleitender Mittelwert wäre ein Tiefpass. Mir fiel bei einem Thread auf Mikrocontroller.net auf, das jemand den gleitenden Mittelwert als Kerbfilter für 50Hz Störungen einsetzt. Das ist dann sicher kein Tiefpass. An anderer Stelle hat dann der User Yalu X. aus ebendiesem Forum den Frequenzgang eines gleitenden Mittelwertes, nennt man wohl auch FIR Filter, zusammen mit dem Frequenzgang eines Tiefpasses, ein IIR Filter, geplottet. Hier das Bild:


Die rote Kurve ist der aus der Analogtechnik gut bekannte Tiefpass, die grüne der gleitende Mittelwert. Man erkennt dort deutlich das Kerbfilter zusammen mit einem Tiefpass.

Der gleitende Mittelwert hat auf jeden Fall zwei Nachteile: er kostet viel mehr Prozessorresourcesn, Speicher sowie Rechenzeit, und er verursacht, hier nicht dargestellt, Phasensprünge im Signal. Wenn man also das Kerbfilters nicht braucht, und das macht nur Sinn, wenn man die Abtastrate und Buffergröße genau an das Störsignal fester Frequenz anpasst, ist ein einfacher Tiefpass besser.

Die Rechnung eines Tiefpasses ist einfach, hier etwas Pseudocode:

Output = Oldvalue * n + Newvalue * (1 - n) // wobei n < 1
Oldvalue = Output

In Integerrechnung für n = 0,5 gehts noch einfacher

Output = (Oldvalue + Newvalue) / 2 // kann auch ein shift right werden
Oldvalue = Output

n zusammen mit der Abtastrate gibt die Grenzfrequenz des Tiefpasses an. Man muß bei der Integerrechnung nur darauf achten, daß beim Teilen nicht unten zuviele Bits verloren gehen. Man sollte also die Messwerte vorher nach oben im Bereich des Integers verschieben. Diese einfache Rechnung kann man leicht z.B. in der Auslesefunktion des ADC unterbringen.

MfG Klebwax

[Peter(TOO)]

Hallo Klebwax,

n zusammen mit der Abtastrate gibt die Grenzfrequenz des Tiefpasses an. Man muß bei der Integerrechnung nur darauf achten, daß beim Teilen nicht unten zuviele Bits verloren gehen. Man sollte also die Messwerte vorher nach oben im Bereich des Integers verschieben. Diese einfache Rechnung kann man leicht z.B. in der Auslesefunktion des ADC unterbringen.

Ich habe oft einige Zeit aufgewendet um FP-Operationen aus meinen Projekten zu eliminieren.
Spart einiges an Speicher (weil die FP-Bibliothek nicht eingebunden werden muss) und viel Rechenzeit.

Da hatten sich einige Kunden gewundert, weil alle anderen Entwickler meinten, dies wäre nur mit neuer Hardware zu machen.

Zum Skalieren/Abgleichen von analogen Eingängen habe ich meistens mit Brüchen gearbeitet, also
(x * k1) / k2;
Aufpassen muss nur, dass man bei der Multiplikation mit k1 keinen Überlauf bekommt, aber mit den richtigen Werten für k1 und k2 bekommt man die krümmsten Faktoren hin. Intern habe ich dann z.B. mit 1/100 Grad gerechnet, dann braucht man auch keine Komma-Zahlen. Das Komma gabs dann nur bei der Ausgabe und da ist es nur Zeichenmanipulation.

Wie schon gesagt wurde, muss man etwas mit den Wertbereichen aufpassen, damit man auf keinen Fall Under-/Overflows erzeugt. Aber auch FP hat da ihre Tücken!

Da hatten ja auch die Amis mit ihren Patriot-Raketen Probleme.
Da wurde die Zeit als FP mit einfacher Genauigkeit verarbeitet, das sind um die 7 Stellen. Gibt man die Zeit in Sekunden an, geht das so 115 Tage gut, dann hat die Zeit keine Auflösung von 1 Sekunde mehr.

float zeit = 0.0;

while (-1) zeit = zeit + 1.0;

Hier erreicht zeit einen endlichen Wert und verändert sich dann nicht mehr. Die Laufzeitbibliothek erzeugt hier dann aber auch keinen Fehler-Trap

Weitere Probleme ergeben sich bei der Konvertierung, endliche Dezimalbrüche ergeben teilweise unendliche FP-Werte, werden also zwangsweise gerundet.

Rundungsfehler können bei Buchhaltungsprogrammen Probleme verursachen, die Bilanz geht dann nicht wirklich auf.
Unter CP/M gab es den CBASIC-Compiler, dieser hat intern mit 14-Digits BCD gerechnet. War etwas langsamer als andere BASIC, auch weil es P-Code erzeugt hat. Aber bis 999'999'999'999.99 (999 Mrd.) rechnet dies also noch auf den Cent genau. Damit kann dann auch Billy sein Vermögen auf den Cent genau verwalten

Bis Anfang der 80er Jahre habe ich alle technischen Berechnungen mit CBASIC gemacht.


Und wie du schon geschrieben hast, zusammen mit Abtastraten, ergeben sich dann die lustigsten Frequenzgänge!

Wenn man ein 50Hz-Signal alle 20ms abtastet, erhält man eine konstante Spannung, welche proportional zur Phasenverschiebung der beiden Frequenzen ist. Nicht unbedingt das was man wollte

Wenn man nicht genau aufpasst, kann es mit dem gleitenden Mittelwert sogar schlechter werden.
Bei deinem Diagramm liegt der -6dB-Punkt (analoger Tiefpass) bei etwa 2.25kHz. Der gleitende Mittelwert unterdrückt diese Frequenz aber fast gänzlich.

MfG Peter(TOO)

[HaWe]

was redet ihr denn von Abtastfrequenz?
wieso Abtastfrequenz?
wir reden doch hier nicht von einem ADC-Abtaster mit RC-Glied wie in der Audio-Technik!
Ein Tiefpassfilter in der Statistik ist ein Rauschunterdrückungsfilter, genau wie ein arithmetisches Mittel, ein Median, oder ein Kalmanfilter, da geht es nicht um Abtastfrequenz sondern Trägheit, wodurch der Filter automatisch neu hereinkommende Werte mehr oder weniger "glättet", um Sensorrauschen zu minimieren, genau wie es auch andere Filter tun. Und die Werte werden 1:1 genau dann verarbeitet, wenn sie "hereinkommen".

Schmeißt doch hier nicht alles durcheinander, da wird man ja ganz wirr!
Der Tiefpassfilter hat gegenüber dem arithmetischen Mittel nur eben den Vorteil, dass er von ganz alleine gleitet und man keine Riesen-Arrays verwalten muss.

[HaWe]

oh nein Witkatz, da hast du was falsch verstanden:
"Durchschnitt" oder "Mittelwert" sind keine Synonyme für "arithmetisches Mittel".
Auch ein Median liefert einen Mittelwert oder Durchschnittswert, und auch ein Kalmanfilter und ein Tiefpassfilter (oder auch ein Hochpassfilter) tun das.
Der Grund, dass man Mittel- oder Durchschnittswerte verwendet, liegt in statistischen Fehlern und den Streuungen der Einzelmessungen begründet, die normalverteilt oder auch nicht-normalverteilt sein können. Dementsprechend werden bestimmte Mittelwertverfahren im einen oder anderen Fall bevorzugt angewendet, um den/die wahren Zustandswert(e) im Messraum (die man nicht kennt) möglichst gut anzunähern.
Für Stichproben mit ganz wenigen aber extremen Ausreißern ist z.B. ein Medianfilter besser geeignet als ein arithmetisches Mittel, das arithmetische Mittel wiederum ist besser für normalverteilte Messwert-Stichproben geeignet.