Kaiser-Window Annäherung

[Peter (Gast)]

Ich suche eine einfach parametrische Annäherung an Kaiser 5 / 7 die man 
in einem AVR skalieren kann. Längen im Bereich von 100 ... 1000 Punkten. 
Leider gibt es solche Fälle wie 777 Punkte, sodass ich nicht einfach 
eine Tabelle nehmen und nicht benötigte Punkte weglassen kann.

Ich habe Wiki, DSP und andere Seiten gescanned und da hier gefunden:

I0(x)≈1+x2(−1(1!)241+x2(+1(2!)242+x2(...+x2((−1)K−1((K−1)!)24K−1+x2(−1)K 
(K!)24K))))

kennt jemand was Einfacheres?

[Tilo R. (joey5337)]

Bitte versuch' erst mal, dein Problem verständlich zu schildern.
Den ganzen Kontext, den du im Kopf hast, können wir nicht raten.

Googeln nach Kaiser 5/7 liefert Fußballschuhe.

Ich habe zwar eine Glaskugel mit USB-Anschluss, die ist aber im Büro und 
da komme ich erst wieder am Dienstag ran.

[Frank G. (frank_g53)]

Vielleicht meint er dieses hier:
https://de.wikipedia.org/wiki/Fensterfunktion#Kaiser-Fenster

[W.S. (Gast)]

Peter schrieb:
> Ich suche

Ver_suche es mal damit (sinngemäß):

// polynomial approximation of the zeroth order
// modified Bessel function
// from the Numerical Recipes in C p. 237

function Bessel0 (x : double): double;
var
  ax, ans : double;
  y       : double;
begin
  ax:= abs(x);
  if ax < 3.75
  then
  begin
   y:= x / 3.75;
   y:= y * y;
   ans:= 1.0 +
         y * (3.5156229 +
         y * (3.0899424 +
         y * (1.2067492  +
         y * (0.2659732 +
         y * (0.360768e-1 +
         y * 0.45813e-2)))));
  end
  else
  begin
   y:= 3.75 / ax;
   ans:= (exp(ax) / sqrt(ax)) * (0.39894228 +
          y * (0.1328592e-1 +
          y * (0.225319e-2  +
          y * (-0.157565e-2 +
          y * (0.916281e-2  +
          y * (-0.2057706e-1+
          y * (0.2635537e-1 +
          y * (-0.1647633e-1+
          y * 0.392377e-2))))))));
  end;
  result:= ans;
end;

// Kaiser-Fenster
function Kaiser (i: integer; beta: double): double;
var
  a, q : double;
  arg  :double;
begin
  a:= FilterTapnum / 2.0;
  q:= (i-a) / a;
  q:= q * q;
  arg:= beta * sqrt(1.000 - q);
  result:= Bessel0(arg);
end;

W.S.

[W.S. (Gast)]

nochwas:
Ob du bei deinem AVR mit single auskommst, muß du mal selber ausrechnen.

W.S.

[Hilbert (Gast)]

Deinen Beitrag verstehe ich nicht.

Ich habe aber mal ein Energiemessgerät gebaut, wo ein Kaiser-Fenster für 
eine Hilbert-Transformation verwendet wurde.
Möglicherweise meinst du ja das.

Hier steht beschrieben, wie es geht:
https://www.nxp.com/docs/en/application-note/AN4265.pdf

Man kann damit die Koeffizienten berechnen lassen:
http://www.iowahills.com/A5HilbertPhasePage.html

Kapitel 3.5.
Das wird da als FIR-Filter umgesetzt.

Läuft bei mir auf einem PIC32, aber ich sehe keinen Grund, warum das 
nicht auch ein AVR könnte.

[W.S. (Gast)]

Hilbert schrieb:
> Deinen Beitrag verstehe ich nicht....
> Läuft bei mir auf einem PIC32, aber ich sehe keinen Grund, warum das
> nicht auch ein AVR könnte.

Und was verstehst du da nicht? Ist ein Kaiser-Window eben. Tapnummer 
rein, Beta rein, Koeffizient raus. ferticht. Hab's eben grad mal aus 
einem Filter-Simulations-Programm von mir rausgeschnitten, deswegen das 
"sinngemäß".

