Forum: FPGA, VHDL & Co. Gleitender Mittelwert rauscht


von Stephan K. (Firma: FAU Erlangen) (sofa1780)



Lesenswert?

Hallo alle,

ich habe, um ein Signal über mehrere Prioden Filtern zu können einen 
Mittelwertfilter beschrieben, welcher jedoch zu stark verrauschten 
Signalen führt.

In der Simulation mit ModelSim war dies noch nicht der Fall und alles 
hat einwandfrei funktioniert, wie in dem Simulationsergebnis zu sehen. 
Hier hatte ich über 4 Perioden einer Sinusschwingung gemittelt.
Phasen- und Amplitudenweite waren dabei auf jeweils 6 Bit bei 50 MHz 
Abtastrate gesetzt um die Simulationsdauer in Grenzen zu halten.

An der Realen Hardware arbeite ich mit einer Amplitude von 14 Bit und 
einer Phase von 12 Bit für die Shift register (14 * 4096 an der Zahl), 
da ich ein 70 kHZ Signal bei einer Abtastung von 50 MHz über mind. 5 
Perioden mitteln möchte.
Folgender Rechenweg wurde hierzu genutzt:

Hat jemand von euch eine Idee, weshalb nun das reale Signal soo 
verrauscht ist?

Der Eingang des verwendeten DA-Wandlars kann max. 2 V Spannnung 
aufnehmen,
der Ausgang des verwendeten AD-Wandlers hingegnen nur max. 1 V Spannung 
ausgeben.

Lieben Danke schonmal im Vorraus

: Bearbeitet durch User
von Trompet (Gast)


Lesenswert?

Es könnten HF-Einkopplungen sein, deren Ursache vielleicht ein oder 
mehrere DC/DC-WAndler sind. Wie sieht den Deine Mess-Schaltung (incl. 
Leiterbahnführungen, auch die der Masse) aus?

von Stephan K. (Firma: FAU Erlangen) (sofa1780)


Lesenswert?

Trompet schrieb:
> Es könnten HF-Einkopplungen sein

Bin ich mir nicht ganz sicher, ich habe die Ein- und Ausgangssignale vom 
AD-Wandler über die vorhandenen Schalter am Entwiklerboard zugewiesen, 
sodass ich whalweise Eingang, bzw. Ausgang A oder B verwenden kann. 
Schalte ich die Schalter alle aus wird der letzte Wert in einem Latch 
gehalten und es ist kein rauschen mehr zu erkennen. Gemessen wird vom 
Oszi folglich störungsfrei.

Trompet schrieb:
> Wie sieht den Deine Mess-Schaltung

Der Messaufbau sieht wie folgt aus:
Entwicklerboard sowie Oszi hängen an der selben Steckerleiste, beziehen 
also die selbe Masse.
Das Oszi wird als Signalgenerator sowie als Messinstrument genutzt.
So wird das Signal also in den AD-Wandlar eingespeist und am DA-Wandler, 
durch den FPGA verarbeitet, wieder erfasst.

von Achim S. (Gast)


Lesenswert?

du bildest alle 20ns die volle Summe über 255 Messwerte mit jeweils 14 
Bit Datenbreite? Hast du dir schon mal die Implementierung im FPGA 
angeschaut? Versucht das wirklich, eine Summation über 255 Werte zu 
bilden, bei der sich in jedem Takt alle Werte ändern? Hast du eine 
Timing-Info, wie schnell diese Monstersumme berechnet wird?

Mein Vorschlag für deine aktuelle Implementierung: speicher den 
Ausgabewert in einem Register, das mit clk getaktet wird. Setze dann ein 
constraint auf die Taktrate und schaue nach, ob die Berechnung innerhalb 
von 20ns durchgeführt wird.

Mein Vorschlag für die generelle Implementierung: für ein moving average 
Filter braucht man nicht in jedem Takt alle 255 Daten zu addieren. Es 
reicht, den jeweils neuen Wert zu bisherigen Summe dazuzuzählen und den 
um 255 Takte verschobenen Wert von der bisherigen Summe abzuziehen. Das 
ist sehr viel weniger Rechenaufwand.

Ich weiß es nicht: vielleicht erkennt dein Synthesetool ja auch, was du 
vorhast, und setzt es ohnehin so um. Deshalb lohnt sich ein Blick, wie 
die Komponente implementiert wurde.

