Hallo zusammen, beim Erkennen bestimmter DTMF-Töne, soll zeitweise ein Schalter geschlossen und ein Audio-Signal erzeugt werden. Die Länge des Tastendrucks und das Audio-Signal (z.B. MP3-Schnippsel) werden vom DTMF-Ton bestimmt. Wie macht man am besten die DTMF-Erkennung? Ich sehe zwei Möglichkeiten: 1. Ein M-8870-01 ist für rund 60ct noch massenweise lieferbar [1], aber das kann ein µC nebenbei machen, dazu braucht man den IC nicht. 2. Z.B. ist im SiLabs AN218 [2] C-Code in 'Fixed Point' mit 'Gain control' und 'DC Bias Removal'. ABER: ===== Ist das 'Goertzel-Verfahren' eigentlich das beste? Denn: Vladimir Vassilevsky schreibt "Don't use Goertzel": https://www.dsprelated.com/showthread/comp.dsp/109640-1.php Weiss jemand, was Vladimir Vassilevsky meint, oder hat noch jemand eine bessere Idee für den DTMF-Decoder? Ich will nicht unnötig Rechenleistung verschwenden, lieber die Robustheit des Decoders verbessern oder Strom sparen, falls Rechenleistung über ist. Außerdem möchte ich C-Code, kein Assembler-Code. Als µC möchte ich einen STM32 nutzen, der auch die MP3-Schnippsel abspielen soll, z.B. "Hier ist Fuchs drei, ich sende zwei Minuten einen Träger.", "Ich sende noch 60 Sekunden." und "Ich schalte nun ab". Hintergrund: ============ Wer noch nie an einer "Mobilfuchsjagd" teilgenommen hat: Unter [3] sind "Ausschreibungen" und "Einladungen". Jede Jagd ist etwas anders. Wer schon mal dabei war, der weiß: Man hat wenig Zeit und jeder Handgriff muß sitzen! Um sich auf zukünftige Jagden besser vorzubereiten und die Abläufe und die Teamarbeit zu optimeren, werden Übungs-Füchse benötigt. Idee: ===== Ein paar "Baofeng UV-5R" mit Kreuzdipolen einfach an verschiedenen Orten im Gelände in einen Baum hängen. Kreuzdipol = Rundstrahler aus Filmdose mit 105cm-Dipol, 95cm-Dipol und SMA-Buchse am Boden. Der STM32 hängt an den Klinkenbuchsen vom UV-5R, drückt - je nach DTMF-Code - auf PTT und macht entsprechende Ansagen. Oder hat noch jemand eine bessere Idee? Hinweise und Vorschläge von Euch würden mich freuen, VG Torsten Links_ _____________________________________________________________ [1] http://www.aliexpress.com/item/-/32674322510.html [2] https://www.silabs.com/Support%20Documents/TechnicalDocs/an218.pdf [3] http://mobilfuchsjagd.de/ BTW: Ich nehme an, Vladimir Vassilevsky meint dieses Dokument: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=4117939 Seine alte Seite bei AbVolt mit "Efficient Multitone Detection" ist leider down: http://web.archive.org/web/20140207131314/http://www.abvolt.com/research/research.htm PS: Weil das sowohl ein "HAM-Thema" als auch ein "µC-Programmier-Thema" ist, passt es auch in das Forum "µC & Elektronik". Bitte verschieben, falls das Theam hier falsch ist.
Torsten C. schrieb: > Ich sehe zwei Möglichkeiten: > > 1. Ein M-8870-01 ist für rund 60ct noch massenweise lieferbar [1], Dann nimm das. Die 60 cent sind gut investiert und ersparen dir u.U. tagelange Fehlersuche.
Torsten C. schrieb: > Weiss jemand, was Vladimir Vassilevsky meint, Scheint mir sehr bezogen zu sein auf ressourcenknappe Controller dazumals (er schreibt etwas von einer AVR-Implementierung). Auf einem aktuellen ARM würde ich das nicht mehr zum Kriterium machen. Torsten C. schrieb: > Bitte verschieben, falls das Theam hier falsch ist. Auch wenn der Afu-Teil davon nicht uninteressant ist, die eigentliche Frage bezieht sich auf die DTMF-Erkennung. Wenn ich recht drüber nachdenke, gehört sie damit wohl ins DSP-Forum.
@nachtmix + Jörg: Vielleicht bin ich mal wieder "zu hoch geflogen". Danke. Der M-8870-01 hat min. 4,75V. Da reichen die 3,3V aus der Baofeng-Klinkenbuchse nicht. Aber vielleicht komme ich ja irgendwie an die 7,4V vom Li-ion-Akku oder nehme separate Batterien. Also, Erstumsetzung mit: - Nur 2 Befehle: "Tonruf I" (1750Hz) und "Tonruf II", Decodierung trivial über NF-Pegel und Nulldurchgänge. - M-8870-01 sind bestellt, für ein DTMF-Upgrade. - Statt Sprach-Ausgabe nutze ich erstmal das Morse-Alphabet. - "WTV020SD music module" sind bestellt, für ein Sprach-Upgrade. - SW-MP3-Decoder später, z.B. bei langen Winter-Abenden - SW-DTMF-Decoder später, z.B. bei langen Winter-Abenden Fragen zu den Winter-Abenden, weil wir hier im DSP-Forum sind: ============================================================== * Ich würde gern einen MP3- oder OGG-Decoder für die Sprachausgaben umsetzen, der nur eine bestimmte Bitrate (z.B. 48kbps) und nur Mono kann, kein Stereo. Hat schon mal jemand einen Open-Source-Decoder 'abgestrippt', oder bringt das nicht viel an RAM/ROM? Was meint Ihr? Kennt jemand einen 'fertig abgespeckten' Decoder für Sprachausgabe? * Natürlich bleibt die Frage zur DTMF-Erkennung bestehen. Falls sich keine bessere Lösung offenbart, probiere ich irgendwann den C-Code aus dem SiLabs AN218. ^^
Wenn du deine Finger auf einen HT9170 von Holtek legen kannst, wäre das ein 3,3V-geeigneter DTMF Dekoder. http://www.ebay.de/sch/i.html?&_nkw=HT9170&_sacat=0 Aber Tonruf ist ja auch ok.
Cool, SOP18 macht das PCB kleiner. :-) Danke. Und die Holteks kosten nur die Hälfte. http://www.aliexpress.com/snapshot/7782227254.html Manchmal ist AliPay echt langsam. Die M-8870-01 konnte ich eben noch stornieren.
Torsten C. schrieb: > Ich würde gern einen MP3- oder OGG-Decoder für die Sprachausgaben > umsetzen, der nur eine bestimmte Bitrate (z.B. 48kbps) und nur Mono > kann, kein Stereo. Wäre es nicht einfacher, ggf. einen seriellen Flash dranzuhängen (für ausreichend Speicher) und dann Rohdaten / WAV auszugeben, statt sich erst noch mit einem Decoder rumzuschlagen? Aber dass hier im DSP-Forum niemand Tipps zur Software-Erkennung von DTMF gibt, wundert mich schon. ;-) Eigentlich sollte ein ARM damit ja kein Problem haben, zumal es von ARM selbst (im CMSIS) eine DSP-Bibliothek gibt. Also auch FFT dürfte da kein großes Problem sein. Hab' ich aber noch nicht selbst gemacht.
Jörg, irgendwie hast Du recht. SPI-Flash mit 32MBit gibt es für rund 60ct, das reicht für diverse Sprach-Ansagen. Da lohnt sich wohl nicht einmal DPCM oder ADPCM. Die billigsten SD-Karten kosten rund das dreifache davon und haben heutzutage 8GB. SD-Karten lassen sich einfacher programmieren als SPI-Flash. Und den SD-Card-Speicher bekommt man auch voll: Falls man PMR-Funkgeräte nimmt, die keinen Anschluss für PTT haben, muss man über die VOX-Funktion arbeiten: "Hier ist Fuchs drei, ich spiele nun zwei Minuten Musik." Und dann gibt es am Ende der Jagt oft noch eine Suchphase, wo die Füchse 90 Minuten ununterbrochen senden müssen. ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Bei der DTMF-Variante per Software sähe ich noch 3 Vorteile: 1. Man muss keinen 3,58MHz-Takt fürden HT9170 erzeugen. 2. Man kann die Robustheit der Erkennung Stück für Stück per SW-Update verbessern, falls sich neue Erkenntnisse ergeben. 3. Man kann Tonruf I und II nebenbei erledigen.
> Aber dass hier im DSP-Forum niemand Tipps zur Software-Erkennung von > DTMF gibt, wundert mich schon. ;-) Eigentlich ist das ja eine "klassische" Anwendung für den Goertzel. Ich benutze diesen Algorithmus seit einiger Zeit in meinem Morsedecoder. Die meisten Programmbeispiele, die ich bisher gesehen habe, erzwingen allerdings die Einhaltung eines ganzzahligen Verhältnisses zwischen der Anzahl der Samples, der Abtastfrequenz und der gesuchten Frequenz. Diese Bedingung ist bei DTMF und beim Rufton (1750 Hz) nicht erfüllbar und der entsprechende Programmteil muss daher entfernt werden. Außerdem ist der Goertzel-Algorithmus kein kontinuierlich laufendes Filter und muss deshalb immer schrittweise Laufen. Bei meinem Beispiel ergibt das bei 8 KHz SR und 40 Samples ein Zeitraster von 5 ms. Mann sollte die Anzahl der Samples aber nicht zu hoch ansetzen, da dies die "Bandbreite" stark verringert. Man sollte das also nur machen, wenn die Töne auch mit der entsprechenden Genauigkeit gesendet werden. Ich füge hier mal 2 Bilder aus meinem Testprogramm an, die zeigen sollen, was passiert wenn die normal angenommenen Bedingungen nicht erfüllt werden können. Die Kurven wurden durch probieren ermittelt, nicht durch Berechnung.
Angehängte Dateien:
-
fl_goertzel01.png
(23 KB)
-
fl_goertzel02.png
(23 KB)
Manfred M. schrieb: > Außerdem ist der Goertzel-Algorithmus kein kontinuierlich laufendes > Filter und muss deshalb immer schrittweise Laufen. Hmmm, Wilfried Elmenreich schreibt hier: https://netwerkt.wordpress.com/2011/08/25/goertzel-filter/ > This filter delivers a result after each sample without storing the > samples, but it considers the whole history of the signal. If you want > to detect the sudden presence of a tone, it is better to limit the > history of the filter. This can be done … Manfred M. schrieb: > … Einhaltung eines ganzzahligen Verhältnisses zwischen der > Anzahl der Samples, der Abtastfrequenz und der gesuchten Frequenz. > … der entsprechende Programmteil muss daher entfernt werden. Das ist ja Mist. Aber wenn die Filter nicht zu schmalbandig sind, vielleicht geht es dann? Mich würde mal interessieren, ob das mit dem ganzzahligen Verhältnis auch für die Implementierung von Vladimir Vassilevsky ^^ gilt. Hat schon mal jemand ein IEEE-Dokument im Internet gekauft? Vielleicht sollte ich das mal versuchen oder in der Uni-Bibliothek der TU Braunschweig danach suchen. http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=4117939 Aber ich befürchte, dass da nur mathematische Ausdrücke drin stehen und ich Mathe-Legastheniker daraus keinen Code erzeugen kann. Manfred M. schrieb: > Bilder …, die zeigen sollen, was passiert wenn die normal angenommenen > Bedingungen nicht erfüllt werden können. Hmmm, habe ich nicht verstanden. Sorry. Die sehen doch beide gut aus.
Ok, das es auch einen kontinuierlich laufenden Goertzel gibt hatte ich schon gerüchteweise gehört, aber bisher nie ein Beispiel dafür gefunden. Ich werde das mal ausprobieren. > Das ist ja Mist. Mich würde man interessieren, ob das auch für die > Implementierung von Vladimir Vassilevsky gilt. Das kann ich nicht sagen, aber wenn das so ist, sollte im Code eine Konstruktion wie: k = N * f_rel / SR auftreten. Beim Code in Deinem ersten Link habe ich dieses Konstrukt nicht gefunden. Und nein, ich brauchte noch nie IEEE Docs zu kaufen. Ich bin auch nicht sicher, ob ich mir so etwas für Hobby Zwecke an tun will. > Hmmm, habe ich nicht verstanden. Sorry. Die sehen doch beide gut aus. Die Nebenzipfel sollten eigentlich alle glatte Kamelhöcker sein, haben aber bei nicht Einhaltung der Bedingung unschöne Einkerbungen. Mich stört das nicht. Das ist wohl eine Folge der Tatsache, das dann von der gesuchten Frequenz kein ganzzahliges Vielfaches der Wellenlänge im Sample-Puffer enthalten ist. Man sollte auch wissen, das die beiden ersten Nebenzipfel immer bei ca. -12 dB liegen, egal wie schmal der Hauptbereich ist.
Hallo zusammen, nachdem hier 3 Wochen lang Funkstille war, möche ich mich noch einmal für Eure Hinweise bedanken und einen kurzen Zwischenstand geben. Die HT9170 aus China sind noch nicht angekommen, aber WTV020-Module. Beide sind nur für einen ersten Quick&Dirty-Aufbau nötig, da ein STM32 sowohl DTMF als auch z.B. DPCM problemlos per SW decodieren kann. Die Platine sollte möglichst auch mit einem VV-898S, TM-218, KT-8900 (25W) oder RT-9000D (75W) funktionieren, nicht nur mit einem UV-5R, um auch bei Wettbewerben eingesetzt werden zu können, also nicht nur zum Üben. Inzwischen ist auch klar, dass man wohl alle 12 Monate einen Antrag an die Regulierungsbehörde für Telekommunikation und Post schicken muss, wenn die Übungs-Fuchse mit mehr als 1 Watt Sendeleistung arbeiten. Siehe Beitrag "Afu: Automatischer Fuchs (Peilsender) - Rufzeichen?" Wenn die HW und SW fertig sind und Interesse besteht, stelle ich gern einen Beitrag in "Projekte & Code" ein. VG Torsten, der sich natürlich weiter über Tipps, Hinweise, Fragen oder sonstiges Interesse am Projekt freut.