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
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?
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.
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.
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?
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.
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!! :)
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"
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...
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.
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.
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.
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
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.
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...
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
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.
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
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... ;-)
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.
Eine Zwischenfrage an die Fachleute: Wie kann man so einen einfachen
Mittelwertfilter verbessern? Warum nicht gleich einen FIR mit
Tiefpassfunktion? Vielleicht mit einfachen Koeffizienten?
Steiniger schrieb:> Wie kann man so einen einfachen Mittelwertfilter verbessern?
In welche Richtung "verbessern"? Was soll das Ziel dieser Verbesserung
sein?
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)
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...
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.
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. :-)