von Stephan K. (Firma: FAU Erlangen) (sofa1780)


Angehängte Dateien:

Lesenswert?

Achim S. schrieb:
> du bildest alle 20ns die volle Summe

So ist es derzeit.

Achim S. schrieb:
> schon mal die Implementierung im FPGA angeschaut?

Dort wird es entsprechend der Beschreibung mittels Shiftregistern 
realisiert. Jeder neue Wert wird entsprechend in dem Register gehalten 
und von dort aus simultan berechnet.

Wie lange diese Berechnugn dauert weiß ich allerdings nicht.
Ich weiß noch nicht wie ich diese Timing analysen genau mache.
Im TimeQuest Timing Analyzer Script habe ich bisher nur die Clocks 
berücksichtigt. Was müsste ich für das constraint hier noch eingeben um 
die Berechnugnszeit der Summe zu ermitteln?
Ein und Ausgang der Summe?

von Achim S. (Gast)


Lesenswert?

Stephan K. schrieb:
> So wird das Signal also in den AD-Wandlar eingespeist und am DA-Wandler,
> durch den FPGA verarbeitet, wieder erfasst.

Ok: was ist das für ein DA-Wandler? Arbeitet der mit einem Takt? (davon 
gehe ich mal aus) Schalten die Ausgänge deines Mittelwerts vom Timing 
her so, dass der DA die richtigen Werte übernimmt (und nicht mitten in 
den Schaltflanken Werte einliest)?

Die Fragen gehen in die selbe Richtung wie mein Kommentar weiter oben: 
hast du das Timing deiner Signalberechnung im Griff. Der richtige Ansatz 
dafür wären entsprechende timing-constraints. Einen ersten Eindruck 
kannst dir aber auch mit dem Oszi verschaffen: triggere auf den Takt des 
DAC. Und dann nimm mit einem zweiten Kanal einen niederwertigen 
Dateneingang des DAC auf und schau, ob du auf dem Datenbit ein 
vernünftiges Datenauge siehst, das korrekt zur Taktflanke positioniert 
ist.

Stephan K. schrieb:
> So ist es derzeit.

Du berechnest damit 255 Additionen wo eigentlich nur eine Addition und 
eine Subtraktion nötig wären.

Stephan K. schrieb:
> Was müsste ich für das constraint hier noch eingeben um
> die Berechnugnszeit der Summe zu ermitteln?

Du musst den Ausgang ebenfalls in ein getaktetes Register packen. Dann 
kann die Software bestimmen, ob das Rechenergebnis rechtzeitig vor der 
nächsten Taktflanke vorliegt.

Des weiteren musst du dann noch sicherstellen, dass das Timing bei der 
Ansteuerung des DAC passt. Aber machen wir erst mal den ersten Schritt 
bevor wir zum zweiten kommen.

von Stephan K. (Firma: FAU Erlangen) (sofa1780)


Angehängte Dateien:

Lesenswert?

Achim S. schrieb:
> was ist das für ein DA-Wandler?

Das ist ein umgelöteter THDB_ADA von Terrasic, bei dem koppelung der 
Signale nun als Single-Ended-konfiguration realisiert ist.
Dabei werden die Werte bei jeder steigenden Clockflanke mit 50 MHz 
übernommen. Die Taktung folgt dabei vom FPGA aus.

Die Werte des Mittelwertfilters sind dabei einsynchronisiert.


Die timing-constraints zwische den Registern zur einsynchronisierung vor 
und nach dem Mittelwertfilter habe ich nun wie folgt gesetzt.

set_net_delay -max 20.000 -from .. -to ..

Fehlermeldungen bei der Synthese bekomme ich hier bei nicht.

Achim S. schrieb:
> eigentlich nur eine Addition und eine Subtraktion nötig wären.
Ich habe es nun soweit geändert und siehe da, statt 77% von 114k LE's 
wird nun nur noch 1% benötigt.. Danke schonmal dafür. Auf die Idee war 
ich einfach nicht gekommen, wohlwissend, dass ein gleitender 
Durchschnitt auch so berechnet werden kann.


Muss also nun nurnoch das Timing des DAC überprüft werden.


Ich habe es grade mal synthetisiert und es klappt auf anhieb.

