Hyperbolische Down-Chirp (genauer die Frequenzwerte eines solchen zum Füttern eines NCO) lassen sich mit der Formel y = (a / (t - b))+ Foff geschlossen berechnen. Eine Implementation per Divider auf einem FPGA funktioniert, frisst aber, je nach Wortbreite, mehrere Hundert Slices. Dazu kommt, dass sich die Skalierung bei jeder Änderung von a oder b ändert; die Berechnung sich also nicht einfach parametrisieren lässt. Ein 8ms langer Down-Chirp von 78kHz auf runter bis 46kHz kann mit folgenden Parameter berechnet werden: a = 4096 b = 128 Foff = 45 kHz (1 MSp/s). Berücksichtigt werden müssen aber auch die jeweiligen Randbedingungeng, z.B. rechtzeitiges Beenden der Berechnung, damit keine Division durch Null entsteht. Grundsätzlich müssten sich die Frequenzwerte doch auch - vom jeweiligen Startwert aus - rekursiv berechnen lassen? Und somit (rekursiv) auch als IIR-Filter implementiert werden - den man einmal passend anregt und dessen Ausgangssignal dann hyperbolisch ausklingt. Geht das oder nur eine spinnerte Idee? BTW: In der Natur finden sich hyperbolische Downchirps bei vielen Fledermausarten als Ortungsrufe, die anhand der unteren Grenzfrequenz des Chirps oft bis zur Art identifiziert werden können.
Burkhard K. schrieb: > Eine Implementation per Divider auf einem FPGA > funktioniert, frisst aber, je nach Wortbreite, mehrere Hundert Slices. Warum nicht die Werte einmal berechnen und in einer Tabelle (LUT) hinterlegen?
nachtmix schrieb: > Warum nicht die Werte einmal berechnen und in einer Tabelle (LUT) > hinterlegen? Geht natürlich auch, frisst aber bei etwas mehr als 8000 Einträgen noch mehr (BRAM-)Resourcen - für genau einen fixen Downchirp.
Die Werte sollten eine geometrische Reihe bilden. Sicher kann man die rekursiv berechnen.
... schrieb: > Die Werte sollten eine geometrische Reihe bilden. > Sicher kann man die rekursiv berechnen. Auf der DSP-Liste wurde vor einigen Monaten ein ähnliches Thema diskutiert, als es um einen einfachen Logarithmus ging. Auch da kam die offset-Formel von oben ins Spiel mit einer Reihe von Lösungen. Ehrlich gesagt, war ich doch recht verwundert, welche Wissenschaft man daraus machen kann. Ja im FPGA kann man das leicht machen, siehe die Diskussionen zu den selbstschwingenden Oszillatoren. Man kann dann dynamisch die Parameter modifizieren, um das exakte Ausklingverhalten der Amplitude und der sich daraus ergebenden tatsächlichen / scheinbaren Frequenz zu bestimmen. Für ganz bestimmte Konstellationen der Parameter gibt es dann einfache Abbildungen für die Rekursion. Aber: Das, was aus einem echten ausklingenden Oszillator mit "natürlich" fallender Frequenz heraus kommt und was sich folglich mit einer rekusrisven Formel einfach berechnen lässt, ist leider nicht so perfekt als optimales Zirpen verwendbar, wenn man die Signale nochmal verarbeiten will, wie z.B. bei den reflektiereten Versionen in Radar-Anwendungen. Damit ist ein einfaches parametrisches Formelkonstrukt dafür gfs nicht ausreichend.
Rekursiv ist vllt ein wenig ungluecklich ausgedrueckt. Wenn ich die Frequenz eines Tones mit 2^(1/12) multipliziere erhalte ich den naechsten Halbton. Auch eine geometrische Reihe. Kann die Berechnung auf einem FPGA u.U. vereinfachen. Genauso kann der TO, nach Abtrennung des additiven Anteils, eine geometrische Reihe benutzen, um aus dem letzten bekannten Faktor den naechsten zu berechnen. Braucht vllt einen etwas breiteren Multiplizierer um hinreichend genau zu sein. Ob das zum Erzeugen von guten Chirpsignalen reicht, ist dabei noch gar nicht relevant.
... schrieb: > eine geometrische Reihe benutzen, um aus dem letzten > bekannten Faktor den naechsten zu berechnen. Die Formel für die rekursive Berechnung (ohne Offset) lautet: y(n) = 1 / (1/y(n-1) + 1/a) Wie sich damit die Berechnung vereinfachen lässt, sehe ich noch nicht (zwei Divisionen). Kann dieses Verhalten auch ohne Division nachgebildet werden? @Jürgen - bei mir werkelt ein stinknormaler NCO den ich mit (zu berechnenden) Frequenzworten füttere, also kein "selbstschwingender Oszillator. Reicht als internes Testsignal allemal.
also die Mathematik sagt:
1 | y[t+1] = a * (y[t] - Foff) / (a + y[t] - Foff) + Foff |
also immer noch eine Division. Und die ganzen eingefangenen Ungenauigkeiten... Die Tabelle scheint mir geschickter, wenn du keine Lust auf Divisionen hast. Skalierung, Zeitverschiebung und Offset sind trivial. Also lassen sich mit wenig Aufwand aus einer gespeicherten Lösung generieren. Mit dieser Argumentation könnte man zurück in die Formel gehen und behaupten, es reicht, y = 1/t rekursiv darzustellen (heißt a=1 und Foff=0). Aber auch so wird man die Divison nicht los... Wellenlänge vorgeben? :D Wenn du gratis Logarithmus und Exponentialfunktionen hast (z.B. zur Basis zwei), dann lässt es sich tatsächlich noch anders darstellen. Aber wie genau?
:
Bearbeitet durch User
Ja, da hab ich mich vertan. Hyperbolisch laesst sich auch durch Anwendung von Gewalt nicht in eine geometrische Reihe pressen. Schuld daran ist natuerlich der grafische Taschenrechner. Der Plot war einfach zu kurz, zu klein und zu pixelig :-).
Burkhard K. schrieb: > nachtmix schrieb: >> Warum nicht die Werte einmal berechnen und in einer Tabelle (LUT) >> hinterlegen? > > Geht natürlich auch, frisst aber bei etwas mehr als 8000 Einträgen noch > mehr (BRAM-)Resourcen - für genau einen fixen Downchirp. Die Verwendung von RAM ist verboten? 1 MSp/s ist ja nun wirklich nicht rekordverdächtig. Wenn du mehrere Chirps speichern willst, nimmst du eben eine SD-Karte oder einen USB-Stick. Selbst billigste SD-Karten schaffen das locker, und auf eine 32GB-Karte für 5 Euro passen ca. 800.000 solcher vorausberechneter 8k-LUT mit 40 Bit je Eintrag.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.