Skalierung auf Int bei einer FFT (128-Punkte)

Hängt vom Format ab, das du wählst.

Deine Zahlen sind 13 Bit signed, also im 1.12 signed Q-Format. Um das in 
16 Bits einzubetten hast du 4 mögliche Positionen für den Dezimalpunkt, 
d.h. du hast die Wahl zwischen
1.15
2.14
3.13 und
4.12

1.15 bringt dir die maximale Genauigkeit an Nachkommastellen. ALlerdings 
ist zu bedenken, daß auch Überläufe aufteten könnten. So ist -1 = 0x8000 
= -0x8000 = -(-1) weil 1 = -1 ist.

Daher ist es u.U. günstiger, 2.14 zu wählen oder 4.12 wenn es um 
Effizienz geht. Da 2.14*2.14 = 4.28 ergibt sich der Ergebnis einer 
Multiplikation aus den oberen 16 Bit nach einem Linksshift um 2. Analog 
ergibt sich das Ergebnis bei 4.12*4.12 = 8.24 aus dem High-Word nach 
einem L-Shift um 4 und bei 1.15*1.15 = 2.30 nach einem L-Shift um 1.

Johann

tiffy schrieb:
> Als muss ich auch an den adc werten skalieren und nicht nur an den
> Twiddlefaktoren? Diese würde ich mit 2^15 erweitern, dann hätte ich ja
> das 1.15 Format richtig?

Ja. Wobei die Berechnung der 128-ten Einheitswurzeln und deren 
Skalierung mit 2¹⁵ zur Compilezeit (oder vorher) geschehen kann, also 
nicht auf dem µC berechnet werden muss.

Johann

tiffy schrieb:

> Als Int Werte werden die ADC-Zahlen in eine 16-Bit Variable gespeichert.
> Da die Werte der "Twiddlefaktoren" zwischen -1 und 1 liegen müsste ich
> diese skalieren. Ich kann diese dann doch mit 2^15 skalieren und dann
> nach jeder Multiplikation mit dem Hardware-Multiplizierer (16-bit *16
> bit) nur das Higher Word (also die oberen 16 Bit) des Ergebnisses für
> die weitere Berechnung nutzen oder verstehe ich das falsch?

Was Du sagst ist richtig, Du verlierst natürlich Genauigkeit, i.e. Dein 
Rauschfloor geht hoch, aber das geht so.

Was nicht geht: Du kommst mit 12Bit Zahlen rein und machst eine 128er 
FFT, entsprechend 7 stages des Algorithmus. In jeder stage gewinnst Du 
maximal 1 Bit hinzu, selbst wenn Du die twiddle Faktoren skalierst, hast 
Du als Ergebnis der FFT 12+7 = 19 Bit Werte, die passen nicht in 16Bit 
Variablen rein. Der Overflow ist aber signalabhängig, breitbandiges 
Signal macht breitbandiges Spektrum, also nix mit Spitzen, Sinus macht 
einen peak, der zum Overflow führt. Entweder 32Bit rechnen oder 
dynamisch skalieren: runtershiften, wenn Overflow droht.

Cheers
Detlef

tiffy schrieb:
> Und jemand ne meinung dazu?
Das verschenkt jede Menge Genauigkeit. Ich weiß nicht, was Du willst und 
Dir leisten kannst: Schnelle Berechnung mit hohem eingeschlepptem 
Rauschen oder langsamer und genauer oder irgendwas dazwischen.

Cheers
Detlef

Sicher gibts Aussagen zur Genauigkeit und Fehlerfortpflanzung in 
integer-FFTs, konkrete Literatur ist mir aber nicht bekannt. Ich würds 
einfach in C auf einem PC ausprobieren.

Cheers
Detlef