Meine Schlussfolgerung, es lag an dem Timing der riesigen Berechnung.
14*(2^12) Register waren schließlich über ein und die selber Clock 
angesteuert worden.

Liege ich damit richtig?
Um das Problem nun auch verstanden zu haben.

Besten Dank aber schon einmal!! :)

: Bearbeitet durch User
von Achim S. (Gast)


Lesenswert?

Stephan K. schrieb:
> Liege ich damit richtig?

Ich denke schon. Am Timing der Berechnung und/oder am Timing der 
Interfacesignale zum FPGA.

von Achim S. (Gast)


Lesenswert?

Achim S. schrieb:
> Am Timing der Berechnung und/oder am Timing der
> Interfacesignale zum FPGA.

Ach, das sollte natürlich heißen "der Interfacesignale zum DAC"

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Stephan K. schrieb:
> Meine Schlussfolgerung, es lag an dem Timing der riesigen Berechnung.
Das hätte dir die Toolchain aber melden können, wenn du noch einen Satz 
Register vor den Ausgang gesetzt (also o_data registriert/getaktet) und 
die gewünschte Taktfrequenz als Constraint angegeben hättest. Denn dann 
wäre ihr klar geworden, dass die Summe nicht rechtzeitig vor der 
nächsten Taktflanke berechnet werden kann...

: Bearbeitet durch Moderator
von Edi M. (Gast)


Lesenswert?

Wäre das nicht auch Bestandteil des Lerninhaltes an der Universität 
Erlangen, die Erzeugerwerkzeuge der FPGAs so einzustellen, dass sie das 
erkennen? So langsam verstehe Ich, warum die Siemens dort keine 
Absolventen von der FAU einstellt, sondern ständig nach Externen 
schielt, die ihnen helfen, hehe - (a wen'g a Spässle g'macht :-) )

Andere Anregung: Man überlege, ob ein gleitender Mittelwirt wirklich die 
richtige Herangehensweise beim Entrauschen sein kann.

von Stephan K. (Firma: FAU Erlangen) (sofa1780)


Lesenswert?

Lothar M. schrieb:
> Das hätte dir die Toolchain aber melden können

Wenn die Register zum einsynchronisieren schon dagewesen wären sicher.


Meister Eduard schrieb:
> Wäre das nicht auch Bestandteil des Lerninhaltes an der Universität
Erlangen

Das hoffe ich doch für die E-Techniker und Mechatroniker sehr, in meinem 
Maschinenbaustudium war der Schwerpunkt jedoch ein anderer.,

Zur Signalglättung gibt es sicher noch einige andere Filter, die zur 
entrauschung herangezogen werden können. Sind jedoch nicht 
Kernbestandteil meiner Arbeit. Allerhöchst einen FIR-Filter, diesen habe 
ich auch betrachtet, braucht allerdings wesentlich länger zum Rechnen da 
ähnlich wie anfangs beim gleitenden Mittelwert alle 20 ns ein neues 
Ergebnis berechnet wird.

: Bearbeitet durch User
Beitrag #5135716 wurde von einem Moderator gelöscht.
von Edi M. (Gast)


Lesenswert?

Stephan K. schrieb:
> Das hoffe ich doch für die E-Techniker und Mechatroniker sehr, in meinem
> Maschinenbaustudium war der Schwerpunkt jedoch ein anderer.,

Da hast Du aber Schwinungsgleichungen und die sind eigentlich noch 
komplizierter, wenigstens, wenn man sie als Filter auslegen möchte.

von Weltbester FPGA-Pongo (Gast)


Lesenswert?

Gleitende Mittelwerte sind naturgenäß rauschempfindlich, da ist nichts 
zu ändern. Entweder einen richtigen FIR oder einen IIR-Tiefpass.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Weltbester FPGA-Pongo schrieb im Beitrag #5169559:
> Gleitende Mittelwerte sind naturgenäß rauschempfindlich, da ist nichts
> zu ändern.
Du hast jetzt aber den Thread nicht wirklich durchgelesen?
Ein gleitender Mittelwert ist die einfachste Form eines FIR-Tiefpasses. 
Wie stark er auf Rauschen im Eingangssignal reagiert ist eine Frage der 
Filterlänge.
https://de.wikipedia.org/wiki/Gleitender_Mittelwert

von Pandur S. (jetztnicht)


Lesenswert?