Ich sehe aber durchaus einen Grund beim AVR, weil dort double gleich 
single ist... es sei denn, der TO benutzt einen Compiler, der 
tatsächlich double macht. Aber das kann ich in diesem Forum nicht als 
gesetzt ansehen.

W.S.

[Hilbert (Gast)]

W.S. schrieb:
> Und was verstehst du da nicht?

Ich habe mich nicht auf deinen Beitrag bezogen, sondern den des TE.

[Peter (Gast)]

Hilbert schrieb:
> Deinen Beitrag verstehe ich nicht.
Das Fenster ist vorgegeben und soll verwendet werden. Kann sein, dass es 
anders geht, nutzt mir aber nichts. Ich muss es anpassen an die Zahl der 
Daten. Laut heute 333, 666, 999 und 1023, 511, 255 sowie 99,199,299.

Es sind praktisch immer 1 weniger als normale Zahlen.


W.S. schrieb:
> nochwas:
> Ob du bei deinem AVR mit single auskommst, muß du mal selber ausrechnen.
>
> W.S.
Dein Beispiel sieht schon mal recht vielversprechend aus. Jedenfalls 
meine ich dass man das implementieren könnte. Ich checke es mal wegen 
der Auflösung. Irgendwie kriege ich das schon hin. Die Datenrate ist ja 
langsam genügend.

[W.S. (Gast)]

Peter schrieb:
> 666

Mach deine Filterlänge am besten immer ungerade, damit du genau 1 Tap 
exakt in der Mitte hast. Bei gerader Tapanzahl ist die Mitte, also quasi 
das Jetztzeit-Sample genau zwischen deinen beiden mittleren Samples - 
und das ist oftmals doof.

W.S.

[J. S. (engineer)]

Peter schrieb:
> sodass ich nicht einfach
> eine Tabelle nehmen und nicht benötigte Punkte weglassen kann.
Was wäre, die Punkte einfach zu interpolieren? Meistens bemüht man doch 
bei solchen Anwendungen nicht den Prozessor mit einer so aufwändigen 
Berechnung, sondern nutzt den heute in Massen vorhandenen Speicher und 
macht das offline. Es läuft doch eh auf eine ungenaue Abbildung durch 
Annäherung hinaus.

Da fände ich eine Tabelle mit quadratischer Interpolation besser. Damit 
wären auch unterschiedliche Kaiser-Fenster gleich miterschlagen. Selbst 
bei einer linearen Interpolation mit 37 aus 64 Punkten und einer 
Phasenauflösung von nur 8 Bit! bekommt man bei einem von-Hann-Fenster 
nur 3% maximalen relativen- und 0,005 absoluten Fehler. Siehe Bild aus 
meinem Fundus. (absoluter Fehler orange x 100, relativer Fehler rot in 
Prozent).

Da die Fenster in der Regel für sequenziell eintrudelnde Daten benötigt 
werden, man könnte die Werte auch noch mit einem sehr einfachen 
FIR-Filter glätten, um Interpoliertes abzurunden.

W.S. schrieb:
> das Jetztzeit-Sample genau zwischen deinen beiden mittleren Samples
Das ließe sich auch mit den Koeffizienten korrigieren, wenn nötig, oder 
man füllt eine Null, wenn es die Anwendung erlaubt, ich glaube aber, 
dass es bei der Anwendung nicht so sehr darauf ankommt. Allerdings ist 
die 666 ja die einzige gerade Zahl in dem Verein und damit 
hinterfragenswert. Sicher kann man auch 667 nehmen. Bibeltreue 
Entwickler werden sich ohnehin weigern, ausgerechnet die zu 
implementieren.

Ich würde auch noch die Frage einwerfen, woher die Koeffizienten kommen? 
Sollen die auch online berechnet werden? Das scheint mir gfs noch 
aufwändiger, sofern es nicht einfach ein Tiefpass ist.

[W.S. (Gast)]

Jürgen S. schrieb:
> Ich würde auch noch die Frage einwerfen, woher die Koeffizienten kommen?

Na aus ner Berechnung zur Laufzeit. Das hängt doch davon ab, was der 
Benutzer grad an den Knöpfen des Gerätes dreht.

