ich schau mir gerade an, wie mit Hilfe des Goertzel-Alg. z.B. ZVEI ausgewertet werden kann.
Dafür habe ich die Sourcen von "multimon-ng" und die des "monitord" gegenübergelegt und analysiert.
Die Sache mit der Gesamtenergie im Signal ist mir allerdings unklar, vielleicht kann mir hier einer der Experten weiterhelfen.
Im multimon-ng wird die Gesamtenergie durch Aufsummieren des Quadrats der einzelnen Samples gebildet.
energy[0] += sample * sample;
Später wird die Gesamtenergie aber mit einem Faktor angepasst.
tote *= (BLOCKNUM*BLOCKLEN*0.5)
Was hat dieser Faktor für eine Auswirkung? Woher kommt er?
Noch später wird die Gesamtenergie herangezogen, um die Energie des erkannten Tons zu bewerten:
if ((tote * 0.4) > totte[i]) return -1;
Also wenn die Energie des Tons < 40% der Gesamtenergie ist, dann ist der Ton ungültig.
Woher kommt dieser Wert? Sind 40% = PiMalDaumen oder physikalisch belegbar?
Bei meinen Versuchen hatte ich Situationen, bei denen die Energie des Tons GRÖßER als die Gesamtenergie war. Wie kommt sowas Zustande?
Und zu guter letzt:
Im monitord sind die obigen Zeilen gar nicht vorhanden:
Hier wird zwar eine Gesamtenergie gebildet, diese wird aber einfach als Summe aller einzelnen Ton-Energien berechnet.
Diese Gesamtenergie wird aber im weiteren Verlauf nicht mehr genutzt.
Mich interessiert nun z.B., ob das Einbeziehen der Gesamtenergie im Code des multimon die Auswertung zuverlässiger machen würde, so dass Fehlalarmierungen verhindert werden können.
Gibt es eigentlich noch weitere digitale Filter o.Ä., mit dem man das Eingangssignal noch vor dem Goertzel "säubern" könnte? Z.B. braucht man zur ZVEI-Auswertung ja nur Frequenzen < 3000 Hz. Ein Tiefpass wäre hier doch eine Möglichkeit? Oder ist das durch den Goertzel unnötig?
Danke und Gruß
Joachim
06.08.2014, 20:54
Piepser09
Hi,
also der Goertzel Algorhytmus ist eine Abwandlung der FFT, runtergebrochen auf eine Spektral-Linie, daher auch die hohe Selektivität. Das Ergebnis des Goertzels ist praktisch nur der Betrag der Energie einer Frequenz-Komponente, die Phasen-Info geht da verloren, da diese ja für die reine Frequenz-Erkennung (Tonfolge) nicht benötigt wird.
Naja, und da ist es natürlich einfacher, diesen Algorhytmus zu nehmen, als die aufwändige DFT zu rechnen und dann von z.B. 256 Frequenz-Linien 255 wegzuwerfen und die zu nehmen die man tatsächlich braucht.
Hast Du mehr Fragen ?
06.08.2014, 21:07
Piepser09
Ach ja, im übrigen ist es nicht so, einfach die Quadrate der Samples über ein Intervall aufzusummieren.
Der Goertzel errechnet sich aus:
Initialisierung:
Q(n-1) = 0;
Q(n-2) = 0;
Feedback-Phase:
Step 1) Q(n) = Q(n-1)*coeff-Q(n-2)+x(n)
Step 2) Q(n-2) = Q(n-1)
Step 3) Q(n-1) = Q(n)
Step 4) Zu Step 1 bis N erreicht
wobei x(n) sind die Samples
und coeff der Frequenz-Koeffizient (coeff = cos(2*pi*N*(Fx/Fs)))
N = dein Intervall, bestimmt auch die Frequenz-Genauigkeit !!!
Fx = gewünschte Frequenz
Fs = Sample-Rate
Das ist schon etwas her, daß ich den monitor umgeschrieben habe. An die Stelle kann ich mich direkt nicht erinnern. Ich weiß, daß ich die Berechnung im alten monitor auch irgendwie verwirrent fand. Was aber vor allem daran lag, daß a(n+1)=... als memcpy() Implementiert wurden. Nicht gerade für's leseverständnis optimal :)
Aber war es nicht so, daß die Spektrallinien für die in Frage kommenden Frequenzen errechnet wurden und auch die Gesamtenergie ? Ich kann mich auf jeden Fall an tote und totte erinnern. Das fand ich damals als absolut saublöd gewählten Variablennamen ..
[Source kurz rausgekramt]
Ich weiß nicht genau, was noch von mdi hinzugefügt wurde. Aber im monitord finde ich im process_block(*found_tones)
Code:
found_tones[0] = find_max_index(totte, -1, -1); // groesste Energie
found_tones[1] = find_max_index(totte, found_tones[0], -1); // zweitgroesste Energie
found_tones[2] = find_max_index(totte, found_tones[0], found_tones[1]); // drittgroesste Energie
found_tones[3] = (int) totte[found_tones[0]]; // Energie I
found_tones[4] = (int) totte[found_tones[1]]; // Energie II
found_tones[5] = (int) totte[found_tones[2]]; // Energie III
found_tones[6] = (int) tote; // Total Energie
[...]
return (found_tones)
Also werden doch die drei "lautesten" Töne (Ziffern), Ihre Energie und die Gesamtenergie übergeben.
ja, die etwas konfuse Auswertung der ZVEI-Töne war ja der Grund für mich, mich dem Projekt überhaupt zu widmen :). Da habe ich relativ viel getan in dem Ding, allerdings habe ich den Goertzel-Algorithmus nicht wirklich angefasst sondern lediglich die Bewertung seiner Ausgabe modifiziert.
Die Deutungen von "tote" und "totte" sind wohl richtig, wenn ich mich recht entsinne. Ich habe darüber sowohl den lautesten Ton erkannt als auch meiner Erinnerung nach eine "Rauschsperre" definiert (Anteil der TOTTE an TOTE, Zeilen 619-624 in MonitorModuleZVEI.cpp). Der zweite und dritte Ton ist meiner Erinnerung nach irrelevant für die Ausgabe in den von mir geschriebenen Abschnitten, könnte aber im Bereich der Sirenenton-Detektion nochmal eine Rolle spielen (Doppelton). Die hinterfragten 40% (0.4) waren pi*Daumen, ich hatte das konfigurierbar gemacht über den squelch-Parameter, der standardmäßig bei 51% (Anteil des detektierten Tons an der Summe aller Töne - "tote" wird berechnet in Zeile 521 als Summe aller Energien der detektierten Einzeltöne) liegt.
Der Ablauf also im monitord, wenn ich mich nicht total verfranzt habe gerade im Code: Pro gesuchter/betrachteter/definierter Frequenz wird deren Energie berechnet. Die aufsummiert ergeben die Gesamtenergie des Signals. Wenn eine der Einzelfrequenzen einen Anteil von mehr als 51% an der Gesamtenergie hat, wird sie als detektiert betrachtet und ausgegeben. Liegt der Anteil darunter, schlägt die "Rauschsperre" zu (konfigurierbar via XML-Config).