War sicher sehr lehrreich : wie verballere ich moeglich viel Leistung in 
wenig. Ein Tiefpass, resp exponentieller Average waer viel einfacher, 
und gewiss besser.
http://www.ibrtses.com/embedded/exponential.html
Ist eigentlich wie gemacht fuer ein FPGA. Mit einer einzigen 
Speicherstelle.

: Bearbeitet durch User
von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Sapperlot W. schrieb:
> wie verballere ich moeglich viel Leistung in wenig.
> Ein Tiefpass, resp exponentieller Average waer viel einfacher, und
> gewiss besser.
Oder wenn es schon ein gleitender Mittelwert sein muss, dann werden 
die Daten in einem Rinpuffer gespeichert und vom Summenspeicher einfach 
der älteste Wert abgezogen und der neueste draufaddiert. Damit spart man 
sich im Filter hier im Thread nämlich c_shift_range-2 Addierer. Und 
spart natürlich gewaltig an Durchlaufzeit...

von Klaus (Gast)


Angehängte Dateien:

Lesenswert?

Hier im Forum wird oft über einen gleitenden Mittelwert zur Glättung von 
Signalen gesprochen. Der Frequenzgang eines solchen Mittelwerts ist an 
anderer Stelle mal gezeigt worden

Yalu X. schrieb:
> So sieht der Frequenzgang eines Gleitenden-Mittelwert-Tiefpasses
> im
> Vergleich zu einem RC-Tiefpass 1. Ordnung (bzw. einem IIR-Tiefpass 1.
> Ordnung oder einem PT1-Glied in der Regelungstechnik) bei gleicher
> 3dB-Grenzfrequenz (1 kHz) aus.

Ich hab das Bild mal mit hochgeladen.

Lothar M. schrieb:
> Oder wenn es schon ein gleitender Mittelwert sein muss

Solange der TO nicht erwähnt, daß er die Notch- bzw Kammfilterfunktion 
eines gleitenden Mittelwertes wirklich braucht, gehe ich davon aus, daß 
eigentlich ein Tiefpass gemeint ist, der TO also eigentlich die ganze 
Sache nicht verstanden hat sondern nur irgendwas nachplappert.

Sapperlot W. schrieb:
> War sicher sehr lehrreich : wie verballere ich moeglich viel Leistung in
> wenig. Ein Tiefpass, resp exponentieller Average waer viel einfacher,
> und gewiss besser.

Tiefpass klingt aber nicht so "schlau" wie gleitender Mittelwert, Kalman 
Filter würde aber noch "schlauer" klingen.

MfG Klaus

von Gustl B. (-gb-)


Lesenswert?

Gleitender Mittelwert ist auch ein FIR Tiefpass. Und er ist extrem 
einfach zu beschreiben und brauch sehr wenig Logik im FPGA.

Will sagen: Wenn man einen Tiefpass haben will und ein gleitender 
Mittelwert gut genug ist, dann spricht da nichts dagegen.

von Klaus (Gast)


Lesenswert?

Gustl B. schrieb:
> Gleitender Mittelwert ist auch ein FIR Tiefpass. Und er ist extrem
> einfach zu beschreiben und brauch sehr wenig Logik im FPGA.
>
> Will sagen: Wenn man einen Tiefpass haben will und ein gleitender
> Mittelwert gut genug ist, dann spricht da nichts dagegen.

Das ist nun beliebig falsch. Ein Tiefpass benötigt nur einen 
Speicherplatz (in Worten einen Buffer der Länge 1), eine Addition und 
ein Rightshift pro Durchlauf. Das nenne ich extrem einfach, da braucht 
man noch nicht mal ein FPGA, das kann man sogar mit ein paar TTL 
Bausteinen diskret aufbauen. Der gleitende Mittelwert braucht einen 
Buffer mit vielen Werten etc. Wie schon gesagt

Sapperlot W. schrieb:
> War sicher sehr lehrreich : wie verballere ich moeglich viel Leistung in
> wenig. Ein Tiefpass, resp exponentieller Average waer viel einfacher,
> und gewiss besser.
> http://www.ibrtses.com/embedded/exponential.html
> Ist eigentlich wie gemacht fuer ein FPGA. Mit einer einzigen
> Speicherstelle.

MfG Klaus

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

