Datenpunkte bei Oversampling verwerfen

#4147044
Lesenswert?

Hallo,

ich habe eine Regelung, die die Höhe eines Fühlers konstant über einem 
zu messenden Untergrund hält.
Die Höhe des Fühlers wird zur Datenanalyse herangezogen.
Nun ist es so, dass das System mit 50kHz abtastet und danach regelt. 
Mich interessieren aber nur bis zu 1000 Punkte pro Sekunde.
Nehme ich dann nur jeden 50. Punkt oder mittle ich über die 50 Punkte? 
Oder gewichte ich beim Mitteln der Punkte sogar noch mit dem Fehler oder 
der Position (Also dass beim Mitteln über 50 Punkte der 25. am meisten 
zählt, da dieser eben auch der angezeigten Position entspricht. Nicht 
dass zwei angezeigte Datenpunkte  hauptsächlich durch zwei nebeneinander 
gesamplete Datenpunkte entstehen, und ich danach eine Lücke von im 
schlimmsten Fall 100 gesampleten Datenpunkte habe)
#4147263
Lesenswert?

Hier noch ein kleiner Artikel (ja es ist Wikipedia, aber nicht schlecht 
erklärt):
http://en.wikipedia.org/wiki/Decimation_%28signal_processing%29#By_an_integer_factor

oder hier

http://dspguru.com/dsp/faqs/multirate/decimation

Wichtig ist der Part des Anti Alias Filters. Wenn du den als FIR 
auslegst, sparst du drastisch Rechenzeit, weil nur jeden n-ten Wert 
berechnen musst.

Einen (gleitenden) Mittelwert zu bilden IST eine Art der Filterung, 
nämlich ein einfaches FIR filter mit N gleichen Koeffizienten. Der hat 
aber nunmal keine so tolle Spektrale Eigenschaften. Wenn dir das das 
reicht, nimm das Filter. Wenn nicht ein etwas komplizierteres ;-)
#4155059
Lesenswert?

> Dafür muss aber dennoch jeder Wert in den FIR-Filter.
Genauso wie beim IIR-Filter. Da sehe ich keinen Unterschied. Aber beim 
IIR Filter müssen immer alle Werte berechnet werden, beim FIR Filter 
hingegen nicht.

Daher denke ich, dass man bei diesem Vergleich auch die Filterordnung 
und die Dezimationsrate berücksichtigen muss.

Aber davon abgesehen, denke ich das eine optimierte Version eines 
gleitenden Mittelwertes hie gut funktionieren würde. Die braucht 
unabhängig von der Länge immer eine Addition, eine Subtraktion und eine 
Division. Das ist mit Sicherheit weniger Rechenaufwand als bei allen 
anderen Filtern.
Gast #4155417
Lesenswert?

Manfred M. schrieb:
> Aber davon abgesehen, denke ich das eine optimierte Version eines
> gleitenden Mittelwertes hie gut funktionieren würde. Die braucht
> unabhängig von der Länge immer eine Addition, eine Subtraktion und eine
> Division. Das ist mit Sicherheit weniger Rechenaufwand als bei allen
> anderen Filtern.

Formal wird er dadurch wieder zum IIR. Du koppelst ja dann zurück ;-)
Aber ich nutze den optimierten gleitenden Mittelwert auch oft. Braucht 
je nach Plattform nur ein paar Takte.
Und wenn man 2er Potenzen verwendet ist die Division auch nur noch ein 
Shift.
#4156089
Lesenswert?

> <korinthen-kack-modus=on> ... off>
Das ist ein Punkt, der mich als DSP Einsteiger bereits verwirrt hat. Oft 
wird in der Literatur bereits die Wiederverwendung eines bereits 
berechneten Wertes (hier die Gesamtsumme) als Rekursion bezeichnet. Mein 
Verdacht ist, das allein wegen dieses Sachverhaltes einfache Gleitende 
Mittelwertfilter (SMA) oft als IIR eingestuft werden. Frage: ist dass 
das selbe, was in der englischen Literatur als "recursive running sum" 
bezeichnet wird?

Aber wir sind uns einig, das die Impulsantwort nicht länger als die 
Anzahl der Taps, und damit endlich ist. Das ergibt sich aus der 
Tatsache, das der wiederverwendete Wert nicht wieder an den Eingang 
gelangt.
Gast #4156275
Lesenswert?

Moin,

Manfred M. schrieb:
> Oft
> wird in der Literatur bereits die Wiederverwendung eines bereits
> berechneten Wertes (hier die Gesamtsumme) als Rekursion bezeichnet.

Da bin ich dabei, das kann man ruhig so machen.

Manfred M. schrieb:
> Mein
> Verdacht ist, das allein wegen dieses Sachverhaltes einfache Gleitende
> Mittelwertfilter (SMA) oft als IIR eingestuft werden.

Da wirds problematisch. Dieses gleitende Mittelwertfilter ist halt so 
ein bisschen ein Sonderfall. Es besteht aus einem Differenzierer
 und einem Integrator
Der Differenzierer ist ganz klar nicht rekursiv und ganz klar FIR. Der 
Integrator ist aber rekursiv und auch IIR. Nur in der Kettenschaltung 
entsteht aus dem Dingens ganz klar wieder was mit FIR.

Das gleitende Mittelwertfilter geht so in Richtung Hogenauers CIC 
Filter. Nur halt noch nicht kaskadiert. Aber von der urspruenglichen 
Anwendung in diesem Thread (Dezimation) schon passend. Bei den CIC 
Filtern haben anfangs auch viele gedacht, der Integrator wuerde 
Stabilitaetsprobleme verursachen. Tut er aber nicht...

Gruss
WK
#4158430
Lesenswert?

> Hat doch keinen Energiespeicher (?)
Ich denke doch, zumindest hat es eine echte Rückkopplung. Bei meinem 
ersten Versuch mich in CIC Filter einzuarbeiten, hatte mir der folgende 
Artikel sehr geholfen: 
http://www.embedded.com/design/configurable-systems/4006446/Understanding-cascaded-integrator-comb-filters
(hier Figure 5 und zugehöriger Text). Das hat mir sehr geholfen, CIC 
Filter in meinem Testprogramm zu realisieren. Dabei musste ich einsehen, 
das diese Filter auch mit "double precision" nicht immer stabil 
arbeiten, was wohl auf Rundungsfehler zurückzuführen ist. Mit Integer 
Arithmetik funktioniert es aber, wobei je nach Filter Ordnung ggf. auch 
64 Bit Integer nötig sind.

Aber, um auf die ursprüngliche Frage zurückzukommen, denke ich, dass man 
erstmal klären muss, wie schnell sich die analogen Eingangsdaten 
überhaupt ändern können. Wenn das schneller ist als 1/50 der 
Abtastfrequenz muss man filtern, ansonsten reicht abzählen.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren