Forum: FPGA, VHDL & Co. Audio-Signal sehr schnell erkennen


von Thomas K. (thomas_k502)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,

ich möchte einen Beep-Ton möglichst schnell erkennen. Anbei zwei Bilder, 
wo ich das Beep-Signal per Rekorder aufgenommen, verstärkt (mit LTSpice 
simuliert) und aufgezeichnet habe. Ist es irgendwie möglich, schon die 
erste Halbwelle des Tons (im besten Fall) direkt zu detektieren? Die 
Frequenz kenne ich und kann damit die Koeffizienten einer Berechnung 
vorher einstellen. Wie mache ich das am besten? Ich muss wohl eine FFT 
in Echtzeit realisieren mit Peak Detektor. Geht das mit einem FPGA 
schnell genug? Habe keine Erfahrung mit den Dingern. Danke für die 
Antworten.

von C. A. Rotwang (Gast)


Lesenswert?

Thomas K. schrieb:

> ich möchte einen Beep-Ton möglichst schnell erkennen. Anbei zwei Bilder,
> wo ich das Beep-Signal per Rekorder aufgenommen, verstärkt (mit LTSpice
> simuliert) und aufgezeichnet habe. Ist es irgendwie möglich, schon die
> erste Halbwelle des Tons (im besten Fall) direkt zu detektieren?

Nein, dazu sind die mikrophone zu träge und die Wandlung Schall -> 
Elektrik zu langsam. Für die elektronische Verarbeitung des Signals 
reicht ein DSP, aber diese ist ohnehin nicht das langsamste Glied in der 
Kette.

Schau dir MEMS Mikrophone an, schneller wirds mit Hobbyistenmitteln 
nicht gehen.

https://learn.sparkfun.com/tutorials/mems-microphone-hookup-guide

Lasermikrophen mit refflektierender Membran sollten auch nicht 
sonderlich schneller sein. Laser scanning rauchmarkierter Strömung 
schon, aber du wirst wahrscheinlich nicht zur Detektion Rauchstäbchen 
abfackeln wollen.

von Wolfgang (Gast)


Lesenswert?

Thomas K. schrieb:
> Ich muss wohl eine FFT in Echtzeit realisieren mit Peak Detektor.

Wenn du die Frequenz kennst, brauchst du doch gar nicht das ganze 
Spektrum. In deinem Fall sollte der Görtzel Algorithmus ausreichen.
Beitrag "Görtzel Algorithmus einfach erklärt"

von Stefan S. (chiefeinherjar)


Lesenswert?

Die Anforderung "sehr schnell" ist zu schwammig. Was ist "sehr schnell"?
Im einfachsten Fall einfach einen (bzw. ggf. zwei) Komparator nehmen und 
jeweils die Schaltschwelle so setzen, dass eben nur der Beep den 
Komparator auslöst. Ganz ohne FPGA. Das funktioniert natürlich nur bei 
ausreichend großem SNR. Ansonsten, ja ein FPGA KÖNNTE vielleicht schnell 
genug sein. Vielleicht auch nicht... Man weiß es nicht...

von Michael B. (laberkopp)


Lesenswert?

Thomas K. schrieb:
> Ist es irgendwie möglich, schon die
> erste Halbwelle des Tons (im besten Fall) direkt zu detektieren

Theoretisch ja, praktisch unterscheidet sie sich kaum von der Störungen 
vorweg, also wird jede grössere Störung auch auslösen.

Zur Störsicherheit also eine blöde Idee.

Zwar hilft es, die Nulldurchgänge zeitlich zu bewerten damit nur Signale 
der richtigen Frequenz erkannt werden, aber auch hier muss man abwägen 
zwischen Störungen (falsche Frequenz) und 
Nulldurchgangszeitverschiebungen des richtigen Signals durch 
beigemischte Störungen wie Rauschen, was natürlich durch 
Mittelwertbildung über mehrere Halbwellen viel besser filterbar wäre.

Hättest du vor dem Signal wirklich Ruhe. wäre das siche rbesser.

Thomas K. schrieb:
> Geht das mit einem FPGA schnell genug?

Für Tonfrequenz reicht ein uC.

von Max M. (jens2001)


Lesenswert?

Thomas K. schrieb:
> schon die
> erste Halbwelle

Natürlich kannst du die erste Halbwelle detektieren!
Doch ob danach wirklich ein Beep kommt, ein Rauschen oder einfach 
garnichts, kannst du nur entscheiden wenn deine Aperatur hellseherische 
Fähigkeiten hat!
Und dabei nützt dir die schnellste FFT nichts.
Mach dir mal Gedanken über Logik, Kausalität, Physik und Mathematik.

von Wolfgang (Gast)


Lesenswert?

Thomas K. schrieb:
> ich möchte einen Beep-Ton möglichst schnell erkennen.

Möglichst schnell dürfte es sein, wenn du die Ansteuerung von dem 
Signalgeber anzapfst, also in der Signalkette noch bevor ein Ton draus 
gemacht wird ;-)

von Michael62 (Gast)


Lesenswert?

Ein Filter braucht eine Periodizität, eine FFT auch.

Eine Faltung wäre denkbar, aber der Störabstand bei einer Halbwelle 
dürfte 3db betragen, maximal.

Das könnte zur Detektion eventuell ausreichen, aber dann muss der 
Signal-Nutzabstand entsprechend sein.