Also, deine Idee, die Fensterfunktion per Interpolation zu machen, ist 
alles andere als gut. Immerhin sind die geläufigen Fensterfunktionen 
(Blackman, Kaiser) ja kein Hexenwerk und lassen sich zur Laufzeit 
berechnen. Das ist nötig, wenn man es mit unterschiedlich großen 
Filterkerneln zu tun hat. Ist hingegen die Länge des Filterkernels 
konstant, dann kann man auch die Fenster als konstantes Array vorhalten.

Jürgen S. schrieb:
>> das Jetztzeit-Sample genau zwischen deinen beiden mittleren Samples
> Das ließe sich auch mit den Koeffizienten korrigieren

Nein, das ist prinzipiell nicht möglich. Bei gerader Tapanzahl sitzt man 
prinzipbedingt immer exakt mitten zwischen den Stühlen.

W.S.

[J. S. (engineer)]

W.S. schrieb:
> Also, deine Idee, die Fensterfunktion per Interpolation zu machen, ist
> alles andere als gut.
Kann aber genauestens untersucht und simuliert werden. :-)

> Immerhin sind die geläufigen Fensterfunktionen
> (Blackman, Kaiser) ja kein Hexenwerk und lassen sich zur Laufzeit
> berechnen.
Das kommt drauf an! Blackman-Harris erfordert in einer Version gleich 3 
Cosinus-Funktionen/Frequenzen und die werden letztlich immer auch über 
Tabellen ermittelt und/oder brechen nach Iterationen ab. Das bringt also 
potenziell mehr Fehler oder erfordert mehr Auflösung bei der Berechnung 
und damit Aufwand. Da ist die einzelne Tabelle mit den Endwerten 
genauer, kontrollierbarer und vor allem schneller. Sie ist halt leider 
erheblich größer.

> Das ist nötig, wenn man es mit unterschiedlich großen
> Filterkerneln zu tun hat. Ist hingegen die Länge des Filterkernels
> konstant, dann kann man auch die Fenster als konstantes Array vorhalten.
Ganz genau daher ja der Tabellenvorschlag. Nur wenn kein Platz für 
Tabellen ist, behilft man sich mit einer generischen Synthese.

Allerdings geht das bei Tempoanwendungen kaum, das in Echtzeit zu 
berechnen - besonders nicht, wenn sich der Filter rasch ändern muss. Das 
ist bei Radar z.B. der Fall, wenn die Datenrate im Bereich der 
FPGA-Taktfrequenz ist. Selbst bei Audio-Apps ist das schon kritisch: 
Meine Window- und Filterparameter für die Equalizer, kann Ich für 192kHz 
und entsprechender TAP-Zahl noch in ausreichender Geschwindigkeit 
nachberechnen, wenn "jemand an den Knöpfen dreht" und damit ein analoges 
Verhalten herstellen. Beim Ultraschall ging es schon nicht mehr.

Bei der hiesigen Anwendung ist die Datenrate sicher gering, aber die 
Prozessorpower auch niedrig. Daher sehe ich das ähnlich gelagert.

Daher wäre die Frage, ob man mit mehreren Tabellen nicht besser 
hinkommt, zumal die Anzahl ja bekannt ist.

Aber auch selbst dann, wenn nur eine statische Tabelle implementiert 
werden kann, lässt es sich mit Interpolation in der Regel recht gut 
hinbiegen.

Man darf nicht vergessen, dass das Berechnen der Koeffizienten und 
Fensterwerte auch an Auflösungsgrenzen stößt und man sich dort Fehler 
einheimst. Die Wirkung der Fehler einer Interpolation zweier ansonsten 
exakter Tabellenwerte liegen hingegen mit etwas Geschick vom Spektrum 
weit oberhalb der Grenzfrequenz des Filters, um das es geht. Das ist 
recht gut untersuch- und kontrollierbar.

Ich habe mich da auch schon verschätzt! Ich habe generische Synthesen in 
VHDL für die meisten Fenster - unter anderem auf Basis meines 
10Bit-Sinus (siehe Digitale Sinusfunktion) und komme da für 
mittelanspruchsvolle Anwendungen auch sehr gut hin. Deutlich kleiner, 
als z.B. CORDIC bei gleicher Genauigkeit!  Das Fehlersprektrum hat aber 
durch das digitale Rauschen etliche tieffrequente Komponenten. Bei den 
Implementierungen und Rechentiefen, die in FPGAs mit ihren MUL-Breiten 
gerade so richtig effektiv sind, werden die mitunter irgendwann 
relevant. Für hohe Anforderungen machen die Tabellen mit Interpolation 
weniger Aufwand - bei besseren Ergebnissen. Um da drüber zu kommen, muss 
man sehr genau rechnen. Das wird langsam und in FPGAs z.B. sehr groß.


