Saturday, September 12, 2009

HSMM @ HamCom

CQ-VHF editor, Joe, N6CL wrote a bit about HamCom in his "Innovations and Insights" editorial. The following is a partial excerpt:

For those of us who were able to attend the HSMM seminar at HamCom in Plano, Texas, we were treated with an exciting presentation on the latest in HSMM. MESH networking is a form of digital communications that is designed to route data, voice, and instructions between nodes. This routing is accomplished by continuous connections and reconfiguration around broken or blocked paths by "hopping" from node to node until the destination is reached. Thus, HSMM-MESH® networking is using HSMM in a mesh network.

John Champa, K80CL, led the two-hour forum with an introduction to the difference between WiFi and HSMM. He highlighted the need for developing a means of digital transmission that is significantly faster than the technology that existed in the aftermath of 9/11. He also spoke of how under-utilized the VHF-plus ham bands have been. Additionally, he discussed the need to update our emergency communications so as to bring ourselves in line with the rest of the world.

With the migration of commercial television to digital, we amateur radio operators are also a bit behind the curve. John covered amateur digital video and compared it with what has just gone away, analog NTSC standard television. Glenn Currie, KD5MFW, followed John with a presentation on HSMM-MESH®

Glen discussed the city-wide deployment of HSMM-MESH® in the Austin, Texas area. Austin was picked for the deployment because of its central location and the critical role that it played in recent hurricanes....

Monday, September 7, 2009

Decoding D-Star / AMBE DTMF?

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 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

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.

"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.


Scott, KI4LKF implemented DTMF decoding in his multi-protocol add-on g2_link program. You can easily customize DTMF commands by editing the shell script.

Tuesday, September 1, 2009

Non-Icom Repeater Joins Network

(Reprinted from the August 2009 D-Star Newsletter)

D-STAR has always been touted as an open standard and has been evidenced by the development of software and applications such as DPlus, D-RATS, DSTARMONITOR and others. Now, an effort is under-way to develop a D-STAR repeater package based on non-Icom hardware and Gateway software. David Lake, G4ULF, and members of the Ashdown Forest Repeater Group in the UK have the GB7MH repeater and prototype software on the air and operating.

The hardware is a modified Tait T800 repeater operating in full GMSK mode with the D-STAR standard 6.25 KHz bandwidth. The repeater uses the GMSK Node Adapter developed by Satoshi Yasuda of Japan. With the cooperation and support of the Trust Server Team in Texas, the repeater is connected to the G2 network and is running popular software including the DPLUS module developed by Robin Cutshaw, AA4RC, and Pete Loveall’s DSTARMONITOR code unmodified.

The system is capable of full callsign routing to and from the live G2 network, provides station updates and includes a self-service registration page similar to the Icom registration. The system is undergoing rigorous testing to ensure the integrity of the worldwide G2 network. The software will not be made available until testing has been completed. The repeater is usually connected to REF005A.

David would like to acknowledge the hard work of many who are working on this project including Sato-shi Yasuda, Robin Cutshaw, Jim McClellan, Darren Storer, Pete Loveall, Iain Phillips and members of the Ashdown Forest Repeater Group. This effort represents an exciting step in the evolution of the D-STAR technology and is worth following closely as development continues.

The evolution of D-STAR repeaters began with the commitment of Icom to implement the JARL standard on not only radios, but repeater infrastructure and software. The tremendous growth of D-STAR has opened the door for developers and other experimenters in Amateur Radio to implement new features and capabilities on the digital platform.

You can follow the developments of the GB7MH D-STAR repeater project at