GSM DTMF Squelch - Page 1
Forum section: electronics / projects

author: itdontgo
author_rank: Regular Contributor
timestamp: July 15, 2013, 08:16:13 am
content: Do we have any GSM experts on here?I have a GSM board with a software based DTMF decoder based on fourier transforms. The loud speaker output goes through some filtering straight into a comparator on the micro. The system works great when a landline calls the board as you can see in this video:http://youtu.be/jcf79XK0ZkU?t=2mThe problem is when you try this from a mobile it doesn't work. On our door entry system you can hear why. The tone plays briefly (say 0.5s) and then is squelched by either the GSM module or the receiving network. What's strange is that when you call a landline with the same mobile phone the tone plays perfectly. But mobile to mobile it's squelched. Anyone know why?It's probably the network which generates the tones (using the AT+VTS command) not the phone as DTMF doesn't go through GSM codes very well (at least not twice!).

author: itdontgo
author_rank: Regular Contributor
timestamp: July 15, 2013, 08:17:55 am
content: I'm answering my own question here but instead of using the loudspeaker output perhaps I should try using the earpiece output. I'll let you know.

author: nctnico
author_rank: Super Contributor
timestamp: July 15, 2013, 11:13:37 am
content: The problem is probably in the mobile phone or the provider. Nowadays mobile phone calls are made using VOIP if you use >G2. The actual DTMF tones may be generated where the VOIP is translated into an analog line. The length of the tones is probably limited to 0.5s so your detection algorithm has to work in 0.5s.Besides that Fourier is not the way to go for detecting DTMF. Better use band filters and then determine the frequencies in the two bands. The problem is that Fourier analysis or a filter has slopes which aren't infinitely steep. So loud signals far outside the DTMF specification can cause false DTMF detection. Another problem is probably no digitizing the audio properly but clipping it into a comparator. I doubt that it will work with different levels...

author: calmtron
author_rank: Regular Contributor
timestamp: July 15, 2013, 01:43:04 pm
content: Check out theGoertzel Algorithm. It has been used to detect DTMF tones on low-performance microcontrollers.

author: itdontgo
author_rank: Regular Contributor
timestamp: July 15, 2013, 05:43:13 pm
content: The problem appears to be due to the network provider. I've tried two identical phone on two different networks - one receives it the other doesn't. It could be the echo cancellation is set differently on each phone but it looks like it's going to be a network issue.Quote from: nctnico on July 15, 2013, 11:13:37 amI appreciate your comment but my DTMF decoder written in a few lines of PIC assembler works perfectly. I have no issues with decoding. It uses an LPF, a HPF and a comparator and the decoder runs from an interrupt in the background. It's something I've written and it's based on Fourier transforms.

author: itdontgo
author_rank: Regular Contributor
timestamp: July 15, 2013, 05:44:34 pm
content: Quote from: calmtron on July 15, 2013, 01:43:04 pmAgain, like I say, the decoding works perfectly it's an issue with GSM.

author: nctnico
author_rank: Super Contributor
timestamp: July 15, 2013, 05:56:34 pm
content: Try the talk-off tests first before making such claimsI have been involved in developing a DTMF decoder (in an FPGA) for call recording equipment which is being used on thousands of telephone lines around the world. We compared several methods but the frequency counter method beats them all. The voice of some people contains a lot of DTMF like tones so a less than perfect decoder may trigger on those. Like I said before:it looks like the tone is too short for your algorithm so you need to change the algorithm. If the audio is in sync with the picture in your video then it seems your decoder is way too slow. Remember I'm just trying to help here so don't shoot the messenger!A DTMF detector should decode a DTMF tone within 45ms:http://en.wikipedia.org/wiki/Dual-tone_multi-frequency_signaling

author: itdontgo
author_rank: Regular Contributor
timestamp: July 15, 2013, 06:07:52 pm
content: Quote from: nctnico on July 15, 2013, 05:56:34 pmI appreciate you're trying to help. I'm not criticising your input but that isn't my main issue. It's the fact that the volume level of the DTMF tone drops dramatically when it originates from a mobile. It's not a decoding issue it's something weird with GSM networks - that's the problem I'm trying to fix todatI'm sure my DTMF decoder would not match your spec but it's good enough for my application. It meets the standard DTMF spec for twist and power levels and whatever else it is etc... I don't remember the details. It's not new; I've used it for years and for what I need it for I have never heard of any issues. It fits into the rest of the code with some extra security to make sure it doesn't open any doors without an actual key press. It doesn't just rely on DTMF decoding but monitors all the noise on the line and figures it out that way too. You don't talk and press buttons at the same time.