Einfacher wird es, wenn du eine zusätzliche Information, zB ein zweites 
Mikro ins Spiel nimmst.

von Thomas K. (thomas_k502)


Lesenswert?

Danke für die Antworten. Wenn es nicht so schnell machbar ist dann eben 
so schnell es geht. Fakt ist aber das ich ein Rechensystem benötige. 
Dann wohl am besten ein Audio DSP.

Stefan S. schrieb:
> Die Anforderung "sehr schnell" ist zu schwammig.

Ich denke eine Millisekunde sollte noch akzeptabel sein.

C. A. Rotwang schrieb:
> Schau dir MEMS Mikrophone an, schneller wirds mit Hobbyistenmitteln
> nicht gehen.

Dann werde ich das ganze mit einem MEMS machen.

Wolfgang schrieb:
> "Görtzel Algorithmus einfach erklärt"

Der Algorithmus hört sich gut vielversprechend an.

Michael62 schrieb:
> Eine Faltung wäre denkbar, aber der Störabstand bei einer Halbwelle
> dürfte 3db betragen, maximal.

Du meinst vermutlich das korrelationsintegral. Das sollte auch 
funktionieren, oder eine Mittelwertbildung.

von Gustl B. (-gb-)


Lesenswert?

Thomas K. schrieb:
> Ich denke eine Millisekunde sollte noch akzeptabel sein.

Das ist auch noch schwammig. Bei 1kHz ist das eine Periodendauer, da 
fällt FFT schon raus und vieles Andere auch.

Was weißt Du denn sonst noch über das zu erkennende Signal? Frequenz? 
Lautstärke/SNR?

von Strubi (Gast)


Lesenswert?

Was hier wieder alles in den Raum geworfen wird...
Goertzel ist dafür völlig ausreichend und auch einen DSP braucht's dafür 
nicht zwingend, ein STFM* tut's völlig. Die Frage ist schlussendlich 
nur, welche Frequenz man über welches Fenster auswerten will, oder: 
Phaseninfo versus Amplitudeninfo. Dazu kannst du auch mehrere IIR 
parallel laufen lassen um deinen "Ping" optimal (so früh und zuverlässig 
wie die Signaltheorie eben erlaubt) zu detektieren.

von Thomas K. (thomas_k502)


Lesenswert?

Danke für die Antworten.

Gustl B. schrieb:
> Was weißt Du denn sonst noch über das zu erkennende Signal? Frequenz?
> Lautstärke/SNR?

Frequenz ist fest, normal 1,5kHz oder 4 kHz. Gain/SNR richtet sich nach 
dem Mikrofon, welches ich erst bestelle, sobald ich weiß ob das alles 
funktioniert oder nicht.

Strubi schrieb:
> Goertzel ist dafür völlig ausreichend und auch einen DSP braucht's dafür
> nicht zwingend, ein STFM* tut's völlig.

Mit STMs habe ich keine gute Erfahrung. Mit einem STM32F4 habe ich mal 
Audioprocessing gemacht und festgestellt, das er recht langsam ist. Dazu 
muss ich erwähnen, dass ich mir nicht alle Taktzyklen in Assembler 
zwischen den 48k Interrupts angeschaut habe um auf Fehlersuche zu gehen. 
Jedenfalls traue ich der Sache nicht.

von Strubi (Gast)


Lesenswert?

Hi Thomas,

>
> Mit STMs habe ich keine gute Erfahrung. Mit einem STM32F4 habe ich mal
> Audioprocessing gemacht und festgestellt, das er recht langsam ist. Dazu
> muss ich erwähnen, dass ich mir nicht alle Taktzyklen in Assembler
> zwischen den 48k Interrupts angeschaut habe um auf Fehlersuche zu gehen.
> Jedenfalls traue ich der Sache nicht.

48'000 Interrupts pro Sekunde? Damit bremst du den Chip aber unnötig 
aus. Für sowas gibt's DMA..
Sonst könnte ich noch die guten alten Blackfins empfehlen. Aber auch 
hier gilt wieder: nicht mit Float-Arithmetik um sich schmeissen (falls 
du das beim STM so gemacht haben solltest), sonst wird's langsam.
Die kleinen BF592 gibt's ab wenigen USD, falls der Preis ein Kriterium 
sein sollte.

von Duke Scarring (Gast)


Lesenswert?

Die Aufgabe klingt aber nicht nach aufwändgem Audioprozessing.
Ein Pegeldetektor + Nulldurchgrangserkennung mit Fensterkomparator 
(Frequenz zu hoch/ zu niedrig) + Zähler für die Mindestzeit sollte die 
Aufgabe erfüllen können. Ggf. vorneweg noch einen analogen Bandpass...

Sowas war früher in jedem 0815-Heimcomputer drin, der seine Programme 
auf Kompaktkassette bzw. Datasette gespeichert hat.

Duke

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Gustl B. schrieb:
> Was weißt Du denn sonst noch über das zu erkennende Signal? Frequenz?
> Lautstärke/SNR?
Die SNR würde mich auch interessieren...
Sieht das empfangene Signal tatsächlich so aus wie dort oben im 
Screenshot? Oder muss man sich da noch ein startendes Flugzeug 
dazudenken, und irgendwo in diesem Lärm piepst einer mit 1,5 oder 4kHz 
vor sich hin?

