On Monday 28 January 2008 17:03:23 Aleksander S. wrote:
> Tobias wrote:
> >Yes, the DTMF decoder used now is much better. Hopefully you will see a
> > big improvement.
> The new DTMF decoder definitly works better. By my experiances there was no
> chance for an TH-D7 to be decoded with the old decoder and the tones from
> an ICOM IC-207E were decoded very unreliably.
> The new decoder now decodes the DTMF tones from TH-D7 I've borrowed for a
> test very reliebly with exception of tones '3', 'A', 'B' and 'C'. No way to
> decode these.
> Tones from the IC-207E are decoded quite reliably now.
> Interesting is that there was absolutely no problem to decode the tones
> from an ICOM IC-E91 handy with previous decoder as it is not with the new
> one in almost any conditions (high noise levels). The same with newer YAESU
> mobiles FT-8900,...).
OK. There are other things besides the algorithm affecting the quality of the
DTMF decoder. The sound card is one thing. I have an FT-8900 and it decodes
perfectly as are any other radios I've tried.
> I still had to change some parameters in the "DtmfDecoder.cpp" to achieve
> a reliable detection from some of the transceiver mentioned above:
> #define BASETONE_N 330
> #define OVERTONE_N 201
> #define POWER_THRESHOLD 500000
> #define POWER_DIFF_THRESHOLD 12
> #define MIN_TWIST -9
> #define MAX_TWIST 6
> Further increase of the twist ranges doesn't seem to bring any significant
> improve (on my system), simmilar as it was the case with the old decoder
> (may be different on some other PC / SB / TRX types).
DtmfDecoder.cpp is not used anymore. I should have removed it. It's
SpanDtmfDecoder.cpp that interface with the spandsp library.
> What is also interesting is that the old decoder decoded the DTMF tones
> from my Yaesu VX-7R very reliably (all of them) while there is no way for
> the new decoder to decode the tones "A" and "B" from this handy! I've tried
> to change the volume from very low up to maximum ("distorsion detected"
> message) without any success. My VX-7 is one of the earliest models and I
> remember there were some issues with DTMF from these transceivers discussed
> on the web. I had the same experience on the Echolink for Win system but
> have managed to fix it by increasing the parameter "Freq. tolerance" from
> the default setting to the level of 3%. Unfortunatelly I can find nothing
> simmillar in SVXlink code.. or have I overlooked something.. please advice.
No, there is no way to adjust this in SvxLink. If possible, try another sound
card. I'm using a "Sound Blaster Live 5.1 Player".
> What I have also noticed (the same as with the Echolink for Win) is that
> there is no universal optimal set of DTMF decoding parameters. After
> replacing the PC motherboard / SB card with a new one I had to find the new
> optimal set of parameters again.
> On the other hand a hardware DTMF decoder with the simple and well known
> 8870 chip seems to decode the tones comming from every transceiver I've
> tested by now very reliably and what is even more important I haven't
> observed any single case when the HW decoder would respond to the voice or
> even more often voice in the heavy noisy conditions. This can not be said
> for any SW DTMF decoder I've seen by now specially if the parameters are
> being changed to more tolerant limits (greater allowed twist and freq.
> tolernace). Later is very important to me since I want to keep the
> execution of DTMF commands on "squelch closed" enabled. That's why I would
> still be very interested in the support of a HW DTMF decoder in the SVXlink
Yes, a hardware solution is a bit harder to put together but when that is done
it will probably work without problems.
I think the problem with software DTMF decoders is that a calibration process
is probably needed since a sound card is not a precision instrument. Clocks
are probably a bit off so we will not get exactly 8kHz sampling frequency.
Also, not many sound cards actually support 8kHz so a higher sampling
frequency is probably used and then it's downsampled by the driver.
Some more work is needed before the software DTMF decoder is as good as the
hardware solution. There really is no reason (in theory) why a software
solution should work less good than a hardware one.
> Now about the interface with the HW decoder I've proposed recently.
> Tobias wrote:
> >A good thing would be if the isolation transformers let all frequencies
> > above 67Hz through. Otherwise it may interfere with SvxLink CTCSS
> >detection/generation. I recently discovered that the CTCSS tone detector
> > was quite sensitive to what you put in the audio path. It's on the list
> > for improvment
> I've measured the transformers used in the interface prototype and they
> seem to have the -3dB cutoff at 70Hz and -6dB at 50Hz with respect to 1kHz.
> They also seem to be flat up to 15kHz (didn't make any measurements at
> higher freq.). The DC blocking capacitor 2u2 will not make problems if the
> mic imput impedance would be kept higher than 1,5kOhm otherwise this C
> should be increased (replaced with an tantalum or even short cvircuited) to
> reliably pass frequencies down to 60Hz or an resistor of 1,5kOhm could be
> put in series to push the cut-off frequency down. Anyhow, one can still
> decide to connect audio output of his receiver to the PC SB's mic. input
That sound great. The reason why I commented on this is that you wrote in your
documentation that a transformer passing frequencies above 500Hz would be
good enough. True for voice but not if you want to encode/decode CTCSS.
> Although I more rely on the CTCSS detectors based on HW circuitry and
> connected directly to the RX's squelch system I agree that having such
> decoder in SVXlink is a very good idea. The only problem is how to take a
> proper signal from the RX. Usually to achieve a good CTCSS detection the
> signal should be taken immediately after the demodulator stage. The
> professional FM transceivers usually have the frequencies below 300Hz
> heavily attenuated in AF amplification stages (and consequently at the
> speaker output) while the amateur transceivers mostly do not, at least not
> significantelly. As I wanted to keep my interface simple enough I didn't
> include an audio amplifier at the interface's audio input which means that
> a good amount of signal is needed (approximately 1,5Vpp), tipicaly taken
> from the TRX speaker output and this might be a problem with respect to
> bringing the CTCSS tones to SB's mic. input undistorted.
Yes, discriminator audio is preferred. Most modern rigs have a 9k6 packet
radio connector so this is not a problem on those. On older rigs, the good
old soldering iron have to be used.
Using discriminator audio will introduce other problems though. For one thing,
pre-/deemphasis have to be handled in software. There are some code for this
in SvxLink but it's very experimental. I don't know how good it actually
> Tobias wrote:
> >In order to make full use of all features in SvxLink (DTMF muting, DTMF
> >repeater module, detection filtering etc) the serial protocol should be
> >modified to signal DTMF tone start and end, not just "digit detected".
> My idea was to propose a solution that would be implementable in existing
> SVXlink system with as little as possible changes in the existing code.
> Therefore (although I don't know the SVXlink structure good enough to be
> sure) I thought to use the external DTMF just for the most important
> function, that is for proper decoding of DTMF commands (command parcer
> code...). All other functionallity like mutting, DTMF repeating etc. could
> still rely on the SW decoder already implemented. No big deal if some of
> the tones passes the muting from time to time...
I don't think this is a good solution. Then you still have to worry about
getting the internal DTMF decoder to work reasonably well. If we have access
to a high quality DTMF decoder it should be used for all things involving
> But, as already said, no problem to implement the RS-232 coding scheme
> proposed (8 binary bits, lower 4 bits used to report the detected DTMF
> tone, upper 4 for signalling).
> There is another possible RS-232 communication option I would like to
> offer. Although it was in the previous message stated that the
> communication should stay uni-directional due to HW limitations I can make
> it two-way with a smal modification. It would cost me to cut two wires on
> the existing prototype PCB, solder two short wire connections and sacrify
> the SQL det. LED which would be in the function of the RS-232 comm RX LED
> after the mod. Actually, no big deal. When I was drawing the circuit I
> wanted to save one transistor and few resistors so I've used one of the two
> MAX232 line receivers to drive the SQL. det. LED :). That's why the
> communication in existing circuit is one-way only.
> If the communication becomes two-directional we can try to make it
> compatible with the Echolink for Win. As I could see from one of the
> Echolink interface projects offered on the web
> http://www.dl5mgd.de/echolink/echolink.htm (opened asm source code for PIC
> microcontroller) the Echolink for Win program sends the incuiry / commands
> in the form of ASCII characters via the serial line to the external
> interface and the external interface only responds rather than talks if not
> asked by PC. As I understand from the above mentioned asm. code the PC
> sends ASCII 'R' / 'T' to the interface to controll the TRX PTT receive /
> transmit and the interface confirms the reception by sending ASCII 'K'
> back. Similar for the tones detection, the PC asks for detected tones with
> an ASCII 'C' and the interface responds with information: ' ' if no tone
> has been detected, 'tone_detected' + ' ' (' ' = ASCII space) if there is a
> DTMF tone detected waiting to be reported to PC. It is not implemented in
> the solution from the web link above but from the protokol described I
> suspect that interface may be allowed to report more detected tones to the
> PC in one data packet in the form of 'tone_detecet_1' + 'tone_detected_2' +
> ... + 'tone_detected_N' + ' '. If such type of communication would suit the
> SVXlink better I could implement it as well.
I say, keep it simple. The protocol described above will not add any benefits,
other than EchoLink compatibility. It's much more complicated to implement. I
also do not like polling. I like event based systems.
> What I would suggest is to keep the management of the PTT and SQL det.
> circuitry without involving microconroller, that is with RTS and CTS lines
> directly as it is implemented in SVXlink now and not via serial
> communication. Of course, both is possible, SVXlink may controll the PTT by
> RTS line as well as by sending the 'R' and 'T' characters at the same time
> to satisfy the existing Echolink for WIN interfaces while the
> microcontroller in another interface may just confirm the reception and
> after that ignore it...
> So much for now from my side. As already said, I would implement in the
> proposed interface any solution that Tobias would consider to be most
> appropriate for the SVXlink package. So please, Tobias, just go ahead, the
> decision is up to you. I only know that I would like to have the DTMF
> detection with an external HW circuitry.
Just implement the DTMF part of my protocol proposal. When we have both DTMF
detected/idle signals, it will fit right into the SvxLink architecture as a
replacement for the software decoder. The squelch thing in the protocol was
just me thinking what could be done in the future. As long as we do not
measure signal strength there is no use in sending squelch status as a serial
> I belive it is not neccessary to point out that if we find a suitable
> solution and Tobias implementats it in the SVXlink system all information
> regarding the interface with HW DTMF detector (PCB layout, PIC source
> code...) will be offered to the public without any restrictions.
73 de SM0SVX / Tobias
> 73 de Aleks s54s
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> Svxlink-devel mailing list