author: itdontgo
author_rank: Regular Contributor
timestamp: July 15, 2013, 06:10:36 pm
content: Quote from: nctnico on July 15, 2013, 05:56:34 pmBy the way GSM has a delay. What you hear is the delay in the audio coming from the landline phone and arriving at the board. Try it with two mobile phones - there is a delay. It's not the decoder which has the delay but the GSM network. I can't remember the spec but the decoder is 50ms or something. It's fast anyway.The landline makes the noise then you see it arriving at the board a short time later because of the network delay.

author: itdontgo
author_rank: Regular Contributor
timestamp: July 15, 2013, 06:15:52 pm
content: That was a good guess. It has two passes 1 for hysteresis. They run for 24.7ms each so the tone would have to be about 50ms for accurate decoding. They also compare power levels to recent audio on the line to see if the noise was there anyway.Again not criticising anyone but for the small amount of code and parts I don't think it's so bad!

author: nctnico
author_rank: Super Contributor
timestamp: July 15, 2013, 08:29:29 pm
content: Perhaps you could record what is coming in from a call origination from a mobile phone and then analyse it using audio editing software.

author: mrflibble
author_rank: Super Contributor
timestamp: July 15, 2013, 08:35:47 pm
content: Quote from: calmtron on July 15, 2013, 01:43:04 pm+1 for Goertzel algo, for the computational cheap bastard on the go.

author: JackOfVA
author_rank: Unknown
timestamp: July 15, 2013, 09:25:44 pm
content: A GSM handset does not generate analog DTMF tones. Rather it sends a certain digital command sequence via the air interface into the network where the tones are generated.On the inbound side, into a GSM mobile, an analog DTMF tone generated by an analog telephone is treated the same as speech; it is digitized and coded and sent onto the mobile for reconstruction as analog speech out of the headset transducer. However, the GSM codec is optimized for human speech and is not guaranteed to pass any particular discrete audio tone or multi-tones. It may or it may not and the quality of tone output may be useful or it may not be. The codec specification is written only in terms of human speech optimization.Things may have changed a bit in this regard since some regulatory agencies such as the FCC in the USA required mobile phones to pass the commonly used FSK modulation used in deaf text communications devices, but I haven't had occasion to follow the subject since.

author: itdontgo
author_rank: Regular Contributor
timestamp: July 16, 2013, 07:59:40 am
content: It is a network issue. Don't use Orange (and maybe T-Mobile) if you plan in sending DTMF tones over the network as they squelch the audio. In the UK they're called EE and they sell their services to Mobile Virtual Network Operators like Vectone (I'm using them in the clip).On the left the phone is a '3' and on the right is a Vectone (Orange/T-Mobile - although it's using an Orange cell in the video).My product still just about works with that short tone that you hear but obviously it's not ideal. You don't hear the left hand phone because its keypad has been turned off.http://youtu.be/q5Z0QHJLjJQ?t=10s

author: itdontgo
author_rank: Regular Contributor
timestamp: July 16, 2013, 08:15:38 am
content: I still find it weird that they let landline DTMF tones through. It might be due to the volume of the mobile network originated DTMF tones.Take a look at this app note it's similar in principle to my DTMF decoder although my code is a watered down version of something I wrote for an automobile product many years ago!http://www.adventcontrols.co.uk/DTMF257a.pdf

author: nctnico
author_rank: Super Contributor
timestamp: July 16, 2013, 12:09:04 pm
content: Its a nice math exercise but solutions from appnotes are never production ready. They always need extra work to be useful and even then it may be possible that an appnote which looks OK at first sight is totally useless for use in a real world product. Did you ever test your circuit to its limits using a (arb) function generator? The question you want to answer is whether your circuits meets the specs or whether the DTMF tone you receive is outside the specs.

author: komet
author_rank: Unknown
timestamp: July 16, 2013, 12:40:50 pm
content: They generate DTMF to landlines in order to appease the "For sales, press 1. For complaints, press 2." call centres, which are always landline based. The assumption is that there is no need for DTMF to be sent to a mobile phone.

author: itdontgo
author_rank: Regular Contributor
timestamp: July 16, 2013, 04:18:43 pm
content: Quote from: nctnico on July 16, 2013, 12:09:04 pmWe can agree on that!