Ich frage da nur, weil ich noch die alten Ultraschallfernbedienungen 
kenne, die man mit den Klimpern des Schlüsselbunds zum Umschalten 
bringen konnte...

: Bearbeitet durch Moderator
von Amateur (Gast)


Lesenswert?

Das Hauptproblem ist und bleibt die Frage: Was ist ein Ton?

Das schlagen einer Tür, Händeklatschen oder wenn Du etwas empfindlicher 
wirst, das Tippeln einer Maus hinter dem Schrank.

Willst Du aber nur den Toni, der aus Deinem Piepser kommt begrüßen, so 
heißt das: "Filtern" - und zwar gut.

Dumm ist dabei nur, dass die meisten Filter das Ganze langsam machen...

von J. S. (engineer) Benutzerseite


Lesenswert?

Duke Scarring schrieb:
> Die Aufgabe klingt aber nicht nach aufwändgem Audioprozessing.
> Ein Pegeldetektor + Nulldurchgrangserkennung mit Fensterkomparator
> (Frequenz zu hoch/ zu niedrig) + Zähler für die Mindestzeit sollte die
> Aufgabe erfüllen können. Ggf. vorneweg noch einen analogen Bandpass...

Klar, um das Signal als solches zu erkennen - aber die Frage ist ja 
immer, gegen was Ich das Signal alles abgrenzen will.

Gegen eines mit 10% höherer Geschwindigkeit im Amplitudenverlauf?

Gegen eines mit einem etwas anderen Amplitudenverlauf?

Gegen eines mit einem etwas anderen Frequenzverlauf?

Wie hoch also sind die Störeinflüsse?

Und wie stabil ist der Beep?

Ein "beep" im Ultraschallbereich, der von einem sich bewegenden Objekt 
ausgesendet wird und /oder von einem bewegten Empfänger empfangen wird, 
braucht schon eine Betrachtung im Frequenzbereich oder eine sehr präzise 
Annahme der Bewegung mit Beam Forming und - Streching der Daten im 
Zeitbereich, um es direkt prozessieren zu können.

Wenn es - wie die Zeichnung suggeriert - nur "beep" und "nicht beep" 
gibt, dann braucht es nur zwei Tiefpässe, einen Komparator und eine 
Gleichrichtung + Verstärkung.

: Bearbeitet durch User
von Thomas K. (thomas_k502)


Lesenswert?

Ja es gibt nur ein "beep" und ein "nicht beep" in einem statischen Raum, 
also es bewegt sicht nichts, das Mikro wird vorher fest angebracht in 
Nähe des Beepers und wartet dann bis der kommt. Die Störeinflüsse 
entstehen also nur durch eine "ruhige" Umgebung ohne sonstige Quellen 
bis auf normales Rauschen, kein lauter Krach oder sonst was. Allerdings 
gibt es im Umfeld noch etwas RFID das ich vielleicht einfach mit einer 
Spule am Eingang herausnehme und die Leitung des Mikros abschirme. Weiß 
nicht in wieweit das Auswirkungen auf das Audio-Empfangssignal hat. Wie 
stabil der Beep ist kann ich leider nicht genau sagen. Ah und noch was, 
das oben aufgeführte Signal habe ich einfach mit meinem Smartphone 
aufgenommen. Das wird wohl über ein Elektret oder MEMS realisiert.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Was passiert, wenn du irrtümlich triggerst?
Geht dann etwas kaputt? Oder ist das teuer?
Falls nein: nimm einen simplen Schwellwertschalter.

von Thomas K. (thomas_k502)


Lesenswert?

Lothar M. schrieb:
> Was passiert, wenn du irrtümlich triggerst?

Dann ist die Messung hinüber und muss wieder durchgeführt werden.

Es wird wohl darauf auslaufen, die komplette Zeitspanne in einen PC 
einzulesen und danach die Verarbeitung dort durchzuführen. Dann muss es 
nicht in Echtzeit gemacht werden und wird nicht unnötig teuer. Ich muss 
das Signal dann eigentlich nur weiterschleifen bis zu einem AD Wandler. 
Die Schaltung werde ich analog aufbauen und, wenn sie mit LTSpice fertig 
simuliert ist, ins Forum stellen um mir Meinungen anzuhören.

von Michael B. (laberkopp)


Lesenswert?

Thomas K. schrieb:
> Ich denke eine Millisekunde sollte noch akzeptabel sein.

Das wären 13 Nulldurchgänge bei deinem gezeigten Signal, das schafft 
noch ein NE567 der auf 'schnelle Erkennung' dimensioniert ist.

Thomas K. schrieb:
> Frequenz ist fest, normal 1,5kHz oder 4 kHz.

Das ist viel weniger, nur 3 bzw 8 Nulldurchgänge, das macht die Sache 
deutlich schwerer.

WARUM KANN KEIN SCHWEIN WENIGSTENS MAL EINE ORDENTLICHE 
PROBLEMBESCHREIBUNG LIEFERN ?!?

Die Nulldurchgänge lassen sich hinreichend genau mit einem stinknormalen 
uC zeitlich bestimmen, dazu gibt es ja extra input capture Kanäle. Bloss 
die statistische Wahrscheinlichkeit, daß auch im Rauschen Nulldurchgänge 
in dem Zeitabstand zu finden sind, ist natürlich bei nur 3 im Abstand 
von 333us+/-33us eher hoch, bei 13 im Abstand von 76us+/-7us wären 
Fehlerkennungen schon fast 0.

