www.mikrocontroller.net

Forum: Digitale Signalverarbeitung / DSP Fixed-point->Genauigkeit geht verloren


Autor: DSPNeuling (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,


wenn ich Fixed-Point-Format auf meine Daten anwende, geht meine 
Genauigkeit bezueglich meiner Referenzwerte verloren. Ich habe eine 
Fehlerrate von 4%. Wenn die Zahl klein ist, springt die Fehlerrate sogar 
auf 28%. Das ist leider zu gross.
An welchen Parametern  kann man drehen, damit die Genauigkeit erhalten 
bleibt? Inputsample ist 12 Bit und die FIR-Koeffizienten konvertiere ich 
von double ins Fixed-Point-Format mit 2^18 Linksverschiebung. Die ganze 
Rechnung ist: (Filterkoeffizienten mal Inputsamples) + vorhergendes 
Ergebnis


Danke fuer Ideen!

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo geht die Genauigkeit verloren? Ganz am Anfang bei der Quantisierung 
der Daten? Da hilft es nur den Wertebereich stärker auszusteuern oder 
wenn das nicht reicht die Wortlänge zu vergrößern.

Autor: Detlef _a (detlef_a)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>An welchen Parametern  kann man drehen, damit die Genauigkeit erhalten
>>bleibt?

Dein FIR Filter berechnet ja ne Summe von Produkten. Du normierst die 18 
Bit nicht nach jeder Multiplikation zurück sondern summierst die genauen 
Ergebnisse auf und wenn Du mit allen Summanden fertig bist schiebst Du 
das Ergebnis 18Bit nach rechts. Vorsicht, Vorsicht: pro Addition kommt 
ein Bit dazu. Für 12Bit Inputbreite und 18Bit Koeffs ist das Ergebnis 
30Bit. Von diesen Produkten darf man nur zwei addieren wenn man mit 32 
Bit breiten Worten arbeitet. Wenn Du für dein FIR Filter mehr 
Koeffizieneten benötigst muß Du mit geringeren Koeffizientenbitbreiten 
als 18 arbeiten.

Cheers
Detlef

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Überläufe im Akkumulator stören nicht, solange das Endergebnis im 
darstellbaren Bereich bleibt.  Je nachdem welche Wahrscheinlichkeit für 
einen Überlauf im Endergebnis du dir leisten willst kann also auch ein 
kürzerer Akkumulator ausreichen.

Autor: Detlef _a (detlef_a)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Damit können eingangsdatenabhängig Overflows auftreten. Bei Audio 
bewirkt das Knacken und Zerren, bei anderen Signalen ebenfalls und das 
ist darüberhinaus auch noch schwierig zu finden.

Ich würde kein design raushauen, in dem Overflows nicht ausgeschlossen 
sind, egal was für Daten reinkommen.

Cheers
Detlef

Autor: DSPNeuling (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen Freunde,


danke fuer die Rueckmeldung.

Ich habe folgendes gemacht sowie ihr das empfohlen habt:
- Geringere  Koeffizientenbitbreite genommen (15-bit)
- Erst multipliziert und addiert, und danach das Ergebnis um 15 nach 
rechts verschoben.

Die Ergebnisse habe ich angehaengt. Die Fehlerrate koennt ihr da sehen. 
Bei kleinen Werten ist der Fehler sehr gross. Was kann ich noch machen?


Danke im Voraus!

Autor: DDB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die zu sehenden Fehler sind einfach die Fehler durch Truncation. Was da 
als shifted value herauskommt, sind die gleichen Werte, die du erhältst, 
wenn du die Float-Werte "truncatest" ohne zu Runden. Du könntest vor dem 
Shiften noch einen der 0.5 entspr. Wert addieren, um zu runden. Aber der 
Fehler wird nicht mehr deutlich kleiner, weil zuviel abgeschnitten wird.

Lösung wäre z.B. mehr verbleibende Genauigkeit (Wer sagt denn, dass da, 
wo ein Komma ist, abgeschnitten werden muss? Kann auch paar Stellen 
weiter hinter dem Komma passieren)

Oder du ditherst die Ergebnisse (z.B. per Rauschen mit Gaussverteilung 
auf die Werte legen u. dann abschneiden u. mehrere Werte pro Sample mit 
dem Rauschen erzeugen)

Autor: DSPNeuling (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

<Die zu sehenden Fehler sind einfach die Fehler durch Truncation. Was da
<als shifted value herauskommt, sind die gleichen Werte, die du 
erhältst,
<wenn du die Float-Werte "truncatest" ohne zu Runden. Du könntest vor 
dem
<Shiften noch einen der 0.5 entspr. Wert addieren, um zu runden. Aber 
der
<Fehler wird nicht mehr deutlich kleiner, weil zuviel abgeschnitten 
wird.

Ja, das stimmt. Ich hatte die geshifteten Koeffizienten gerundet.

<Lösung wäre z.B. mehr verbleibende Genauigkeit (Wer sagt denn, dass da,
<wo ein Komma ist, abgeschnitten werden muss? Kann auch paar Stellen
<weiter hinter dem Komma passieren)

Heisst das, vor dem Shiften erst mit z.B. 100 multiplizieren und dann 
shiften. Einfach die Kommastelle verschieben. Das Ergebnis backshiften 
und durch 100 dividieren. Meinst du sowas?

<Oder du ditherst die Ergebnisse (z.B. per Rauschen mit Gaussverteilung
<auf die Werte legen u. dann abschneiden u. mehrere Werte pro Sample mit
<dem Rauschen erzeugen)

Diese Methode kenn ich nicht :-( Kannst du mir das bitte besser 
erklaeren?


Danke!

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Detlef: Kommt drauf an. Man muss die Wahrscheinlichkeit eines Overflows 
gegen den SNR-Gewinn durch stärkere Aussteuerung abwiegen. Wenn man 
dauerhaft ein paar dB gewinnt indem man weiter aussteuert, dann kann es 
sich schon lohnen dafür einen Überlauf zu riskieren der durchschnittlich 
einmal im Jahr auftritt.

Um Überläufe komplett auszuschließen muss der Akkumulator so breit sein 
wie die Summe der Beträge der Impulsantwort (l1-Norm), das können bei 4 
Koeffizienten und 12x18 Bit auch weniger als 32 Bit sein.

Autor: Detlef _a (detlef_a)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schwarz wrote:

> Um Überläufe komplett auszuschließen muss der Akkumulator so breit sein
> wie die Summe der Beträge der Impulsantwort (l1-Norm), das können bei 4
> Koeffizienten und 12x18 Bit auch weniger als 32 Bit sein.

Das ist rchtig und vielleicht auch ne Lösung für DSPNeuling. Die Summe 
der Beträge aller 'real-values' ist 261.xx, also 9 Bit. Bei 12Bit 
Eingangsdaten hast Du also noch 31-9-12=10Bit Luft, Du kannst die 
'real-values' also noch um Faktor 1024 aufblasen, ohne daß was 
überläuft.

Die Addition von 0.5 vor dem Abschneiden ist gut, sonst kommt nen 
systematischer bias rein.

Die Koeffizienten scheinen mir bißchen merkwürdig, so unterschiedlich in 
der Größenordnung. Wo kommen die denn her?

Es gibt spezielle Entwurfsverfahren für FIR-Filter, die darauf Rücksicht 
nehmen, daß man die integer Koeffizienten abschneiden muß. Das bedeutet, 
daß man in der z-Ebene auf diskrete Plätze festgenagelt ist.

Cheers
Detlef

Autor: DSPNeuling (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi nochmal,

oh, ich sehe da ist ein Missverstaendnis in meinem Anhang.
Was ich mit der Spalte "real values" meine, ist, ihr seht Ergebnisse aus 
der Multiplikation und Addition: FIR*Inputsample + prevResult

Meine FIR-Coeffs:

a1= -0.0106 = -347
A2= 0.0329 = 1078
A3= 0.0308 = 1009
A4=-0.1870 = -6128
A5=-0.0280 = -918
A6=0.6309 = 20673
A7=0.7148 = 23423
A8=0.2304 = 7550

Es sind insgesamt 8 Koeffizienten. Auf der rechten Seite sind die um 
15-bit geshifteten Koeffizienten. Ich multipliziere diese mit 
Inputsamples. Im Anhang, die Spalte "real-values" ist das Ergebnis ohne 
das Shiften der Koeffizienten. Die Spalte "shifted value" ist das 
Ergebnis der geshifteten Koeffizienten. Ich hoffe, dieses Mal war das 
verstaendlich. Sorry.

>Das ist rchtig und vielleicht auch ne Lösung für DSPNeuling. Die Summe
>der Beträge aller 'real-values' ist 261.xx, also 9 Bit. Bei 12Bit
>Eingangsdaten hast Du also noch 31-9-12=10Bit Luft, Du kannst die
>'real-values' also noch um Faktor 1024 aufblasen, ohne daß was
>überläuft.

Ich habe einen Spielraum von 32-bit auf dem DSP-Chip.

>Die Addition von 0.5 vor dem Abschneiden ist gut, sonst kommt nen
>systematischer bias rein.

Aber warum Addition? Das verfaelscht den Wert oder? Wenn ich z.B. 11.3 
habe und 0.5 dazuaddiere, kommt ja 11.8 raus. Wenn ich das aufrunde, ist 
das schon 12. Ich habe die geschifteten Koeffizientenwerte einfach 
gerundet, ohne etwas dazuzuaddieren. Ist das falsch?

Danke fuer eure Hilfe. Die Betreuung von euch ist echt super!!!

Autor: Detlef_A (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Deine Koeff. benutzen den vorhandenen Zahlenbereich gut, sind allerdings 
Faktor 100 auseinander. Falls die Genauigkeit nicht reicht, sollte das 
mit integer schwierig werden. Ich weiß allerdings auch nicht, welche 
Genauigkeitsanforderungen Du hast, 32 Bit sind immerhin mehr als 180dB 
Dynamikumfang.

>>Ist das falsch?
Nein, das ist richtig. Nicht: 0.5 addieren und dann runden sondern: 
runden, indam man 0.5 addiert und dann abschneidet,


Cheers
Detlef

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde zuerst einmal von den gerundeten Koeffizienten auf den 
Frequenzgang zurückrechnen. Wenn der nicht im akzeptablen Rahmen liegt 
helfen mehr Bit für Daten und Endergebnis auch nichts mehr.

Autor: DSPNeuling (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,


also ich habe folgendes gemacht:

-einmal die Werte um 15 geshiftet
-einmal um 18


Das Shiften um 18 hat nichts gebracht. Die Ergebnisse im Vergleich mit 
den Ergebnissen um 15 waren sogar schlechter in unteren 
Frequenzbaendern. Also habe ich das bei 15-bit gelassen. Mehr faellt mir 
auch ncihts ein. Jetzt muss ich eine Standardabweichung berechnen um die 
Haueufigkeit der Fehler zu berechnen.


Ich danke euch ganz herzlich fuer eure Hilfe!


Ich habe eine Frage aus Neugier:

Wie kann ich die dBs rechnen? Ich weiss nicht, wie Detlef auf die 180 
dBs kommt :-(

Autor: Detlef _a (detlef_a)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
~ 6db/Bit (genau: 20*log10(2)). Wenn Du mit n Bits k-Volt darstellen 
kannst, kannst Du mit n+1 Bit 2*k Volt darstellen, also doppelt soviel: 
20*log10(2).

20*log10(2^32) ~ 180

Cheers
Detlef

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.