Klaus schrieb:
> Ein Tiefpass benötigt nur einen Speicherplatz (in Worten einen Buffer
> der Länge 1), eine Addition und ein Rightshift pro Durchlauf.
Nich mal den Rightshift braucht er, denn im FPGA ist das lediglich ein 
simple Umverdrahtung. Heraus kommt das im Anhang.
In der Testbench habe ich einen recht "eckigen" Sinus hineingegeben und 
heraus kommt ein wesentlich "schönerer" Sinus... ;-)

: Bearbeitet durch Moderator
von Edi M. (Gast)


Lesenswert?

Das ist aber kein gleitender Mittelwert und vor allem kein FIR.
Oder irre Ich mich da?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

E. M. schrieb:
> Das ist aber kein gleitender Mittelwert und vor allem kein FIR.
> Oder irre Ich mich da?
Nein, aber lies mal den ganzen Thread: es geht darum, das langsame und 
umständliche FIR-Filter vom Threadanfang, das in jedem Takt die Summe 
über zig Speicherstellen bildet (und dessen Notch-Funktion der TO 
vermutlich sowieso nicht braucht) zu vereinfachen.
Und der einfachste Ansatz ist ein RC-Glied: der Summierer ist der 
Kondensator und die Gewichtung(Filterlänge) ist der Widerstand.

: Bearbeitet durch Moderator
von Steiniger (Gast)


Lesenswert?

Eine Zwischenfrage an die Fachleute: Wie kann man so einen einfachen 
Mittelwertfilter verbessern? Warum nicht gleich einen FIR mit 
Tiefpassfunktion? Vielleicht mit einfachen Koeffizienten?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Steiniger schrieb:
> Wie kann man so einen einfachen Mittelwertfilter verbessern?
In welche Richtung "verbessern"? Was soll das Ziel dieser Verbesserung 
sein?

von Lukas (Gast)


Lesenswert?

Steiniger schrieb:
> Eine Zwischenfrage an die Fachleute: Wie kann man so einen
> einfachen
> Mittelwertfilter verbessern? Warum nicht gleich einen FIR mit
> Tiefpassfunktion? Vielleicht mit einfachen Koeffizienten?

ein gleitender Mittelwertfilter ist ein FIR mit sehr einfachen 
Koeffizienten (Alle Koeffizienten gleich)

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Steiniger schrieb:
> Eine Zwischenfrage an die Fachleute:
> Wie kann man so einen einfachen Mittelwertfilter verbessern?
Die Antwort auf meine Frage noch abwartend ein kleine Ergänzung als 
Denksanstoß:
Wenn du einen Eingangswert hast, der von einer 
50Hz-(Netzfrequenz-)Störung und deren Oberwellen überlagert ist, dann 
hilft ein gleitender Mittelwert, der über 20ms hinweg filtert. Denn dann 
heben sich die Störungen durch positive und negative Halbwellen der 
Netzspannung (im Idealfall) auf.
Das ist dann genau der erste "Tiefpunkt" in der im 
Beitrag "Re: Gleitender Mittelwert rauscht" geposteten 
Filtercharakteristik.

Verbessern kann man einen (einfachen) Filter also bestenfalls dann, wenn 
man weiß, was verbessert werden soll. Denn wenn ich jetzt die 
Filtercharakteristik so weit verbessere, dass dadurch  mein FPGA zu voll 
wird, dann kann es besser sein, wenn ich einen schlechteren Filter 
nehme...

von Edi M. (Gast)


Lesenswert?

Steiniger schrieb:
> Warum nicht gleich einen FIR mit
> Tiefpassfunktion?
Weil das wieder einzelne Multiplikationen erfordert und eben solche 
ungleich 1. Man kann auch mehrere solcher Mittelwertfilter 
hintereinanderschalten.

von Weltbester FPGA-Pongo (Gast)


Lesenswert?

Lothar M. schrieb:
> Ein gleitender Mittelwert ist die einfachste Form eines FIR-Tiefpasses.

So ist es, deshalb schrieb Ich ja wörtlich "einen richtigen FIR" und 
nicht nur einen mean value, mit Betonung auf "richtig".


Gustl B. schrieb:
> Will sagen: Wenn man einen Tiefpass haben will und ein gleitender
> Mittelwert gut genug ist, dann spricht da nichts dagegen.

Gleitende Mittelwertfilter sind was für Osterhasen. :-)

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.