: Bearbeitet durch User
von Gustl B. (-gb-)


Lesenswert?

Also bei großem SNR sollte das problemlos und sehr schnell mit 
Pegelerkennung funktionieren. Sowohl analog als aus digital mit den 
Samplewerten hinter dem Mikrophon.

von Martin K. (mkmannheim) Benutzerseite


Lesenswert?

Kann man nicht einfach die Spitzen des Signals detektieren und mit der 
Frequenz vergleichen? Ein Sinus, also die Grundwelle, wird verknüpft mit 
diesen Punkten eine gute  Korrelation aufweisen.

von J. S. (engineer) Benutzerseite


Lesenswert?

Das wäre eine Art diskrete Faltung im Digitalen. Im Prinzip macht man es 
ja eigentlich auch so, nur eben nicht nur fpr die "Spitzen" sondern die 
gesamte Kurve. Je mehr Punkte man innerhalb einer Betrachtungsperiode 
zwischen Soll und Ist vergleicht (multipliziert), desto störungssicher 
wird es.

von Thomas K. (thomas_k502)


Lesenswert?

Ja deswegen. Ich werde mich mal melden wenn es wieder was neues gibt. :)

von Joe F. (easylife)


Lesenswert?

Thomas K. schrieb:
> das Mikro wird vorher fest angebracht in
> Nähe des Beepers und wartet dann bis der kommt.

Was heisst denn "in Nähe des Beepers" in Zentimetern?
Ich frage deshalb, weil es kaum Sinn mach sich Gedanken über Erkennung 
des Signals anhand einer oder weniger Halbwellen hinzubekommen, wenn der 
Schall vom Beeper bis zum Mikrofon naturbedingt 3 ms pro Meter 
benötigt...

Und wenn man ganz an den Beeper rankommt, wäre evtl. eine direkte 
elektrische Ankoppelung an das Beeper-Signal möglich (z.B. induktiv). 
Dann erübrigt sich auch das Problem mit den Störgeräuschen...

Was mir auch nicht 100% klar ist: sollen hier 2 Töne (Frequenzen) 
unterschieden werden, oder geht es allein um die Erkennung eines 
Piepstones mit nur einer Frequenz?

: Bearbeitet durch User
von Wolfgang (Gast)


Lesenswert?

Martin K. schrieb:
> Kann man nicht einfach die Spitzen des Signals detektieren und mit der
> Frequenz vergleichen?

Das ist wie mit Aktienkurven - ob es eine Spitze war, weisst du erst 
hinterher. Bei einer Halbwelle als angestrebtem Zeitfenster zur 
Erkennung bleibt da nicht viel "hinterher".

von Thomas K. (thomas_k502)


Lesenswert?

Hallo,

Joe F. schrieb:
> Und wenn man ganz an den Beeper rankommt, wäre evtl. eine direkte
> elektrische Ankoppelung an das Beeper-Signal möglich (z.B. induktiv).
> Dann erübrigt sich auch das Problem mit den Störgeräuschen...


Das ist leider nicht möglich, da der Beeper in einem festen Gehäse sitzt 
und man nicht genau weiß, wo genau.

>
> Was mir auch nicht 100% klar ist: sollen hier 2 Töne (Frequenzen)
> unterschieden werden, oder geht es allein um die Erkennung eines
> Piepstones mit nur einer Frequenz?

Es ist nur eine einzige Frequenz.

von Joe F. (easylife)


Lesenswert?

Thomas K. schrieb:
> Es ist nur eine einzige Frequenz.

Dann werte einfach die Amplitude des Signals aus (über Schwellwert -> 
beep detektiert).

von rbx (Gast)


Lesenswert?

Was ich mich frage ist: in welchem Zusammenhang schnell.
Erinnerung: Beitrag "schneller ADC gesucht"

Analog: schneller als der Schall geht erst mal nicht. Also zuerst große 
Lautsprechermembran (mit vielen Häärchen) aufstellen?

