Having remote control over an amateur station is traditionally done with DTMF.
So far, all D-Star control functions have had to be done via the URcall field. This is totally annoying and cumbersome to me.
When it come to digital mode like D-Star the AMBE vocoder translates the DTMF to a digital signature of sorts.
Most codecs add special payload forwarding information for DTMF digits. This is because most low-rate voice codecs cannot be guaranteed to reproduce these tone signals accurately enough for automatic recognition. Codec compression and then decompression of audio will make decoding DTMF at the remote end highly unreliable.
Defining separate payload formats also permits higher redundancy while maintaining a low bit rate. (See RFC 2833)
AMBE is no exception. The AMBE chip has digital codes to signal the encoding of DTMF and to decode the same. The coding scheme can be found at http://dvsinc.com/manuals/AMBE-2020_manual.pdf starting on page 32 (Section 5.2.8)
These special digital codes can only be used if you have access to the full 48-byteframe, which is not in the case of DV data, that only forwards the 9 DV data bytes.
Due to this, it is some peoples understanding that Icom chose not to use that feature of the AMBE chip. (See: the Testing With DTMF Tones section of the Utah VHF Society page.) However, DTMF data is in fact included "in-band" along with the compressed audio data stream. (those 9 bytes of wonderful but totally opaque data..)
However, if you are trying to decode DTMF that isn't directly generated by a keypad on a D-Star radio, good luck.
The microphone audio input path to the the vocoder on a D-Star radio have not been setup correctly to decode this type of in-band processing. You may still need access to an AMBE Chip (or DV Dongle) to deal with that..
That aside, there is no reason we can't create software hooks in programs like Mark, KB9HKM's Hotspot to be able to remotely control it.
There is a ton of software applications hams could be developing if they had the ability to decode AMBE DTMF. The Icom D-Star ID-RP2C controller also lacks the AMBE chip, which makes it a no-thrills controller.
For example; the current temperature could be sent to the display of ones radio if requested via DTMF. Or time...
So is there really no way to interact with DTMF? I'm not convinced yet. It is way to clumsy to have to handle all control functions using the URCALL fields. (especially when mobile)
If you listen to the raw DV stream it sounds noticeably different when you are pressing digits.
While I haven't played with this enough, it does seem there is a digital pattern to DTMF when you analyze at the raw DV stream.
For instance;
DTMF 0 always seems to start with c3-48-3c-82-02-44-21-0b-28
DTMF 1 always seems to start with d3-08-24-f3-83-18-30-41-10
DTMF 2 always seems to start with d3-08-24-f3-83-58-30-41-10
DTMF 3 always seems to start with d3-08-24-fe-93-18-30-41-10
DTMF 4 always seems to start with 83-09-20-82-c5-14-40-c6-2c
DTMF 5 always seems to start with 83-09-20-82-c5-54-40-c6-2c
DTMF 6 always seems to start with 93-49-24-92-55-10-50-c6-28
DTMF 7 always seems to start with
DTMF 8 always seems to start with 93-c8-38-f3-04-4c-51-8e-14
DTMF 9 always seems to start with 93-c8-38-f3-14-0c-51-8e-14
DTMF * always seems to start with c3-48-3c-82-02-04-21-0b-28
DTMF # always seems to start with c3-48-3c-82-12-04-21-0b-28
etc...
There are some variations that occur, which make determining an accurate DTMF mapping difficult. Tools to record AMBE (natively) exist, so perhaps a histogram comparison routine can solve the dilemma.
If a DTMF mapping can't be accurately determined you can always add a DV dongle at the repeater site.
But ideally I'd like to see the AMBE vocoder become part of future revisions of the D-Star controller hardware. Having that in there enables hams to develop applications like I have described above.
DVSI the codec manufacture was able to be persuaded to sell the AMBE vocoder chip in small quantities to help hams. Perhaps they could be further persuaded to release or sell an affordable closed binary to enable such DTMF decoding?
First lets see what we can do as hams.
I re-introduced this subject on the dstar_digital mailing list in December 2009.
I want to try and get a better understanding of the limitations of the "DTMF Decoding" feature of the AMBE codec that is not fully-implemented in D-Star.
I've read the "Testing with DTMF tones" section on the Utah VHF Society page.
http://utahvhfs.org/dstar_codec_behavior.html
"you cannot reliably pass DTMF signaling through a D-Star link system unless that audio is generated from a D-Star radio itself! This means that if you are using a D-Star system as a gateway or as a relay of an analog channel, you should not expect DTMF control to be possible through that link."
From the limited testing I have done from an Icom Radio to an Icom radio by pressing Digits on the keypad I haven't really noticed the distortion behavior.
What I am reading is the problem is going from Analog DTMF to Digital medium within the radio? Like feeding analog DTMF from some other source into a D-Star Radio's Microphone input. (why you'd want do this, is beyond me)
Since my experimentation would involve a D-Star radio's keypad and a node adapter with DV dongle to recover the audio (and DTMF if needs be), does anyone know if DTMF is implemented correctly with the DV Dongle? Or any other perceived issues?
{Update May 2013}
The Digital Speech Decoder Software (version 1.7) was updated to support decoding of D-Star's AMBE. The Digital Speech Decoder and xMBE codec library - can decode and recover the audio from P25 (Phase 1) IMBE, as well as Mototrbo (AMBE+2) and DMR, and NXDN. It started off only being able to decode the D-Star Data, but not the voice portion. This was because D-Star uses an early version of the AMBE codec that is not entirely to the proper spec of the final codec.
A TIA document (TIA-102.BABA-1) (PN-3-3633-AD1) titled "APCO Project 25 Half-Rate Vocoder Addendum" is for AMBE+2 which is similar but not identical to AMBE+ as used in D-Star. But folks have since figured it out.
Now it is probably just a matter of time before someone codes a virtual DV Dongle to encode the D-Star voice frames.
{Edit Jan 2011}
For more information on the DTMF in-band channel with all 4 bits of DTMF information, see the ircDDB-mheard code from Michael, DL1BFF. (line 383 - his code handles the bit interleaving and FEC processing)
Kristoff, ON1ARF took Michael's code and packaged it as a proof of concept, to allow people to experiment with DTMF-controlling your D-STAR repeater.
See: https://github.com/on1arf/dtmf-rcq
Scott, KI4LKF implemented DTMF decoding in his multi-protocol add-on g2_link program. You can easily customize DTMF commands by editing the g2_link_dtmf.sh shell script.