Wo es sich eher lohnt, sind CPU mit 64 Bit und ihren Rechenoptionen.

[W.S. (Gast)]

Jürgen S. schrieb:
> Kann aber genauestens untersucht und simuliert werden. :-)

Mag ja sein, aber ich weiß, daß schon Kleinigkeiten bei der 
Tap-Berechnung und bei der Fensterfunktion ne Menge bewirken im 
Sperrbereich des Filters.

Naja - und Winkelfunktionen brauchst du bei der Berechnung der Taps ja 
ohnehin - bei sin(x)/x wenigstens einmal den Sinus. Bei Blackman kommt 
dazu noch 2x Cosinus und bei Kaiser eben ne Wurzel und ein Sack voll 
Multiplikationen. Wenn man das per SW in double machen will, wird's 
natürlich nicht furchtbar schnell, wenn dafür jedoch single ausreichen 
sollte, dann geht's beim Cortex M4F ratzfatz.

Und was hast du gegen den Cordic? Die meisten Leute glauben, man müßte 
den mit voller Stellenzahl abarbeiten, aber das stimmt einfach nicht. 
Wenn man den Rest mit dem bislang aufgelaufenen 1/cos(dphi) verrechnet, 
dann braucht man überschlägig nur 1/3 der Bits und der Rest kommt aus 
dem Rest. Nochmal: für 15 Bit braucht man nur 5 Iterationen, für 24 Bit 
braucht man nur 8 Iterationen.

Ich häng hier mal ein kleines Delphi-Programm dran. Ich hatte es den 
Cordic sowohl mit double als auch mit single rechnen lassen, die 
tabellarischen Ergebnisse sind anbei im ZIP. Wundere dich nicht, ich 
hatte mir erspart, ne Tabelle für die arctan's zu schreiben. Für eine 
echte Implementierung würde man das natürlich tun.

W.S.

[Peter (Gast)]

Jürgen S. schrieb:
> die 666 ja die einzige gerade Zahl in dem Verein und damit
> hinterfragenswert. Sicher kann man auch 667 nehmen. Bibeltreue
> Entwickler werden sich ohnehin weigern, ausgerechnet die zu
> implementieren.
In welcher "Bibel" steht, dass man die nicht nehmen soll? Was ist an den 
geraden Zahlen so schlecht? Die Filtersumme ändert sich nur minimal, 
wenn ein Wert mehr gerechnet wird, meine ich. Trotzdem möchte ich nicht 
ohne zwingenden Grund einen weiterer Wert mitverrechnen. Leider gibt es 
auch noch die 222.

> Ich würde auch noch die Frage einwerfen, woher die Koeffizienten kommen?
Diese kommen aus einer Entwicklungsformel, die ich nicht mehr 
programmieren muss, weil es die schon gibt. Die ist etwas kompliziert 
und nicht ganz durchschaubar.

W.S. schrieb:
> bei Kaiser eben ne Wurzel und ein Sack voll
> Multiplikationen.
Ich habe das weiter oben angesprochene Beispiel eingebaut, komme aber 
auf kein Kaiserfenster. Es sieht in keinem Fall so aus, wie in der 
Wikipedia.

Wie könnte ich das bitte mit einem Cordic berechnen?

[W.S. (Gast)]

Peter schrieb:
> Ich habe das weiter oben angesprochene Beispiel eingebaut, komme aber
> auf kein Kaiserfenster. Es sieht in keinem Fall so aus, wie in der
> Wikipedia.

Dann hast du irgend einen Fehler gemacht.
Ich häng dir mal zwei Beispiele dran, sind im Prinzip SSB-Filter, also 
für Quasselfunk so etwa 0.2 .. knapp 3 kHz bei 44.1 kHz Samplerate.