Erinnerung2: die Emu Sampler (ab emax2) hatten einen schnelle 
Auto-Sample-
schaltung, die hatte Soundtechnisch nicht weh getan (Rumms der Bassdrum, 
Schnapp der Snare noch voll da).
(und wenn man den Rhythmus kennt, oder hier Erkennung betreibt, dann 
könnte man das Sample selber starten (z.B. 1 Sekunde vorher, falls das 
die Speicherökonomie mitmacht (soll das Sample deswegen schnell sein?)
(zur Not Hallalgo o.ä.)

Eine andere Frage wäre noch, ob eine man etwas Alternatives überlegen 
sollte, die Schallquelle in eine überwachte Umgebung (beschallen, 
einfärben) bringen oder ob Erschütterungsmessungen gehen (bei Karnickeln 
beliebt) usw.

von Joe F. (easylife)


Lesenswert?

rbx schrieb:
> ...

Manche Druffi-"Beiträge" möchte man eigentlich persönlich sofort löschen 
dürfen um anderen die Zeitverschwendung zu ersparen.

von Audiomann (Gast)


Lesenswert?

Dem kann man nur zustimmen! Der Autor rbx wirft hier Sachen rein, die 
mit der Fragestellung nichts zu tun haben und zudem scheint er einiges 
Verdächtiges konsumiert zu haben, wenn man den Satz liest:

> Eine andere Frage wäre noch, ob eine man etwas Alternatives überlegen
> sollte, die Schallquelle in eine überwachte Umgebung (beschallen,
> einfärben) bringen oder ob Erschütterungsmessungen gehen (bei Karnickeln
> beliebt) usw.

Ja,ja die bei Kanickeln so beliebte Schallquellenbeschallung zur 
Überwachung der Färbung ...

Zu dem e-MU kann man nur sagen, daß ein sampling in dieser Weise 
vollkommen offline geschieht, d.h. die Daten sind im Speicher und können 
beliebig rückblickend erfasst werden. Das ist wohl kaum die Lösung der 
Aufgabe und wenn doch, sollte man dem TE nochmals die Frage stellen, ob 
hier wirklich ein Audiosignal schnell erkannt werden soll oder ob ein 
schnelles Audiosignal erkannt werden soll.

Kurze Audiosignale können nämlich nicht mal vom Ohr erfasst werden. So 
ein kurzer Beep von nur einer oder zwei Wellen sind auch nichts anderes 
als ein Knack.

von rbx (Gast)


Lesenswert?

Audiomann schrieb:
> Zu dem e-MU kann man nur sagen, daß ein sampling in dieser Weise
> vollkommen offline geschieht

Nein, wie am Rekorder startest du die Aufnahme und die Kunst der 
Autoschaltung ist soviel vom Eingangssignal mitzunehmen, wie geht - das 
ist Echtzeit, wie auch die sehr gut klingenden Digitalfilter ab emax2 
zur Nachbearbeitung in Echtzeit verstellbar/nutzbar waren.

Offline waren dagegen bestimmte Algorithmen, wie das Umrechnen der 
Samplefrequenz oder ein "Verschmelzen" der Samples

von Audiomann (Gast)


Lesenswert?

> die Kunst der Autoschaltung ist soviel vom Eingangssignal
> mitzunehmen wie geht
???

Seit wann wird "soviel wie geht" mitgenommen?

Und nochmal: Bei einem Sampler wird das Audiosignal total aufgezeichnet 
und der Trigger kontinuierlich appliziert. D.h. man kann "nach hinten" 
schauen, wie bei einem Oszilloskop. Das hat nichts mit Echtzeit zu tun.

von Pandur S. (jetztnicht)


Lesenswert?

Es ist relativ einfach eine gesendete Frequenz wieder zu erkennen. 
Einfach alles was kommt mit Sin & Cos dieser Frequenz multiplizieren und 
tiefpassen/integrieren. Dann ein Komparator hinten dran und gut ist.

von Weltbester Signalverarbeiter (Gast)


Lesenswert?

Sapperlot W. schrieb:
> Es ist relativ einfach eine gesendete Frequenz wieder zu erkennen.
> Einfach alles was kommt mit Sin & Cos dieser Frequenz multiplizieren und
> tiefpassen/integrieren. Dann ein Komparator hinten dran und gut ist.

also auch mit Gleichanteil, Frequenzoffset und ohne Rücksicht auf 
Kontinuität, etwaitger Fensterung oder anderer Optionen zur 
Unterdrückung von Störung drauflos integrieren/tiefpassen.

Was kommt denn dann bei raus?

Was ist denn dann das Kriterium für das Vorhandensein des Signal?

Mann, Mann, Mann, heute haben die Chefberater Ausgang.

von Duke Scarring (Gast)


Lesenswert?

Weltbester Signalverarbeiter schrieb:
> also auch mit Gleichanteil,
Der wird bei der IQ-Demodulation rausgefiltert.

> Frequenzoffset
Sorgt für eine verringerte Amplitude (je nach Bandbreite).

> und ohne Rücksicht auf Kontinuität,
Was interessiert den Komparator die Kontinuität?

> etwaitger Fensterung oder anderer Optionen zur
> Unterdrückung von Störung drauflos integrieren/tiefpassen.
Der Problemsteller hat angeblich keine Störungen ;-)

> Was kommt denn dann bei raus?
YGWYPF

von Weltbester FPGA-Pongo (Gast)


Lesenswert?

Duke Scarring schrieb:
> Weltbester Signalverarbeiter schrieb:
>> also auch mit Gleichanteil,
> Der wird bei der IQ-Demodulation rausgefiltert.
Abgesehen davon, daß hier noch nicht die Rede von einer IQ-Behandlung 
war, ist es nicht so, daß der Gleichanteil weggeht. Wie kommst Du 
darauf?


>> Frequenzoffset
> Sorgt für eine verringerte Amplitude (je nach Bandbreite).
Sorgt vor allem für eine schlechtere Erkennbarkeit


>> und ohne Rücksicht auf Kontinuität,
> Was interessiert den Komparator die Kontinuität?
Weil eine Korrelation ermittelt wird, die nicht exisitert.

>> etwaitger Fensterung oder anderer Optionen zur
>> Unterdrückung von Störung drauflos integrieren/tiefpassen.
> Der Problemsteller hat angeblich keine Störungen ;-)
Wenn Ich mir die Signale ansehe, hat er die durchaus.


> Was kommt denn dann bei raus?
> YGWYPF
Es geht darum, daß irgendwo noch ein Vergleich oder ein Kriterium her 
muss. Also wenigstens ein "Ist Signal gross genug" denn die schlaueste 
Filterung wird immer aufgrund des Rauschens irgendwas rausgegeben.

