Re: [Svxlink-devel] Improved tone detector
Brought to you by:
sm0svx
From: <st...@ar...> - 2011-11-21 18:22:35
|
Hi Tobias, I've just done some tone signal simulations and found the Goertzel version with additional phase info very useful also for the DTMF decoder, especially to reduce false detections. I'd rather not reduce the detection time of the DTMF decoder, as this will reduce detection reliability again and detection delay is within specification limits anyway. Maybe the tone spacing is a bit narrow on the VX-2. If you send me a wav file from your VX-2, I can run it through my simulator and find out the reason. I'm a bit more pessimistic concerning the calculation of the overall block power, as the current DTMF decoder uses block length adaption and result value scaling to place each individual DFT maximum close to the tone of interest. Through this method your gain about 4-6dB compared to the SpanDSP decoder. Unfortunately, I did not understand your thougths about the square root stuff. I think it's always sufficient to use power magnitudes and avoid square root calculations in all casses, because they are of no particular interest. Do you mean block length based power value scaling like in line 396 in SwDtmfDecoder.cpp ? Maybe we should apply your range 0...1 approach also to the present DTMF/Sel5 decoder, because it would perfectly fit there. 73s Steve > > The improvements done to the CTCSS tone detector could probably be used to > improve the DTMF decoder as well. That too is a bit on the slow side. For > example, SvxLink can not detect DTMF sent using the auto dialer in the Yaesu > > VX-2 handheld. Not even on its slowest setting. > > Now for some technical details :-) > > The old detector measured the energy in three narrow (~16Hz) passbands, > comparing the middle passband to the two other passbands. This will make it > > good all over the CTCSS band. It turns out though that this method will > produce a very noisy detector signal which is caused by the poor estimation > of > the noise we get. I call this mode "Neighbour bins". > > The new detector use two new methods. The first is that it will use the > whole > CTCSS passband to check if a tone is present. It will compare the total > energy > of the passband to the energy present at the tone frequency. This will give > a > very good estimation of the noise energy and a much less noisy detector > signal. The drawback is that if the gain in the passband is not uniform, > tones > in parts of the passband where the gain is lower will be harder to detect. > This can probably be compensated for in some way like narrowing the passband > > or maybe trying to do some sort of equalization. This is still on the todo > list. I call this mode "Center to total passband power" (mode 2). > > The second new method used to improve the detector is to use the phase > information contained in the signal. The Goertzel algorithm, used to > estimate > the energy at a certain frequency, will result in both the magnitude and the > > phase of the signal. One can wonder what the phase in the signal mean. The > interesting thing is when we start to compare consecutive measurements of > the > phase. The phase will rotate with a speed that is linear, within limits, in > > relation to the frequency difference. This can be used to make a very narrow > > detector. I just call this mode "Phase" (mode 3), even though it really is > an > addition to the previous mode. > > Another improvement in the new detector is that we can use different > parameters for detection and undetection. This will make it possible to set > up > hysteresis for all detector parameters. > > Now for some even more technical stuff :-) > > I must say I have never understood what the "relative magnitude squared" > value > is that the Goertzel algorithm calculate. One part of improving the tone > detector was to understand this. This is an excerpt from the documentaion I > > have written in Goertzel.h: > > The relative magnitude squared value can be used directly to compare it > against other relative magnitude squared values. If you want to compare it > to other measured values, it will probably be necessary to recalculate it > to an absolute magnitude value. For example, an input signal containing a > sinus with amplitude 1.0 will produce magnitude 0.5 in the frequency plane. > The reason it's 0.5 is because the peak in the frequency plane is mirrored > around zero so it's actually two peaks with magnitude 0.5. So to get the > magnitude for the relative magnitude squared value, we do the following: > > 2 * sqrt(rel_mag_sqr) / block_len > > Now we will get magnitude one for a sine tone with amplitude 1. However, > the > magnitude may not be what you need. The mean power in the signal during > the block may be more interesting. We calculate this by first converting > the magnitude (peak) value to a RMS value. This is easily done by dividing > by sqrt(2). We then square the whole thing to get the mean power. This > calculation can be simplified to: > > 2 * rel_mag_sqr / (block_len * block_len) > > If using Goertzel to find one or more tones, one way to determine if a > tone is present or not is to compare the power given by Goertzel to the > power in the whole passband. The passband power is easily calculated by > squaring each sample in the block and adding them together. Then divide > this with the block length. This will give the mean power in the passband > during the block, including the tone power of course. We will see later > that what we actually need is the passband_energy, which we get by simply > not dividing the summed squares with the block lenth. Now the result from > Goertzel and the passband power can be compared to give a measure if a > tone is present or not. Dividing the tone power with the passband power > will give a value between 0.0 and 1.0. If it's close to one, almost all > power is in the tone. If close to zero, we probably just have broad band > noise. After some simplification, the relation can be computed using: > > 2 * rel_mag_sqr / (block_len * passband_energy) > > 73's de SM0SVX / Tobias > |