Ein Filter mit dem üblichen Blackman gemacht, das andere mit dem oben 
geposteten Kaiser, Beta zu 9.5 gewählt.

Ich hab übrigens die Sinusberechnung für das sin(x)/x Filter auch mal 
per single und obendrein auch mit dem Pedersen gemacht. Resultat: man 
kann beides benutzen, die Unterschiede zeigen sich im Sperrbereich und 
sie sind m.E. durchaus tragbar.

Ich habe anschließend auch noch mal den Vergleich gemacht zwischen dem 
Filter in double, single und integer mit verschiedenen Bitbreiten 
gerechnet. Nur 16 Bit ist zu wenig, aber so ab 20 Bit integer ist das 
OK.

Also guck mal, was du da falsch gemacht hast.

W.S.

[J. S. (engineer)]

W.S. schrieb:
> Und was hast du gegen den Cordic?
Im Grunde nichts, nur arbeitet der eben auch mit intern vorgerechneten 
Tabellenwerten und die müssen eine gewisse Genauigkeit haben, damit 
Fehler nicht akkumulieren. Eine finale Tabelle gleicher Auflösung der 
Einzelwerte hat immer weniger Fehler. Man muss also schauen, was man 
vergleicht. Klar, der CORDIC kommt mit vielleicht 10 Real-Werten aus und 
ist super klein.

Da es hier aber um das Rechnen mit einem Kleinstprozessor geht, fände 
ich es allemal sinnvoller, sich für die paar Fälle einige Tabellen zu 
machen und deren Werte zu laden. Ein einzelner Speicherzugriff, statt 
einem Vielfachen davon. Bei einer Interpolation wären es zwei Zugriffe 
und etwas Addition. Blackman-Harris mit 3 Termen und die Koeffizienten 
sind 4x cosinus-Cordic, mehr Adds und Muls. Das ist Arbeit, die man in 
die Designzeit schieben kann.

Ich halte jetzt mal mit einer 1024 Punktetabelle gegen, aus der man mit 
einfacher Interpolation 7777 Punkte rausholt:

Fehler orange x 10.000, relativer Fehler rot in Promille -> maximal 
100...200ppm.
Die Werte sind in maximal 16 bit gerechnet.

Für andere Funktionen hängt der Fehler von der maximalen Steilheit ab. 
Diese ist aber bei engeren Fenstern, als das von-Hann in der Mitte 
größer, wo der relative Fehler klein ist. Damit wird sich das kaum 
verschlechtern - im Gegenteil.

[J. S. (engineer)]

W.S. schrieb:
> aber ich weiß, daß schon Kleinigkeiten bei der
> Tap-Berechnung und bei der Fensterfunktion ne Menge bewirken im
> Sperrbereich des Filters.
Genau so ist es und damit müssen die Faktoren des Fensters effektiv 
mindestens so genau sein, wie die Koeffizienten. Wenn man sich nun die 
Blackman-Fenster und ihre Derivate ansieht, dass die Faktoren auf 6 
Stellen genau gegeben sind, dann muss man nachdenken, ob man mit single 
auskommt.

Bei Kaiser ist das noch viel schlechter. Da möchte man keine 
Besselfunktionen in Echtzeit berechnen. Diese sind am Ende auch nur über 
Tabellen und Polynome genähert. Damit schleppt sich ein Fehler zum 
nächsten, bis hin zu einem Wertesystem, bei dem einige Werte recht genau 
sind und andere nicht. Das ergibt keinen tabellenweit konsistenten 
Fehler. Man muss dann die Rechnung weitgehend auf den ärgsten Fehler 
abstimmen, womit dann die meisten anderen Werte viel zu genau sind und 
erheblichen Aufwand machen.

Zudem erzeugt das ein "zufälliges" Fehlerspektrum und damit Rauschen, 
welches der Rechnung aufgedrückt wird. Wie ich schon ausgeführt habe, 
ist das bei Interpolationen besser kontrollierbar, wenn man die 
interpolierten Werte selbst entsprechend filtert, also "rund" 
interpoliert. Ein kleines Biquad-filter reduziert schon mal alles 
oberhalb der 2. Oberwelle und die überbleibenden Spektralanteile kleben 
dann im Filter selber.