Und da stellt sich sofort die Frage, ob nicht bei der ersten Welle - 
ganz ohne Extrem SV - eine einfache Abfrage reicht.

von Duke Scarring (Gast)


Lesenswert?

Weltbester FPGA-Pongo schrieb im Beitrag #5019538:
>>> also auch mit Gleichanteil,
>> Der wird bei der IQ-Demodulation rausgefiltert.
> Abgesehen davon, daß hier noch nicht die Rede von einer IQ-Behandlung
> war, ist es nicht so, daß der Gleichanteil weggeht.

Sapperlot W. schrieb:
> Einfach alles was kommt mit Sin & Cos dieser Frequenz multiplizieren
> und tiefpassen/integrieren.
Das ist die Umschreibung für IQ-Demodulation...

Weltbester FPGA-Pongo schrieb im Beitrag #5019538:
> Wie kommst Du darauf?
BTDT.

> Es geht darum, daß irgendwo noch ein Vergleich oder ein Kriterium her
> muss. Also wenigstens ein "Ist Signal gross genug"
Richtig, ich wollte nicht auf den Komparator verzichten.

> denn die schlaueste
> Filterung wird immer aufgrund des Rauschens irgendwas rausgegeben.
Der richtige Schwellwert wäre zu ermitteln. Ein guter Startwert wäre 
z.B. die Hälfte vom Beep-Maximum.

> Und da stellt sich sofort die Frage, ob nicht bei der ersten Welle -
> ganz ohne Extrem SV - eine einfache Abfrage reicht.
Die Frage ist definitiv berechtigt und m.E. wurde der 'analoge' Weg 
weiter oben schon erörtert.

Der TO könnte ja evtl. die Beispieldatei (.wav) zur Verfügung stellen 
und die Sollfrequenz nennen. Dann kann der geneigte Mitleser das Ganze 
in einem Simulator seiner Wahl (analog/digital) durchexerzieren.

Duke

von Christian Erker (Gast)


Lesenswert?

Nur mal eine grundsätzliche Frage ...

Musst du innerhalb von 1ms reagieren oder willst du nur den 
Startzeitpunkt auf 1ms genau wissen und es ist in Ordnung wenn du diese 
Information mit etwas Verzögerung bekommst?

Das sind 2 völlig verschiedene Problemstellungen.

Solltest du meinen sofort reagieren zu müssen .. warum? Wenn du z.b. 
Synchron einen anderen Wert messrn musst, könntest du diese Messung 
einfach ständig vornehmen und in einen Ringpuffer in so 1.5-2facher 
Länge der zu erwartenden Latenz schreiben um dir dann später den 
passenden Wert zu holen.

Nur so als Gedankenanstoß.

Gruß Christian

von Thomas K. (thomas_k502)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,

Christian Erker schrieb:
> Musst du innerhalb von 1ms reagieren oder willst du nur den
> Startzeitpunkt auf 1ms genau wissen und es ist in Ordnung wenn du diese
> Information mit etwas Verzögerung bekommst?

Der Beep triggert das Ende einer kontaktlosen Transaktion, die etwa 100 
ms andauert. Um eine Zeitmessung durchzuführen, muss man diesen Beep so 
schnell/exakt wie es geht erkennen. Reicht das als Information?

Duke Scarring schrieb:
> Der TO könnte ja evtl. die Beispieldatei (.wav) zur Verfügung stellen
> und die Sollfrequenz nennen. Dann kann der geneigte Mitleser das Ganze
> in einem Simulator seiner Wahl (analog/digital) durchexerzieren.

Klar die .wav Datei habe ich angeheftet. Zu diesem Beispiel habe ich 
leider nicht die Unterlagen der exakten Frequenz aber sie müsste bei 
rund 4,3 kHz liegen.

von Joe F. (easylife)


Angehängte Dateien:

Lesenswert?

Das Gerumpel am Ende der Aufnahme ist ja vermutlich nicht der Regelfall.
Anbei eine Idee mit einem Bandpass-Filter und einem Komparator.

Die Verzögerung von der ersten sichtbaren Signalwelle bis DETECT=high 
ist je nachdem wie tief man die Schwelle einstellt so ab ca. 1.2ms 
anzunehmen.
Je tiefer die Schwelle, desto schneller die Erkennung.
Mit tieferer Schwelle werden aber auch Fehltriggerungen 
wahrscheinlicher.

R9/R8 ist idealerweise ein Poti und vor dem Filter kommt eine 
entsprechende Pegelanpassung rein.

von Audiomann (Gast)


Lesenswert?

Welches Prog ist das?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Audiomann schrieb:
> Welches Prog ist das?
LT-Spice. Ein Elektronik-Simulator.

von Weltbester FPGA-Pongo (Gast)


Lesenswert?

Duke Scarring schrieb:
> Weltbester FPGA-Pongo schrieb im Beitrag #5019538:
>> Wie kommst Du darauf?
> BTDT.

Ich muss da nochmal einhaken: Habe es mal durchprobiert und ein 
Offset-belastetes Signale mit sin und cos prozessiert (mit Fenster) - 
das Ergebnis ist leicht vom Offset abhängig.

?

von J. S. (engineer) Benutzerseite


Lesenswert?

