Forum: Digitale Signalverarbeitung / DSP / Machine Learning Echtzeit FFT


von Jan Winter (Gast)


Lesenswert?

Hi,

ich möchte für ein Studienprojekt eine Echtzeit FFT von einem Standard
Audiosignal (16bit 44,1kHz) in Form von einer Hardware umsetzen.

Jetzt habe ich aber noch wenig Ahnung von DSPs und welche Typen es da
so gibt.
Hat von Euch jemand ne Empfehlung welchen ich mir da mal anschauen
sollte?
Bzw schafft ein AVR sowas in Echtzeit?

Jan

von thomas.o (Gast)


Lesenswert?

willst du es jetzt mit einem DSP oder AVR machen. was ist fuer dich
echtzeit??!! Wenn du alle 10 sekunden ein spektrum berechnest, dann
kann das auch echtzeit sein.. wieviele punkte soll deine fft denn
berechnen? davon wird dann auch deine samplingrate und der
speicherbedarf abhaengen. oder willst du das signal auch mit 44,1 kHz
samplen? wie bekommst du die daten?

mfg,
thomas

von Jan Winter (Gast)


Lesenswert?

hi Thomas,

na momentan fang ich gerade an mir zu überlegen, was ich alles
brauche.
Ich will ein monophones Audiosignal analysieren und daraus MIDI Daten
generieren.
Dazu will ich ein qualitativ hochwertiges Signal (16bit 441,kHz)
nehmen, wird wohl n externer AD Wandler liefern (keine Ahnung wie gut
die AD Wandler von DSPs sind, falls DSPs überhaupt welche haben)
Will ich dabei zB noch 1/16 Noten bei 120 bpm erfassen müsste ich schon
alle 125ms ne Analyse haben...
Jetzt halt meine Frage: was für ein DSP schafft sowas, oder kann sowas
noch ein AVR machen (der gleichzeitig dann noch andere Sachen machen
muss...)

Gruß
Jan

von Michael O. (Gast)


Lesenswert?

Hallo Jan,

1) so richtig hochwertig braucht dein Signal ja nicht sein, da du
vermutlich im Spektrum nur ein Maximum suchen willst und das als MIDI
Daten zu transcodieren.

2) um mit voller Geschwindigkeit kontinuierlich FFT's zu berechnen (du
willst vermutlich nicht immer nur einen Happen samplen und dann einige
Sekunden rechnen bevor du wieder neue Eingangsdaten verarbeiten kannst)
benötigst du vermutlich schon einen ausgewachsenen DSP (TI TMS320C67xx
benötigt für Ntaps = 256, cycles = 3696 mit einer vollwertigen
Floatingpoint DSP und single cycle Instructionsausführung). Der AVR
wird damit vermutlich nich klar kommen.

3) Die Länge deines FFT intervalls ist auch noch wichtig. Der Aufwand N
samples zu transformieren ist ~N*log(N). Andererseits schränkst du deine
Frequenzauflösung für tiefe Frequenzen durch ein kurzes Intervall stark
ein.

Vielleicht kannst Du sowas auf einem FPGA programmieren.
Für 99 Tacken bekommt man schon ein Spartan3 EVA-Board von Xilinx
und das WebPack ist eh kostenlos.
Im Internet gibt es auch SPDIF receiver codes so dass du alles in
Echtzeit und komplett alles in Software implementieren könntest.

Gruß
Michael

von Jan Winter (Gast)


Lesenswert?

HI Michael,

ja als Software wäre das am einfachsten, gibts aber auch schon
(WIDI)...
ich hätte halt bock mal was "greifbares" zu haben...
deswegen danke für deinen Tip mit dem TI, mit FPGAs kenn ich mich noch
weniger aus...

Gruß
Jan

von Sebastian (Gast)


Lesenswert?

Ich erinnere mich, dass vor kurzem jemand auf einem AVR eine FFT in C
realisiert hat. Das Ergebnis war echt beeindruckend. Vielleicht hilft
es Dir. Ist in der Codesammlung.

Gruß,
Sebastian

von Sebastian (Gast)


Lesenswert?

Oh, tschuldigung, war in ASM.

http://www.mikrocontroller.net/forum/read-4-159757.html

Nochmals Gruß,
Sebastian

von Alex (Gast)


Lesenswert?

ADSP-21992

14-Bit ADC on-chip

160MHz

16 Bit Festkomma

Der schafft so etwas denke ich ohne Probleme.

von Christian S. (kriki)


Lesenswert?

TI ist gut und recht, aber wer hat bitte schön 2500€ für die
Entwicklungsumgebung !?
Also wenn ich aussuchen müsste, würde ich mich für den FPGA
entscheiden.

von Alex (Gast)


Lesenswert?

Bei Analog-Devices bekommt man eine Vollversion (halbes Jahr Laufzeit)
für lau - ideal für Studien- bzw. Diplomarbeiten.

Das Development-Kit ist erschwinglich.

Nen FPGA halte ich für oversized.

Aber um konstruktiv zu bleiben müsste man einmal direkt Preise,
Software und Einarbeitungsaufwand vergleichen. Das kann aber der
Threadersteller erledigen :-)

von The Daz (Gast)


Lesenswert?

Was du mit Echtzeit meinst ist vermutlich die maximale Verzoegerung vom
Zeitpunkt des Anlegens des Audio-Signals bis zur fertigen Ermittlung
des Grundtons. Im Bereich von Samplern (fuer den umgekehrten Weg : MIDI
in -> Audio out) wuerde ich nicht mehr als 5 msec, maximal 10 msec
akzeptieren. Viele Dinge kommen ja auch nicht schoen genau auf der
16tel Grenze. Oftmals ein bischen hinter dem Takt um einen schoenen
Groove zu kriegen, je nach Material auch gerne 64tel. In 5 msec kriegst
du ca. 220 Samples pro Kanal. Da wird die genaue Ermittlung tiefer
Grundtoene, wie vorhin beschrieben, schon schwieriger, aber nicht
unmoeglich.

von Alex (Gast)


Lesenswert?

Die Frage bleibt auch, wie die Daten mit geeigneter Geschwindigkeit aus
dem DSP zu bekommen sind ...

Dann wird das wohl eher der limitierende Faktor.

von Jan Winter (Gast)


Lesenswert?

hi danke erstma für die vielen Antworten...

also wäre ein FPGA wegen der parallelen Verarbeitung direkt im
Datenstrom angesagt?
Oder is der FPGA doch nich so gut? (hab im FPGA Kochbuch gelesen dass
sie für ne FFT nich so geeignet sein sollen)

Kennt jemand ein gutes Tutorial und einen FPGA der dafür geeignet wäre?

von Alex (Gast)


Lesenswert?

Weil das Rechnen mit den Dingern ein Krampf ist - da sind DSP ALU,
Shifter und Multiplier schon komfortabler.

von Björn (Gast)


Lesenswert?

Die FFT muss man doch nicht per in den FPGA stopfen. Es gibt doch z.B.
von Xilinx den Core-Generator.

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
Noch kein Account? Hier anmelden.