Bei so umständlichen Funktionen wie Kaiser rechnet man das fein 
säuberlich in eine Tabelle und nimmt die Koeffizienten gleich mit 
hinein. Was an Rechenzeit im Prozzi zur Verfügung steht, steckt man dann 
in die Filterung. Die maximale Krümmung der Koeffizienten/Fensterwerte 
ist ja dediziert bekannt und kann somit als Information bez. der 
Grenzfrequenz in den Interpolationsfilter einfließen.

Dann baut man einfach eine Tabelle mit einem Fehler im Bereich der 
Hälfte des Zulässigen und interpoliert sich den Rest hin. Selbst bei so 
ungünstigen Konstellationen wie 1023/1024 gibt es dann kaum Fehler, 
obwohl die Schwebungsfrequenz extrem tief liegt.

[J. S. (engineer)]

Peter schrieb:
> Jürgen S. schrieb:
>> die 666 ja die einzige gerade Zahl in dem Verein und damit
>> hinterfragenswert. Sicher kann man auch 667 nehmen. Bibeltreue
>> Entwickler werden sich ohnehin weigern, ausgerechnet die zu
>> implementieren.
> In welcher "Bibel" steht, dass man die nicht nehmen soll?
In der Offenbarung des Johannes. Oder wie es die Eisernen Jungfrauen 
einst ausdrückten:

Woe to you, oh earth and sea, for the devil sends the beast with wrath,
because he knows the time is short. Let him who hath understanding 
reckon the number of the beast, for it is a human number, it's number is 
666!

Es gibt in der Tat unzählige, die diese Zahl meiden. Glaubt man gar 
nicht.

Ungeachtet dessen kommen mir Deine Filter-TAP-Zahlen etwas suspekt vor. 
Woher kommen die?

> Was ist an den geraden Zahlen so schlecht?
Die Filtermitte sitzt nicht auf einem echten Sample. Das ist aber nicht 
unbedingt ein Problem:


> Jürgen S. schrieb:
>>> das Jetztzeit-Sample genau zwischen deinen beiden mittleren Samples
>> Das ließe sich auch mit den Koeffizienten korrigieren
>
> Nein, das ist prinzipiell nicht möglich. Bei gerader Tapanzahl sitzt man
> prinzipbedingt immer exakt mitten zwischen den Stühlen.

Aus Sicht des Samples und seinem Zeitpunkt nicht, aber man kann die 
Filterkoeffizienten versetzen, wie beim statischen 
Sub-Sample-Prozessing.
Damit kann man die Wirkung des Filters um 0,5 Samples verschieben.
Das ist nicht dasselbe, hat aber im Bezug auf die Vergleichbarkeit 
zweier Filter, die einmal mit gerade und einmal mit ungerade arbeiten, 
dieselbe Wirkung.

[Peter (Gast)]

Jürgen S. schrieb:
> Da es hier aber um das Rechnen mit einem Kleinstprozessor geht, fände
> ich es allemal sinnvoller, sich für die paar Fälle einige Tabellen zu
> machen und deren Werte zu laden.
Mit dem RAM sieht es leider nicht so üppig aus. Es muss doch möglich 
sein, das zu berechnen: Kaiser habe ich von Wikipedia. Das müsste 
stimmen. Das Problem ist jetzt die Besselfunktion. Ich beziehe mich auf 
die folgende Seite auf der die "Besselfunktion null-ter-Ordnung" 
bestimmt werden kann:

https://mhf-e-wiki.desy.de/Bessel-Funktion

Die Formel lautet wie angegeben.

Meines Erachtens steht unten 2x m-Fakultät, da "n" = 0. Der Zähler 
liefert ein wechselndes 1/-1 und der Faktor hinten sind m/2 hoch (2m). 
Die Tabellenwerte summieren die Werte über m auf. Müsste machbar sein, 
da sie schnell konvergieren. Ich habe es für die angegebene Nullstelle 
bei 2,405 durchprobiert, stimmt aber nicht. Wo ist der Fehler?

W.S. schrieb:
> Ich häng dir mal zwei Beispiele dran, sind im Prinzip SSB-Filter
Mit welcher Software sind die Funktionen erzeugt worden?

[W.S. (Gast)]

Peter schrieb:
> Mit welcher Software sind die Funktionen erzeugt worden?