Weltbester FPGA-Pongo schrieb im Beitrag #5119168:
> Ich muss da nochmal einhaken: Habe es mal durchprobiert und ein
> Offset-belastetes Signale mit sin und cos prozessiert (mit Fenster) -
> das Ergebnis ist leicht vom Offset abhängig.

Welches Fenster?


Audiomann schrieb:
> Kurze Audiosignale können nämlich nicht mal vom Ohr erfasst werden. So
> ein kurzer Beep von nur einer oder zwei Wellen sind auch nichts anderes
> als ein Knack.
Bei hohen Frequenzen ja aber bei Bässen ist oft die (deformierte) Welle 
selbst das alleinige Signal. Solche Dingen müssen bei einer Fensterung 
auch betrachtet werden.

von Weltbester FPGA-Pongo (Gast)


Angehängte Dateien:

Lesenswert?

@jurgen
Ist mit und ohne Festner so

@duke:
In der linken Spalte ist ein Signal ohne Offset in der rechten mit 
Offset.
Sowohl bei den einzelnen Multiplikationen als auch den Summen gibt es 
andere Werte (orange und blau).

von Duke Scarring (Gast)



Lesenswert?

Ich hab jetzt mal Zeit gefunden, die Sache in VHDL durchzuziehen.

Weltbester FPGA-Pongo schrieb im Beitrag #5119168:
> Ich muss da nochmal einhaken: Habe es mal durchprobiert und ein
> Offset-belastetes Signale mit sin und cos prozessiert (mit Fenster) -
> das Ergebnis ist leicht vom Offset abhängig.
Mea culpa. Natürlich ist der Betrag vom Offset abhängig, alles andere 
wäre Quatsch. Bei meinen Realisierungen ist immer ein Hochpass davor, 
bevor es mit der Demodulation weitergeht.

Die digitale Signalverarbeitung kann auch nicht zaubern.
Ziel ist es doch das Nutzsignal vom Störsignal zu trennen.

Dazu werden die folgenden Schritte durchgeführt:
- Hochpass
- IQ-Demodulation mit Betragsbildung
- Tiefpass (gleitender Mittelwert) und
- Komparator mit Hysterese

Es gibt ein paar Parameter an denen man hier spielen kann:
- Referenzfrequenz für die Demodulation
- Länge des Tiefpassfilters
- Komparatorschwellen

Joe F. schrieb:
> Je tiefer die Schwelle, desto schneller die Erkennung.
> Mit tieferer Schwelle werden aber auch Fehltriggerungen
> wahrscheinlicher.
Das gilt hier auch.
Und der Knackser bei ca. 4 Sekunden triggert auch.

Joe F. schrieb:
> Die Verzögerung von der ersten sichtbaren Signalwelle bis DETECT=high
> ist je nachdem wie tief man die Schwelle einstellt so ab ca. 1.2ms
> anzunehmen.
Das deckt sich witzigerweise ziemlich gut mit der digitalen 
Realisierung...

Duke

P.S.: Das Ursprungsproblem würde ich trotzdem nicht mit einem FPGA 
lösen. Es sei denn es gibt Randbedingungen, die der TO verschwiegen hat.

von Nils P. (torus)


Lesenswert?

Thomas K. schrieb:
> Der Beep triggert das Ende einer kontaktlosen Transaktion, die etwa 100
> ms andauert. Um eine Zeitmessung durchzuführen, muss man diesen Beep so
> schnell/exakt wie es geht erkennen. Reicht das als Information?

Ah! Jetzt weis ich, worum es geht.

Da Du offensichtlich die Prüfgerät Seite eines EMVCo Level-2 Tests 
implementierst musst Du Dir keine großen Sorgen machen. Die 5 bis 10 
Millisekunden Extrazeit, die die Erkennung des Pieps braucht haben alle 
EMVCo Prüfgeräte.

Das ist natürlich für den Kreditkarten Terminal Hersteller blöd, weil 
nicht zu seinen Gunsten gemessen wird, aber da muss er durch.

Zum Thema, wie schon geschrieben:

Multiplizier das Eingangssignal mit sin und cos der erwarteten Frequenz 
und errechne über die Quadratwurzel die Amplitude. Wenn sie nach einer 
Millisekunde (länger, dann genauer) nicht unter deinen Schwellwert 
fällt, dann triggerst Du.

: Bearbeitet durch User
von Duke Scarring (Gast)



Lesenswert?

Nils P. schrieb:
> Multiplizier das Eingangssignal mit sin und cos der erwarteten Frequenz
> und errechne über die Quadratwurzel die Amplitude.
Das reicht tatsächlich nur um die Amplitude zu bestimmen. Genauso hab 
ich das oben gemacht. Ich war der Meinung, das das auch als Bandpass 
wirkt. Nachdem ich mir die Transferfunktion angeschaut habe, mußte ich 
meine Meinung revidieren.

Sinnvoll wird das Ganze, wenn man die Werte für eine gewisse Zeit 
aufintegriert (Vielfache der Periodendauer des Referenzsignals) und 
damit die Korrelation zum Referenzsignal ermittelt.

Damit kann man auf Hochpass und Mittelung (=Tiefpass) verzichten und 
bekommt trotzdem brauchbare Ergebnisse.

In der angehangenen Realisierung gibt es drei Parameter zum Spielen:
- Referenzfrequenz (ref_frequency)
- Integrationszeit (count_max) und
- Schwellwert

