Announcement: there is an English version of this forum on 
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.
Angehängte Dateien:
-
Audio.jpg
230 KB -
Audio2.jpg
270 KB
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.
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"
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...
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.
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.
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 ;-)
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.
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.
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?
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.
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.
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.
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
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
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...
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
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.
Was passiert, wenn du irrtümlich triggerst? Geht dann etwas kaputt? Oder ist das teuer? Falls nein: nimm einen simplen Schwellwertschalter.
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.
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
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.
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.
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.
Ja deswegen. Ich werde mich mal melden wenn es wieder was neues gibt. :)
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
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".
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.
Thomas K. schrieb: > Es ist nur eine einzige Frequenz. Dann werte einfach die Amplitude des Signals aus (über Schwellwert -> beep detektiert).
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.
rbx schrieb: > ... Manche Druffi-"Beiträge" möchte man eigentlich persönlich sofort löschen dürfen um anderen die Zeitverschwendung zu ersparen.
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.
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
> 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.
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.
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.
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
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.
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
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
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.
Angehängte Dateien:
-
4300hz-detector.png
120 KB
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.
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. ?
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.
Angehängte Dateien:
-
iqbeispiel.gif
34 KB
@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).
Angehängte Dateien:
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.
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
Angehängte Dateien:
-
cross_correlation.png
12 KB -
cross_correlation_detail.png
13 KB
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
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"?
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
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.
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.
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 :-)
Thread beobachten
Seitenaufteilung abschalten
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.