Mit meinem eigenen Entwurfs-System. Und eben mit dem bereits von mir 
geposteten Kaiser-Fenster, inclusive der Bessel0.

W.S.

[Dergute W. (derguteweka)]

Moin,

Warum beschleicht mich ganz stark das Gefuehl, dass das mit dem 
Kaiserwindow mal wieder so ein Holzweg ist, der - einmal beschritten - 
um's Verrecken alternativlos ausgelatscht werden muss? Koste es was es 
wolle.

Kein Mensch kann was mit einem alleine in der Weltgeschichte 
rumstehenden Kaiserwindow anfangen. Das ist hoechstens Teil einer z.B. 
filternden Signalverarbeitung. Die aber sicher eigentlich durch ganz 
andere Anforderungen gekennzeichnet ist (.z.b. Durchlassripple, 
Sperrdaempfung, Gruppenlaufzeit, Datendurchsatz, ...) und daher sicher 
auch irgendwie anders aufgebaut werden kann. Und da eine alleine in der 
Weltgeschichte rumstehende Signalverarbeitung auch recht sinnlos ist, 
koennte man auch da 2..3 Worte verlieren...
Aber nein; es muss das Fenster vom Herrn Kaiser von der 
Humbug-Muelleimer sein. Mit Besselfunktionen. Aufm AVR. In 
floating-point.
Wo ich - wenns einer still implementiert haette und hier vorstellen 
wuerde - sofort begeistert waere. Aber wenn man's nicht hinkriegt, muss 
man sich halt schon auch mit der Frage plagen lassen, wie sinnvoll so 
ein Unterfangen wohl sein mag.

Gruss
WK

[W.S. (Gast)]

Dergute W. schrieb:
> Warum beschleicht mich ganz stark das Gefuehl,..

Ja, das kenne ich. Immerhin war es der dedizierte Wunsch des TO, den 
Algorithmus für eine derartige Fensterfunktion mal gesagt zu bekommen, 
was ja auch wunschgemäß erfolgte - bittesehr.

Offenbar hat er den geposteten Code nicht wirklich verstanden. 
Jedenfalls meint er, "Ich habe das weiter oben angesprochene Beispiel 
eingebaut, komme aber auf kein Kaiserfenster. Es sieht in keinem Fall so 
aus, wie in der
Wikipedia".

Ob dabei ein sinnvolles Projekt im Hintergrund steht oder eher nicht, 
ist ne andere Sache. Er will vermutlich ein variables FIR-Filter mit 
"Längen im Bereich von 100 ... 1000 Punkten" auf nem AVR damit 
berechnen. Nun ja, seufz.

Putzig ist dabei, daß der Vergleich zwischen einem Bandpass mit Kaiser 
versus Blackman offenbar niemanden interessiert, Downloads=0. Die 
ungepackt geposteten Bilder, wo ich mal mit reduzierten Bitbreiten 
gerechnet habe, um mir die Degradation zu veranschaulichen, scheinen auf 
größeres Interesse zu treffen. Sehen so schön bunt aus...

Vielleicht ist es dem TO auch nur ein Anliegen, derartige Berechnungen 
überhaupt auf einer eigenen HW tun zu können, also den eigentlichen 
Algorithmus zu kennen. Da wäre der AVR lediglich als symbolische Geste 
zu verstehen.

Immerhin wäre es ansonsten recht wahrscheinlich, daß er mit Beiträgen 
zugemüllt würde, wo man ihm sagt, er soll doch einfach sich nen fertigen 
Filterkernel per Mathlab berechnen lassen. Viele Leute schweben auf 
derartiger Ebene und präsentieren angebliche Lösungen für ein Problem 
durch einen Verweis auf eine dafür spezialisierte Funktion in Mathlab. 
Sowas nützt normalerweise garnichts für's Verstehen und Können.

W.S.

[Peter (Gast)]

Dergute W. schrieb:
> Warum beschleicht mich ganz stark das Gefuehl, dass das mit dem
> Kaiserwindow mal wieder so ein Holzweg ist, der - einmal beschritten -
> um's Verrecken alternativlos ausgelatscht werden muss? Koste es was es
> wolle.
Es muss laut SPEC eingebaut werden. Ist nichts zu deuten. Die Herren 
Physiker haben es so festgelegt. Ich werde Deine Kritik weitergeben.