Duke

von Weltbester FPGA-Pongo (Gast)


Lesenswert?

Duke Scarring schrieb:
> Mea culpa. Natürlich ist der Betrag vom Offset abhängig, alles andere
> wäre Quatsch.
Hört hört! :D

Nur wie ist das zu erklären? Der Gleichanteil ist doch Frequenz 0.

> Sinnvoll wird das Ganze, wenn man die Werte für eine gewisse Zeit
> aufintegriert

Wie verhält es sich dann mit der Forderung:

"Audio-Signal sehr schnell erkennen"?

von Duke Scarring (Gast)


Lesenswert?

Weltbester FPGA-Pongo schrieb im Beitrag #5232542:
> Nur wie ist das zu erklären? Der Gleichanteil ist doch Frequenz 0.
Ich stelle mir das als Zeiger in einem zweidimensionalen Diagramm vor. 
Auf der X-Achse ist der Realteil abgebildet und auf der Y-Achse der 
Imaginärteil. Hier interessiert die Amplitude, die Länge des Zeigers, 
der um den Nullpunkt kreiselt. Ein Gleichanteil bzw. Offset ist eine 
Nullpunktverschiebung auf der X-Achse. Damit ändert sich die Länge des 
umlaufenden Zeigers permanent.

>> Sinnvoll wird das Ganze, wenn man die Werte für eine gewisse Zeit
>> aufintegriert
> Wie verhält es sich dann mit der Forderung:
> "Audio-Signal sehr schnell erkennen"?
Bei dieser Variante muss man Kompromisse eingehen: Sichere Erkennung vs. 
Geschwindigkeit. Je kürzer die Integration läuft, desto schlechter ist 
die Güte des Bandpasses. Damit wird man empfindlicher auf Störungen.

Bei der Realisierung beep_detection_cc.vhd liegt man jetzt bei ca. 600 
µs.
Dort käme bei einer FPGA-Realisierung noch die Latenz durch die 
Betragsbildung dazu.

Duke

von Thomas K. (thomas_k502)


Lesenswert?

Hallo zusammen,

ich habe das Ganze anders gelöst, womit ich ein sehr gutes Ergebnis 
erreicht habe. Ich habe den Sound über die erforderliche Zeitspanne 
eingelesen, abgespeichert und dann eine Analyse durchgeführt. Ich bin 
dabei den Weg über sin und cos gegangen, allerdings ist die Berechnung 
nun nicht in Echtzeit mit einem Verarbeitungssystem realisiert, sondern 
über einen PC. Da man die Daten im PC abliegen hat, kann man nach der 
Messung auch numerische Berechnungen durchführen, um die Effizienz zu 
steigern. Wäre ich den anderen Weg gegangen, hätte ich die Erkennung auf 
einem STM mit den vorgeschlagenen Algorithmen implementiert.

Duke Scarring schrieb:
> Ich hab jetzt mal Zeit gefunden, die Sache in VHDL durchzuziehen.

Danke für den Aufbau, falls das Projekt wieder aufgegriffen wird, kann 
man es vielleicht so machen.


Nils P. schrieb:
> Da Du offensichtlich die Prüfgerät Seite eines EMVCo Level-2 Tests
> implementierst musst Du Dir keine großen Sorgen machen. Die 5 bis 10
> Millisekunden Extrazeit, die die Erkennung des Pieps braucht haben alle
> EMVCo Prüfgeräte.

Genau darum geht es! Allerdings liegt der Toleranzbereich um 1 ms.

Duke Scarring schrieb:
> Bei dieser Variante muss man Kompromisse eingehen: Sichere Erkennung vs.
> Geschwindigkeit. Je kürzer die Integration läuft, desto schlechter ist
> die Güte des Bandpasses. Damit wird man empfindlicher auf Störungen.

Das ist richtig, jedoch hat man ja die Parameter, mit denen man spielen 
kann, um es effizient zu machen.

von Weltbester FPGA-Pongo (Gast)


Lesenswert?

Thomas K. schrieb:
> allerdings ist die Berechnung
> nun nicht in Echtzeit mit einem Verarbeitungssystem realisiert, sondern
> über einen PC. Da man die Daten im PC abliegen hat, kann man nach der
> Messung auch numerische Berechnungen durchführen, um die Effizienz zu
> steigern.

Das ist mit absoluter Sicherheit die beste Methode, um ein Signal 
schnell zu erkennen. Optimal ist es, das in MATLAB zu machen und es über 
eine WEb-basierte GUI in JAVA zu steuern.

Dann kann es sich nur um Minuten handeln, bis einer weiß was es für ein 
Signal hat. Super.

Könnte es sein, daß die Frage im falschen Forum gestellt wurde?

@Admins: Bitte in den Bereich "PC-Programmierung" verschieben.

von Martin K. (mkmannheim) Benutzerseite


Lesenswert?

Weltbester FPGA-Pongo schrieb im Beitrag #5234913:
> Das ist mit absoluter Sicherheit die beste Methode, um ein Signal
> schnell zu erkennen. Optimal ist es, das in MATLAB zu machen und es über
> eine WEb-basierte GUI in JAVA zu steuern.

Es gibt Cubes, in denen in der Tat MATLAB in Echtzeit läuft, um 
Auswertungen von Signalen zu erledigen. Allerdings ohne Java :-)

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.