mikrocontroller.net

Forum: Digitale Signalverarbeitung / DSP Hyperbolischer Down-Chirp per IIR?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Burkhard K. (buks)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: nachtmix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Burkhard K. (buks)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Werte sollten eine geometrische Reihe bilden.
Sicher kann man die rekursiv berechnen.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
... 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.

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Burkhard K. (buks)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... 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.

Autor: A. S. (rava)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also die Mathematik sagt:
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
Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-).

Autor: nachtmix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

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.

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