W.S. schrieb:
> Viele Leute schweben auf
> derartiger Ebene und präsentieren angebliche Lösungen für ein Problem
> durch einen Verweis auf eine dafür spezialisierte Funktion in Mathlab.
> Sowas nützt normalerweise garnichts für's Verstehen und Können.
MATLAB nicht Mathlab.

Ich konnte die Näherung nun ins Laufen bekommen. War ein Tippfehler in 
der Weitergabe der Parameter. Hat sich verrechnet. Das Fenster sieht nun 
aus, wie das in der Wikipedia.

[Dergute W. (derguteweka)]

Moin,

Peter schrieb:
> Es muss laut SPEC eingebaut werden. Ist nichts zu deuten. Die Herren
> Physiker haben es so festgelegt. Ich werde Deine Kritik weitergeben.

Wuerd' mich schon interessieren, was letztendlich die Anforderungen 
sind, und warum's genau das olle Kaiserfenster sein muss. Vielleich 
hat's ja irgendeine tatsaechliche Berechtigung. Die faend' ich dann 
schon interessant.

Gruss
WK

[W.S. (Gast)]

Peter schrieb:
> MATLAB nicht Mathlab.

Ist dir das derart wichtig? Mir nicht.

W.S.

[J. S. (engineer)]

Dergute W. schrieb:
> Wo ich - wenns einer still implementiert haette und hier vorstellen
> wuerde - sofort begeistert waere. Aber wenn man's nicht hinkriegt, muss
> man sich halt schon auch mit der Frage plagen lassen, wie sinnvoll so
> ein Unterfangen wohl sein mag.
Die Implementierung an sich ist eigentlich weniger das Problem. Man muss 
sich eben fragen, wann man die Iteration für die Besselfunktion 
abbricht. Für den Bogenabschnitt, der bei Kaiser relevant ist, reichen 
eigentlich 5-7 Iterationen wegen der doppelten Fakultät im Nenner. Es 
läuft also wieder auf eine Abschätzung hinaus, wie genau der jeweilige 
Wert sein muss. Ab dann muss man eben schauen, wie man es am 
Geschicktesten auflöst, um mit Integer hinzukommen. Man kann sowas ja 
als Rekursion hinschreiben, es in C++ mit einem Abbruchkriterium 
betreiben. In der selben Weise ginge das auch offline in einer Software 
wie Python oder Excel, indem man in jeder Rekursionsstufe eine 
Integerskalierung durchführt und die benötigten Korrekturfaktoren von 
der jeweils darunter liegenden Stufe ausrechnen lässt, es ausführen 
lassen, um so direkt die Skalierungsfaktoren mitgeliefert zu bekommen 
und sie auch gleich theoretisch zu testen. Für eine Logarithmusfunktion 
haben wir das mal in Unix gemacht.

W.S. schrieb:
> Putzig ist dabei, daß der Vergleich zwischen einem Bandpass mit Kaiser
> versus Blackman offenbar niemanden interessiert,
Vielleicht ist den regelmäßigen Nutzern von Fensterfunktionen deren 
Qualität und Unterschiede hinlänglich bekannt :-)

Peter schrieb:
> Es muss laut SPEC eingebaut werden. Ist nichts zu deuten. Die Herren
> Physiker haben es so festgelegt.
War da ein anderes Fenster drin (oder keins) und hat man gemerkt, dass 
da was nicht so ganz klappt?

> Das Fenster sieht nun aus, wie das in der Wikipedia.
Optisch geprüft oder über Wertevergleich? Oder sogar über 
Wirkungsvergleich zusammen mit dem Filter wie W.K. es oben skizziert?

Das, was das Fenster an Oberwellen betont und zu gut durchlässt, lässt 
sich teilweise mit den Filterkoeffizienten ausgleichen. Wenn es richtig 
billig und resourcenschonend sein soll, kann man dann auch so etwas 
nehmen und etwas korrigieren:
http://www.96khz.org/oldpages/windowfunctions.htm

Die Funktion in der zweiten Potenz kommt auf den benötigten Abschnitt 
der Besselfunktion bis auf 95% ran und mit einer Mischung aus S2 uznd S3 
kriegt man auch so etwas wie Kaiser einigermaßen hin.