Customized D-Star Repeater

I have provided three simple bash example scripts. One says the time, another reports the weather conditions. And yet another will read back who was recently on your d-star repeater.

(I have since improved some of the quirky word concatenation from what is shown in the video.)

Special thanks to Kristoff, ON1ARF for his ambestream voice announcement toolkit.

Also to Scott, KI4LKF for his g2_link program.

To install this, first install ON1ARF's D-Star voice announcement toolkit, and download my premade AMBE library of files. (this also includes the three mentioned scripts)

http://kb9mwr.blogspot.com/2011/11/library-of-ambe-files.html

To process DTMF; I suggest installing KI4LKF's g2_link program. (Alternatively ON1ARF's dtmf-rcq or a number of different DTMF decoding add-on options) Scott's g2_link will also give you the ability to connect to XFR and DCS D-Star reflectors. His g2_link program contains an easy to understand and modify to your liking g2_link_dtmf.sh shell script.

http://kb9mwr.blogspot.com/2009/09/decoding-d-star-ambe-dtmf.html

Library of AMBE-files

This has been on my to do list for a long time.

About this time last year, Kristoff ON1ARF wrote some excellent open source software.

You can find it here: http://villazeebries.krbonne.net/dstar/voice-announce/

From: http://villazeebries.krbonne.net/hamstuff/?page_id=10

Voice-announcement system on analog repeaters have existed for .. well .. almost forever. D-STAR repeaters, on the other hand, have so-far had this in a very limited way.

The main reason for this is related to the use of the AMBE voice-codec in D-STAR. AMBE-encoders are only available via an external hardware-device (either a chip inside the transceiver or the DVdongle). As this technology is usually not present in a D-STAR repeater, it has up-to-now only been possible to play out a fixed audio-message...

The “dstar voice-announce” package aims to provide additional ways to generate voice-announcement messages on a D-STAR repeater. It is designed to be as flexible as possible, to provide as much choice to the sysops.

By concatenating the .ambe files for “good morning”, “the time is now” “6″ “o’clock”, a complete voice-announcement can be created (also in .ambe format)

Kristoff created a small library of common words using the eSpeek text to speech synthesizer.

I'm not real fond of the voice quality of eSpeak, or Festival/Flite for that matter. So I created an alternate more extensive voice library. Mine contains about 360 words.

Now you don't need a DV Dongle to create system announcements. You just need to install and use Kristoff's ambestream program and download my or his AMBE word library.

You use it like so:

 ambestream -t TEST -v -4 -my KB9MWR -d w1abc.dstargateway.org -p 40000 K9EAM B this.ambe is.ambe a.ambe test.ambe  

Rather than having to specify the path to each ambe word, here is way to use sed to append the full path to the premade AMBE words. In this example I have all my words in /root/words/ambe

 #!/bin/bash  
 #SENTENCE="this.ambe is.ambe a.ambe test.ambe"  
 SENTENCE="this is a test"  
 #  
 # note all forward slashes must be escaped. Just follow the example  
 #  
 #SPEAK=`echo $SENTENCE | sed 's/[^ ][^ ]*/\/root\/words\/ambe\/&/g'`  
 SPEAK=`echo $SENTENCE | sed 's/[^ ][^ ]*/\/root\/words\/ambe\/&.ambe/g'`  
 #  
 #echo $SPEAK  
 ambestream -t TEST -v -4 -my KB9MWR -d w1abc.dstargateway.org -p 40000 K9EAM B $SPEAK  

Please note if you get an error "Error: could not create udp socket! Exiting!" with Kristoff's program, it would be because ipv6 is not installed or enabled. To correct that see:

http://wiki.centos.org/FAQ/CentOS5#head-47912ebdae3b5ac10ff76053ef057c366b421dc4

DUTCH*Star DV Node / WinDV

http://www.blogger.com/img/blank.gif
Fred van Kempen, PA4YBR has written a new Windows program for use with D-Star DVAPs, and GMSK node adapters. It also works with the (blue) DV Dongle, amongst other things.

The DV Node program, (WinDV) will eventually take over most of the "market" currently serviced by DVAR Hotspot, as DVAR has reached the end of its development cycle - the "takeover" by DV Node has been in direct discussion and agreement with Mark McGregor, KB9HKM.

The beauty of his WinDV program is that is supports a combination of several protocols.

DPlus (regular gateways and reflectors) as well as the DExtra protocol used by the Xreflector system. And the newly emerged DCS reflector system.

Also supported are D-STAR Callsign Routing (through ircDDB) and the reporting of GPS positions to the APRS network.

His program should enable more D-Star users to be able access both networks. As currently most D-Star repeaters in DVAP/Dongle users are only able to access the US Trust based network. Where as; homebrew GMSK nodes and repeaters as well as Dongle users using G4KLX Digital Voice package have had access to XRFxxx based reflectors.

Icom stacks/gateways can implement both ircddb and dextra (XRF) linking. I encourage all Icom gateway operators to consider widening the D-Star experience for their users.

I feel Win DV is a great step towards interoperability and hopefully exposing and migrating more users and gateways to a more open source based D-Star infrastructure.

In the future, Fred also notes he plans to develop a version for Linux, and Mac.

I encourage you to check out WinDV today!

Kenwood TKR-850 as a D-Star Repeater

In my opinion this type of thing needs more attention. After all do-it-yourself has long been a hefty part of this hobby. And there is no better way to learn than a hands-on project like this.

Reason number two would be economics, but I think that is obvious.

The third is spectral savings. D-Star is narrowband, but buying a new system just robs another frequency pair from the pool. It seems people rarely take repeaters off the air, even if nobody really uses them. And these days it seems there are more repeaters in a geographic area, than there is activity.

So it seems best in my mind to convert something already out there. This would make a great club project.

This is great example of continued innovation of D-STAR technologies by incorporating non-Icom products into D-STAR environment.

Date: Thu, 07 Oct 2010 05:32:17 -0000
To: dstar_digital@yahoogroups.com
From:
Subject: K8BIG Port B Using Kenwood TKR-850 Interfaced to ID-RP2C

The K8BIG Port B D-Star Repeater in Cincinnati, Ohio is successfully running using a Kenwood TKR-850 Interfaced to the Icom ID-RP2C in place of the Icom Band module (ID-RP4000V). The usable range of the repeater has been effectively doubled from around 25 miles radius to 50-55 Miles radius.

The K8BIG system is on the WCPO-TV Tower overlooking downtown Cincinnati, OH with the antenna at 700' AGL. There are 3 50,000 Watt FM Radio transmitters, 1 250,000 Watt VHF DTV Transmitter, and 2 3,000 Watt LPTV stations on the same tower along with various commercial VHF/UHF/220 transmitters so the RF environment is pretty harsh - add in the neighboring (2 Blocks) tower with a similar complement of transmitters and it is downright brutal for any radio equipment.

The Icom band module was being swamped by the high RF levels at and surrounding the site, causing very poor effective receive sensitivity even after the TX-RX BpBr Cans and an additional band-pass cavity. I had partially remedied this with one side of a reject-only mobile duplexer, but that introduced around 6 dB of insertion loss. Even with the 6 dB insertion loss the effective sensitivity was improved. The Kenwood repeater has a much tighter front end and much better selectivity with adjustable front-end helicals so the additional receive filter is not necessary and the 6 dB insertion loss was removed.

After the interface was built we were able to plug and play into the Icom ID-RP2C controller and gateway. With the exception of the increased range there is no operational difference in the repeater - everything works identically to the Icom band module. Commands work, data works, D-Rats works, etc.

I will be building more of the interfaces shortly which can be used to interface any 9600 baud-capable analog repeater directly to the ID-RP2C. Anyone interested please let me know.

Thanks.

Dan Woodie
KC8ZUM

You may want to look at;
Michael, VK5ZEA's Homebrew DV Node Adapter to ID-RP2C interface.

John, K7VE's Kenwood TKR-820 Node adapter retrofitting.

And/or my Motorola GM300 retrofitting and commentary.

As a technical side note, one thing to consider when converting analog repeaters is the receiver IF bandwidth. To date there has been little discussion on narrowing receivers bandwidth to match the narrower D-Star signal. Just be aware that converting a 1950's era repeater to D-Star that might have a 60 Khz I.F. would be vulnerable to adjacent channel interference. A good overview of the theory can be found in a reprinted article from Ham Radio Magazine 1985, by WD5IBS.

DIY Compatible D-Star Repeater - Green Bay

I have an experimental 440 MHz analog repeater that has been converted to D-Star. The GM300 radios have been interfaced using a Mark Phillips, G7LTT GMSK node adapter clone. The node adapter is in a duplex configuration, so in reality it has nearly all the functionality of an Icom D-Star repeater.

A D-STAR repeater is an expensive proposition. And many people are not happy with the Icom D-Star repeater performance. It's a number of things, most notable the poor receiver sensitivity. ~.45uV... In many cases the "repeater" is nothing more than two 28XX series radios in a rack mount box ... Pictures in the d-star digital yahoo group confirm this. Receiver desense is also on the list due to the use of plain-jane RG-58 inside the units. In addition, the receiver is prone to overloading by out of band high power FM broadcast signals.

Apparently the Icom G2 software is also not impressive, as discussed on the D-Star Gateway mailing list back in November 2009.

To build this adapter the cost about $100 (+ your analog radios) as compared to the cost of a Icom RPC-2 Controller plus a RF band module at about $2900.

For the longest time I was running Mark, KB9HKM's DVAR Hotspot Windows based software to compliment the board. For remote repeater site use I haven't been real keen on the idea as Windows computers seem to need reboots at inconvenient times.

So I have had a watchful eye on two Linux developments.

The first is by David, G4ULF, but he is still in the midst of releasing the program.

The other (probably less prominent) is by Scott, KI4LKF. His "rptr" program is available now.

All-in-all, I'm happy to report, version 2.93 has been running stable for me. Under Linux at least I have been able to script some ideas by trapping the debug messages with Perl.

For now, the frequency is 441.4625 +5 (SNP) The 40 watt GM300 radios are running cleanly at 20 watts.. The repeater is located in the village of Allouez near Heritage Hill State Park. The antenna is a Comet GP-6 Omni (9 dB), at about 35 feet. It is fed with LMR-400 coaxial cable. It appears to have about a 15 mile coverage radius.

Maxtrac/GM300 radios have a jumper inside (JU551) that sets whether the external connector will have flat or discriminator audio. You want discriminator. You may also need to add some 10 uF DC blocking caps on the RXA and TXA lines.

For more Information on the GMSK/ DSTAR Node Adapter/ Hotspot, please visit the websites below:

http://www.dutch-star.eu

http://www.gmskhotspot.com

http://d-star.dyndns.org/

Specifics on node adapter setup

If you are seeing what else you can do on a Linux platform with D-Star, I'd love to hear more about it.

{Edit Oct, 2010}
You may also want to take a look at John, K7VE's recent blog where he converts a Kenwood repeater for D-Star.

{Edit Nov, 2010}
And a Cincinnati OH, club using a Kenwood TKR-850

Reasons to like / dislike D-Star

Here is a thought from a local club member that contacted me about D-Star:

The thought occurs to me that D-Star is one future standard and why not purchase a D-Star radio ahead of the roll-out? One issue is that it adds expense and why buy something today that you can’t use when the standard may evolve to something better in the future. Therefore, a waste of money now?

He actually has a good thought process. The thing I see is that since D-Star is based on the JARL standard, some parts of it cannot change. By that I mean, GMSK modulation and data rates for example. Evolve, yes it already is, and that is why I like it.

What he means is be replaced (not evolved) by something else radically different, perhaps TDMA based or what have you.

My feeling is that this is not a big consideration/fear simply because ham radio is in such a decline. You will likely never see another replacement simply because it's not on ham manufactures priority list as they market is simply not there.

Resons I like D-Star:
I've been in the hobby for nearly 15 years. I'm starting to become a been there, done that kind of guy. This is something different... a step in the right direction, to the future.

From a repeater stand-point the slow speed data & voice are not only spectrally efficient, but efficient on the club pocket book. Else you have to deploy separate APRS and voice repeater feedlines and antennas.

The framework is open so some development and evolution is possible. This paves the way for additional functionality that can be added later.

And it can be done remotely (SSH) since this is a digital system. No more spending $$ on new controllers and scheduling trips to the site to interface them.

D-Star helps attract a new breed to the hobby. The computer savvy. Which is good, since we should be one the path to software defined radio (SDR).

Some of my dislikes:

-Closed codec.
-User radios are not firmware upgradable
-DTMF encoding implemented wrong ?
-The term "D-Star" trademarked by Icom
-Attitudes
-One vendor

The attached images shows some starter ideas of how to add additional functionality.

One of the problems since ham radio is so stagnant is that no one really monitors. It becomes so infrequent that people are on at the same time. Those once 24/7 radio active hams are now amusing themselves with Ipods and smart phones.

So one of the script ideas report the callsigns of who is in the air to twitter. This way people know when to put down the Ipod and pick up the HT. Other scripts report current temperatures as text messages periodically.

DV Access Point Dongle (DVAP)

Unlike the DV Dongle, the new product allows Amateur Radio operators to walk away from the computer and transmit/receive D-STAR voice and data using a two meter D-STAR radio..... The DVAP is basically a GMSK modem with a 10 milliwatt two meter transceiver built in.

This is more crap for hard core D-Star enthusiasts. As if paying $200 for a regular DV dongle wasn't insane enough, just so you could talk AMBE over the internet using your PC microphone and speakers... now you can pay that plus the price of a D-Star radio, just to talk on the precious D-Star network.

Why in tar-nation Robin, AA4RC wasted any time designing the DV Access Point Dongle is beyond me.

It seems more logical to promote the GMSK node adapter hooked to a real retrofitted analog radio. Converting analog repeaters to D-Star at a fraction of the cost seems like something I'd get behind. At least then more than one person can use it.

This is another toy... that to me was a huge waste of engineering time. I thought Robin was going to work on a complete open replacement for the $300 Icom D-Star gateway software, hence www.opendstar.org.

All that has resulted is an add-on called D-plus, basically written to augment the DV dongle that Robin sells.

The AMBE decoder should be at the repeater end. Then users who want to talk on D-Star over their PC's can stream their voice using an open codec (no dongle) to the repeater, at which point it can be converted to AMBE with a community dongle.

Who is steering the D-Star boat? Will the D-Star newsletter ever promote such ideas? Or is it a mere advertisement to aid Icom and Robin in their financial endeavors?

How-To Build a D-Star Compatible System at a Fraction of the Cost with More Capabilities

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

Homebrew D-Star Repeater?

In the past I've written about a passive D-Star capable repeater using a couple Maxtracs.

This of course is less than ideal as it's a carrier activated system, left open to intermod and such.

I have also written about Satoshi's GMSK node adapter. There was a tid-bit about this in the July 2009, QST, Eclectic Technology column by Steve Ford.

In the QST article it was talking about using Satoshi's board as D-Star Simplex Hot Spot. Mark, KB9KHM developed some windows software so one can use the node adapter as a simplex node to talk back to the gateway server of other D-Star repeaters.

Most of the bugs have been worked out, and the official non-stripped down Satoshi, GMSK node adaptor board can be used to make or convert an existing repeater for D-Star, with the capability to talk back to gateway servers for interlinking.

I suggest taking a look at David, G4ULF's blog.

His blog is a running log of development of a D-Star repeater that links to the worldwide dplus network running on homebrew components and standard UHF FM rigs.

Duplex use of the node adapter used to require two 18F2550 PIC chips running his code, instead of the one. Now KB9KHM's HotSpot software can emulate that. So you can get by with a mini-hotspot board, and just one PIC.

Satoshi's project has caught a lot of attention (and some flack), because you can construct the node adapter for about $75. An Icom D-Star system; one radio module, RPC controller and gateway runs about $3,000.

If you build or convert your existing repeater system, you can also keep backwards compatibility for repeating analog.

All you really need are direct (varactor or varacap) drive to transmit the GMSK data, and a discriminator output for receive. (As pointed out for the simplex hot spot use, most 9600 baud "data ready" radios will work.)

The retrofitted repeater system should be tuned for maximum 3 KHz deviation for best bit error ratio.

If the idea of running Mark, KB9KHM's windows based "hotspot" linking software for a permanent repeater installation doesn't thrill you, never fear, Dextra is here! (This is a very close basis of G4ULF's project)

British Columbia Wireless Amateur Radio Network.

The BCWARN infrastructure includes and supports:

-Electronic Mail via WinLink (over 2.4ghz microwave, AX.25 packet radio and Pactor3)
-D-Star Digital voice and data
-VoiceOverIP using Asterisk private branch exchange (PBX) open source telephony switching technology
-File sharing
-Remote printing and facsimile
-Video conferencing & instant messaging

http://www.bcwarn.net

D-Star Simplex Station

Ok first off I promise not to turn into a D-Star fanatic. Nothing has urked me more lately than the D-Star hype fanatics. The most recent example is this D-Star newsletter.

D-Star isn't for everyone, nor is it the saving grace of amateur radio. Bombarding folks with growth (peer pressure) statistics from DtarUsers.org isn't cool kids.

To me; D-Star overall is Disappointment-Star. My feeling are that ham radio needs narrow band like the ARRL needs aging members. But that's no fault of D-Star's design, more so of our bandplans. D-Star was designed to work into existing ham band plans.

So why did I pick up a D-Star radio you may be wondering? Simple, it's emerging technology and experimenting with that sort of thing is right up my alley. It was hard to justify because the local big radio club around here will spend grant money on foolish redundant equipment that only gets used occasionally. But the concept of trying to define and set the pace for the areas ham radio future by deploying new infrastructure is apparently beyond them. (IMHO a CW and spark gap forever mentality.)

I've shared my thoughts before on the enormous amount of development potential there is with D-Star despite it's utterly useless low bit rate. Enhancing the no-frills controller, and a SIP to D-Star translation for IP telephony interconnection.

However that's all stuff a bit beyond what one or two guys with a HT can start messing with.

So what I have been throwing a few ideas around with and messing with some code that is doing things with the receive callsign heard data as a simplex station. Bruce, KG7WI has a nice perl routine for to get and put data from/to an IC-91AD that can be adapted for the IC-92AD as well.

The concept is, since each user transmission contains a callsign, we are able to create custom greetings based off decoded data, by using a text to speech engine such as Cepstral or Festival. "Welcome KB9MWR to the N9DKH simplex station." "You have one voice mail message from Kevin, left yesterday"... A relational database or QRZ lookup could even make it more personal with first name greetings. Last heard callsign stats could be kept and queried via touch tones and/or exported to a club webpage. D-Star low speed short messages could be posted to twitter for those hams who don't have a HT genetically attached to their hip at all times. And so much more...



To make this interactive, I was hoping the digitized DTMF would be available via CI-V. This is not the case, so they will have to be decoded externally-analog style.

Other ideas include reposting the received short text messages once can send from their radio to twitter. Or reporting recent heard - on the air status messages to twitter.

Icom could share the CI-V command codes, which could them sell D-Star, as more excitement there would be generated and people using the D-Star radios. But so far there hasn't been any openly published for this particular radio. A true bummer, as well as their choice to deny a fairly major radio issue. Those are bad business moves in my book.

D-Star data port?

I almost bought the IC-92AD at AES superfest. I had planned on it actually until I discovered a design flaw.

Apparently there a number of people reporting that the display goes blank after VHF transmit in DV mode. So something isn't shielded the best. Icom will fix this is you discover it and send it in. But that's just a bummer when you drop cash to buy a new radio only to have to send it in.



What did pique my interest for a while was the 12 pin connector on the handheld. There is an optional (overpriced) GPS speaker mike that interfaces to this port.

I knew it was wishful thinking that there might be access to the raw (signed 16-bit, Little-Endian, 8kHz, non-stereo audio packets.) AMBE decoded audio. Such is not the case. The 12 pin port is solely for the utterly useless slow speed data and some cloning functions.

Why anyone would bother with a 1200 baud digital data port is beyond me. We had that kind of speed with packet in the 80's. It makes sense to use that reserved 1200 baud for on-board text messaging. Or with that crazy priced GPS mic.

So it makes sense me to me that hams might want to interface to the digital audio part and callsign routing to try and create a SIP bridge.

Anyway you can't get at that DV stream which is a shame. So to experiment with interfacing a D-Star radio to Asterisk you really need to buy that overpriced DV-Dongle. Which of course lacks an over the air demodulator so you need to connect it to an analog radio.

What a bunch of bull.. D-Star isn't for me yet. I have other things to spend my money on, and there really isn't anyone around my neck of the woods with a D-Star radio. But it is interesting to read up on and play with some of the software being developed. Perhaps one day there will be such a standardized port, much like the standardized packet radio data port.

Above is a block diagram of how a D-Star radio works. As you can see analog microphone audio hits a single-channel, Analog Devices Front-End Speech Processor. This is actually what does the analog to digital and digital to analog conversion.

From there we have a RAW digital audio stream to the AMBE-2020 vocoder. This raw stream is signed 16-bit, Little-Endian, 8kHz, non-stereo audio packets. At this point this raw stream is a non-license encumbered codec, close in resemblance to ulaw (g711). The Linux SoX tool can convert most file formats, like WAV or MP3 to this RAW format.

The AMBE-2020 Vocoder Chip is configured to transmit and receive digitized speech to and from most linear, a-law, or u-law A/D-D/A codecs though its serial interface.

It kind of bugs me that there isn't a way to interface to this digital audio. I guess it's not a super big issue on a user end radio as you can always interface analog using the speaker microphone jacks.

Satoshi, 7M3TJZ/AD6GZ's D-Star Node and DV Adapter

Satoshi Yasuda, 7M3TJZ/AD6GZ, has two different constructions projects available. The one that is the main focus of this yahoo group - the node adapter - is basically a GMSK smart modem tailored to D-STAR.

The node adapter has two modes - simplex and repeater. In simplex mode, node adapter only serves to decode/encode the GMSK modulation used by D-STAR radios and turn it into a bit stream that can be fed into a computer. In repeater mode, the node adapter serves as a bit regenerative repeater. However, while in repeater mode, the node adapter does not have the capability to pass any data in/out of the computer. So, in repeater mode, the node adapter can not be linked to any D-STAR gateways/reflectors. This node adapter has no provisions to convert D-Star Digital Voice To Analog Voice. This hardware software combination operates in 100% digital mode.

He began by looking into the UT-118 works. It is entirely of his own design. Mr. Yasuda is/was a member of the D-Star standardization committee.

The main component is the CMX589A GMSK modem chip. The same chip used in many
of the Icom radios.

Probably the next most important chip is the 18F2550 PIC that runs his firmware.
This takes care of formatting/ recognizing the actual D-Star protocol, USB
communications etc.


More information can be found on Satoshi's web site.

Mark, KB9KHM uses his node adaptor in simplex mode with his D-STAR Hot Spot software that Mark wrote to provide a simplex RF point of presence to the D-STAR network. (He uses his D-Star HT with the adaptor hooked to an analog radio's packet port to pass D-Star digitally to a gateway server over the internet.)

In this video, Erik Finskas OH2LAK, of Finland shows his D-Star Hot Spot / node adaptor while holding a QSO:

And here is a slide-show overview of the GMSK Node Adapter:


In a later revision of Mark's hotspot software he added a routine that provides a way around the combination problem repeater mode and linking. Now you only need one pic, as the data received can be sent back out like a loopback, while still keeping a data stream to external D-Plus gateways.

---

His AMBE DV adaptor on the other hand is a full blown adapter to turn an analog radio in to a D-STAR radio and does include provisions to encode/decode AMBE.

In this video Peter, DJ6ZR/AI4UE and Don, WD4CWE test D-Star on 6 meter and 10m with the Satoshi DV Adapter. With more info at http://dstarradioclub-international.com/default.aspx



Mark, G7LTT/NI2O also has had 10 and 6 Meter successful D-Star QSO's using Satoshi's AMBE DV adapters interfaced to two Yaesu FT-8900 quad band FM rigs.

Satoshi's AMBE DV adapter does decode and encode raw D-Star tailored GMSK unlike the the DV Dongle that Moe, AE4JY and Robin, AA4RC have in production.

Satoshi's does seem better suited for the D-Star to SIP translation project that is being investigated.

D-Star <-> SIP Translation

One of the interesting things about D-Star is it's ability to route calls between radios by callsign. There are two types of calls with D-Star; directed calls and non-directed calls. Non-directed are much like we are all used to. A CQ type listening mode, where you basically hear all general CQ style traffic on the channel. In the directed call mode, you can ignore all this (think of it as call sign squelch), kind of do-not disturb mode, but either way you can be summoned by anyone making a directed call to you. The radios display the callsign of who you are talking to kind of like a caller id type of thing.

When systems are linked a gateway server tracks where various callsigns are coming from so that directed calls can route out to the appropriate radio end point as you mobile from city to city, etc.

The Session Initiation Protocol (SIP), works very similar. It has become a standard for VOIP and other text and multimedia sessions. The sip username/ secret can represent the D-Star callsign or device / radio endpoint. SIP usernames are usually represented numerically, as in extension 200, but they can also be alphanumeric. A meetme/ conference call/room can act like that big CQ style reflector that we are used to with IRLP and Echolink.

SIP devices can register dynamically with an Asterisk Sever The best example is a SIP based Wifi phone where you may travel from hotspot to hotspot, but the server keeps track of how to route calls back to you. Much like how a D-Star gateway can track and route calls to you.

In either example, D-Star or SIP, under each packets SIP data, the callsign or extension information, there is then the Real-time Transport Protocol (RTP) audio stream carrying ones voice. With D-Star this is AMBE encoded, and with SIP it's typically encoded U-law/G.711.

John, K7VE has a D-Star dream of convergence with SIP, an established real- world protocol using by VOIP networks.

To accomplish such an Asterisk/SIP to D-Star/AMBE bridge/translation, the patented D-Star codec would have to be decoded with a $20 hardware solution, such as the DV dongle developed by Moe Wheatley, AE4JY. It can then be transcoded to more common g.711 a-law/u-law codec.

He points out that once a channel driver is properly created the whole power of Asterisk can be brought to play as a D-Star radio can then be used like any other digital IP phone endpoint; conference bridges, interactive voice response, call out, autopatch, voice recognition, etc. Basically instead of an IP phone as a digital endpoint, we could use a D-Star radio.

Using the AMBE-2020 chips in a PCI card or USB dongle will allow the conversion of the DSTAR Digital Voice to/from alaw or ulaw 8k digital voice and the chip decodes/encodes DTMF ... this combined with the datastream (containing callsigns) should enable making DSTAR radios extensions on a Asterisk PBX (or even assign a DID to them) -- total 2-way ROIP/VOIP integration that can route to/through the PSTN. (Example: dial 1-800-4KB9MWR and get a call you can pick up on your DSTAR radio and vice-versa.) Pretty powerful for EMCOMM and personal use. All enabled by open source

http://www.mail-archive.com/dstar_digital@yahoogroups.com/msg02975.html

-Update May 1st, 2009-
Scott, KI4LKF announced today that he has written an asterisk channel driver (chan dstar) that can connect to D-STAR repeaters and reflectors.

Keep your eyes peeled as this is further developed. http://asteriskradio.net/wp/2009/04/29/digital-integration-to-pstn/

And here are some thoughts on using a SIP phone/client on an Iphone or Android phone to connect to D-Star.

Here is a bit more of John's thinking. A cut and paste from an inquiry to the rtpDir yahoo group:

Subject: Re: Question on Dstar-Asterisk Integration
Date: Thursday, July 23, 2009 3:56 PM



--- In rtpDir@yahoogroups.com, "Tom Power" wrote:

Question for the Group:

Does Scott, KI4LKF's Dstar to Asterisk integration allow the passing of the Dstar integrated callsign in the Dstar Stream to Inbound Caller ID on Asterisk/SIP?

Wondering the level of integration with Asterisk.

Thinking of doing some experimenting....
Was thinking on a PBX integration point. Basically two ID-1's with one of the ID-1's having an asterisk server on one end and using it as a Autopatch, announcement system, SMS Gateway etc.

Thanks,
Tom

As Scott said, that is not what his code does, but it is something several folks have a strong interest in seeing implemented.

Now that open source (Scott's and G4ULF) gateway implementations are coming about, the integration should be a lot more approachable.

Here is what I would like to see.

A driver on Asterisk that has the following functionality:

* It creates a channel to D-STAR where an extension or DID could be mapped to a D-STAR callsign. This channel would do a few things:

Route the stream through an AMBE device (such as the DV Dongle) and bi-directionally transcode between the source CODEC (GSM, G.711, etc.) and AMBE.

It would initiate a "ring" to the D-STAR network through a gateway, setting the UR field to the destination callsign and the MY field to a callsign assigned to the PBX (e.g. KX1XXX T - T for telephony interconnect). The "caller ID" would be placed in the Icom defined 20 character short message field, so that it would show up on the display of D-STAR radios on the radio side of things. It could also send an "audio" indicator of a ring in the stream.

When the radio receives the "ring", the radio user sends back a DTMF command such as "*" to answer, "#" to hangup, "1" send to voicemail, "2" send to my landline, etc.

If no command is received within a certain amount of time, the call is sent to Voicemail.

The conversation takes place (with predefined timout).

If there is also text from the same session (e.g. Jabber/SIP) it is put into the data stream on D-STAR, so it will be available on the data port on the radio. (Bi-Directional)

At the end of the conversation, the radio user sends a DTMF hangup command (e.g. "#") - since this is connectionless, if the "telephone" user hangs up, the DTMF is unnecessary.

Conversely the radio user, sets up a call by setting up his radio:

UR: KX1XXX T
RPT1: KX1XXX A (the repeater)
RPT2: KX1XXX G (the gateway -- I think this should be removed in the future, but its how it works now)
MY: K7VE

The radio user sends a DTMF sequence to start the patch, such as "*123", then dial the number/extension you want to call and proceed like a "regular" telephone call. Then hangup using a DTMF command.

BTW, all of this should work through the D-STAR network. So you could actually go to a remote "registered" Telephony Interconnect. E.g:

UR: KX1XXX T (Boston Interconnect)
MY: K7VE (I'm in Seattle)
RPT1: K7LWH C (2 meter Bellevue WA Repeater)
RPT2: K7LWH G (Bellevue WA Gateway)

Pretty cool?

Once this is all working it is simple to use the Asterisk PBX for voicemail, interactive voice response, etc.

I am gathering the components to build a "desktop repeater" for testing, at which point I hope to work on this.

-- John, K7VE

http://www.mail-archive.com/dstar_digital@yahoogroups.com/msg02975.html

{Edit 1/2011}
Karl, N2VQM posts some good thoughts on the whole matter:
http://groups.yahoo.com/group/gmsk_dv_node/message/6210

DV Dongle

If you have been following my blog you probably say my piece on interoperability strides and my other piece on this second roll out of D-Star called NXDN.

This interoperability thing as you can imagine is pretty important. The key problem stems from a lack of standards but it really has to do more so with the fact that technology is developing so quickly that it's difficult to get everyone on the same page. Technology standards seem to be set by who can develop something first and obtain the largest market following. Just look back at VHS vs Beta, Blueray vs HD-DVD, etc.

As pointed out a common interconnection that both P25, and D-Star developers are choosing is the standardized Asterisk based SIP protocol using RTP audio streams.

A key component in all these digital voice systems is the vocoder. This is the device that converts your spoken voice to a synthesized or digitally compressed speech format.

The public safety APCO/ P25 format uses Improved Multi-Band Excitation (IMBE). This is proprietary vocoder developed by Digital Voice Systems, Inc. (DVSI). It is the predecessor of their Advanced Multi-Band Excitation (AMBE). It costs $150K to get the rights to play with that mode plus $5 a seat. There is no off the shelf IC to do it.

D-Star uses Advanced Multi-Band Excitation (AMBE) from DVSI. Same $150K if you want the software source but they do offer a single chip solution for $20 single quantity and are happy to sell to hams.

The DV dongle is an important development. It was started by Moe, AE4JY and Robin, AA4RC. It contains the ability to process AMBE full duplex. Presently software applications exist to use this to communicate from a computer to a D-Star gateway. Further development are expected so that it can be interfaced to a radio's packet radio port that has the necessary discriminator connections. This may be a huge milestone. The ability to retrofit an existing repeater could be possible with this. Not only that, but you may be able to retrofit it in such a way that it can be usable in analog and for D-Star. 

With the DV Dongle you will be able to use DPLUS* or the future OpenDSTAR gateway software to connect to the gateway computer behind the ID-RP2C (repeater controller). Then you will use the DV Dongle to extract the audio streams and can transcode them to standard G.711a/u, GSM, G.729, etc. and then use the Asterisk PBX power for telephone, voicemail, DID-Callsign-DID, repeater, etc. interconnection.

(* DPLUS is a gateway addon daemon that provides a number of functions see: http://opendstar.org/tools/readme.txt)

When you take a digital radio platform like D-Star, this is where integrating Asterisk could be very powerful. Since the call sign is part of every packet, this could be assigned to a direct inward dialing number (DID) or extension.

At the present time the dongle connects over the internet to an Icom gateway controller at a repeater site. So for now is a non-RF application.

What would be even more ideal since D-Star radios don't have an analog packet port is if the various D-Star radios had a digital interface port/jack to support just such a dongle / device to transcode to a SIP and codec standard. Unfortunately at this time there are no known interfaces to the Icom D-STAR radios that allow access to the on-air data stream.

I'd love it if I could buy a D-Star radio, that has an digital interface of sorts. Something along the lines of D-Star non-proprietary interface. Perhaps a mini-USB interface that perhaps transcodes to a more open standard codec like G.711 using SIP and RTP protocols (standardized protocols) so one can connect the radios together into wide area networks.

Then one would be able to have a D-Star radio in my shack also interconnected to various Asterisk powered applications in their house. Where if you weren't around to take a directed D-Star call, it could be configured as a DID to a system and use a ring group / follow me list to let the radio caller ring a home phone or leave a voice mail.

The open source project25 interface is a good idea. Unfortunately the problem they're facing is that most of the manufacturers don't bother following the ISSI spec, nor does the ISSI spec call out hardware interface details. So basically the "plugs" on the back of say, a Quantar... don't match the "plugs" on the back of a MASTR III.

http://en.wikipedia.org/wiki/P25_ISSI

The Project 25 Inter RF Subsystem Interface (P25 ISSI) is a non-proprietary interface that enables RF subsystems (RFSSs) built by different manufacturers to be connected together into wide area networks.

It would be great to see an a D-Star radio that supports something like this on the market possibly before the P25 interface idea ever makes it to the market.  

ARRL: It Seems to Us: Interoperability October 1, 2007 We need to encourage D-Star manufactures to come up with a similar style non-proprietary interface for D-Star.  

Digital Voice Interoperability strides

Asterisk provides an Interoberabity platform

What is Asterisk?
Asterisk is an Open Source PBX & Telephony Platform. It’s often labeled as the future of telephony. It has been around since about 1999 and the platform is open source - Linux operating system based. It can support a variety of signaling protocols, but by far SIP, the session intitation protocol, for VOIP and other text and multimedia sessions, has become a standard.

For those scratching their head a bit... PBX stands for private branch exchange. It is a machine that handles many businesses telephones calls for you. Its main functions are to transfer calls to different individual phones; play music when somebody is put on hold; to play automated voice responses when a call is received; to provide an options menu for the caller etc.

Asterisk allows one to build their own phone systems. It adds features, functionality and reduces deployment costs in ways which; at first are a little difficult to understand.

How does this relate to amateur radio?

Very simple, the future of two way radio is digital. As of writing, TV are required to be full digital and shut down their analog transmitters in Feb. 2009. The only spectrum broadcasters are required to vacate are channels 64 thru 69 that will become the new "700 MHZ band" that is being auctioned off by the FCC. The vacated areas of this spectrum will be utilized for: Public Wireless deployment (Cellular/PCS); A wide-band private data network that will be shared between public safety and paying customers; and new spectrum for public safety that will butt right up to the re-located NPSPAC National Public Safety Planning Advisory Committee band being moved to 806-809/851-853 by Sprint/Nextel.

Public safety also has guidelines to migrate to APCO-25 digital. The future of two way radio is digital, and we must also advance in this direction. The digital premise is that it generally allows more use in a more efficient/flexible use of band space.

Most present day government communication centers that use analog systems happen to have a VOIP based dispatch console. This analog to VOIP patching is something that we are presently also embracing in ham radio with IRLP, EchoLink, Yeasu WIRES II, and the like.

Your seeing the digital migration in the commercial world as I pointed out; And the only analog part left of traditional telephone is the “last mile” drop to your home. Time Warner and now AT&T are providing digital phone service to close that up too.

As of writing there aren't any 100% directed approaches to tie this to the hobby that I can point you to. There are a number of open ended ideas from a variety of different people. What I'm saying is there is no one entity steering the ship, so to speak. This ideas are still in development. Which makes it precisely the time to jump aboard and get our hands in it and see what we can do with it. So in light of that I suggest a google search for more info...
Digital Voice Interoperability Software Strides
Perhaps some of you remember the ARRL "It Seems to Us: Interoperability" statement from October last year regarding emerging digital voice.

Well the good news is here are some of the strides I've run across:

-OpenP25 Project http://openp25.org/index.php/category/project-status/

"We've determined that the open source Asterisk PBX appears to be a good framework on which to build a P25 ISSI (Inter RF Subsystem Interface) switch. Asterisk has a mature SIP stack and already has the ability to transparently pass RTP frames between SIP channels. The National Institute of Standards and Technology (NIST) has made an open source program for ISSI testing freely available to the P25 community. A full-featured open source P25 ISSI switch is clearly achievable."

The Project 25 Inter RF Subsystem Interface (P25 ISSI) is a non-proprietary interface that enables RF subsystems (RFSSs) built by different manufacturers to be connected together into wide area networks. Apparently consideration is being given to enhancing Asterisk app_rpt to support a such a low-level P25 radio interface.
The open source project25 interface is a good idea. Unfortunately the problem they're facing is that most of the manufacturers don't bother following the ISSI spec, nor does the ISSI spec call out hardware interface details. So basically the "plugs" on the back of say, a Quantar... don't match the "plugs" on the back of a Mastr III.

-Open D-Star Project http://opendstar.org/

The OpenDSTAR group has released several software tools which build on existing commercially available repeaters and Internet gateways to extend functionality.

And this interoperability work in progress attempt has been around longer than the P25 one. They too are working a SIP stack into their DPLUS gateway add-on daemon.
A project is lead by Scott, KI4LKF expand the Asterisk capabilities with his RtpDir bridge software (Real TimeProtocol Director) software package for VoIP/RF Gateways. http://tech.groups.yahoo.com/group/rtpDir/
It can bridges transmit and receive from/to Asterisk/app_rpt, IRLP, Echolink, Speak-Freely and he is working on D-Star. There is support for all link interfaces, sound mode or ASCII mode, VA3TO, WB2REM, ULI, Rigblasters, MFJ, SignalLink, etc.
-RadioGrid RG-4 Radio Gateway. http://www.radiogrid.com/
The guys from NHRC who make repeater controllers have come up with a commercially targeted (and priced) controller called the RadioGrid RG-4 Radio Gateway. It's built around Asterisk open source PBX technology. It's specifically for VOIP linking designed with interoperability applications in mind. It uses a 500 MHz Blackfin processor, 64 MB RAM, 4 MB Flash memory, 1 GB SD Card

A key component in all these digital voice systems is the vocoder. P25 uses the IMBE vocoder from Digital Voice System Inc. (DVSI). It costs $150K to get the rights to play with that mode plus $5 a seat. There is no off the shelf IC to do it. Fortunately D-Star uses AMBE from DVSI they do offer a single chip solution for $20 single qty and are happy to sell to hams.

- The DV Dongle http://dvdongle.com/
The DV dongle is an important development. It was started by Moe Wheatley, AE4JY and Robin Cutshaw, AA4RC. It contains the hardware ability to process AMBE full duplex. Presently software applications exist to use this to communicate from a computer to a D-Star gateway. Further development are in the works so that it can be interfaced to a radio's packet radio port that has the necessary discriminator connections. This may be a huge milestone. The ability to retrofit an existing repeater could be possible with this. Not only that, but you may be able to retrofit it in such a way that it can be usable in analog and for D-Star.

It would be great to see an a D-Star radio that supports something like this on the market possibly before the P25 interface idea ever makes it to the market. We should to encourage D-Star manufactures to come up with a similar style non-proprietary interface for D-Star. As unfortunately at this time there are no known interfaces to the Icom D-STAR radios that allow access to the on-air data stream.

It would be nice to see some agreement and standards in place amongst the various guys working on software solutions and the manufactures, to help make things more stream-lined. Either way people are working on interoperability solutions, toward convergence with open standard codecs like G.711 using real word protocols like SIP and RTP protocols so one can connect the radios together into wide area networks.

Then one would be able to have a D-Star radio in their shack also interconnected to various Asterisk powered applications in their house or abroad. Where if you weren't around to take a directed D-Star call, it could be configured as a DID to a system and use a ring group / follow me list to let the radio caller ring a home phone or leave a voice mail. Calls could be route to/through the Public switched telephone network and so on. A very powerful ability for EMCOMM and personal use.

Second roll out of D-Star

The second phase or revision of D-Star is out there. Both Icom and Kenwood are selling radios for it, it's general name is NXDN - FDMA.. It's know as Icom IDAS (Icom Digital Advanced System) and Kendwood calls it NEXEDGE.

NXDN Forum Announces its Formal Establishment

This is a brand-new digital format was co-designed by Kenwood & Icom that is geared towards the business sector. It is designed for those that want to meet the up-coming FCC mandate for 6.25 KHz channel spacing, but that can't (or don't) want to move to the APCO P25 Phase-II equipment that will soon come to market. The format is based on the AMBE+2 voice codec (similar to ICOM's D-STAR), but uses a 4-level FSK modulation (FDMA). The radios are capable of narrowband analog, along with 12.5 KHz & 6.25 KHz digital emissions. Kenwood is offering the system under the name NEXEDGE, and the radios are capable of both conventional & trunking operation. The attached sound file contains all of the formats the system is capable of producing, including the raw data streams of both digital formats.

D-Star, developed by ICOM, is the forerunner to the commercial counterpart of the technology we now know as IDAS (ICOM Digital Advanced System).

IDAS, also known as FDMA is the system generally best suited for commercial use since it meets all FCC technical standards through 2018 and is backwards compatible with 25 kHz, 12.5 kHz analog systems plus capable of operating in the digital mode on 25, 12.5, and 6.25 kHz channel spacing.

We have been to be Icom's lab rat for their rollout of commercial P-25 Phase-2 products. It's nice to know that the AMBE codec that was chosen for D-Star is slated to replace the IMBE codec in Phase 2 of APCO 25. For once it puts us as ham radio operators into state-of-the-art in communications for the first time in about 10 years. It's so nice to say that.

Audio sample

It uses AMBE+2 codec and 4FSK (4 level FSK) / FDMA (frequency-division multiple access scheme) digital modulation. AMBE+2 codec is compatible with IMBE used by P25 phase I.

NexEdge/IDAS was built off D-Star. Unlike D-Star, the NXDN repeaters can repeat analog or digital so you can have a smooth user migration.

It supports unit ID auto-roaming/registration much like how D-Star works.

Looks like the pricing to get going with NXDN will be about half the cost of D-STAR implementation. NXDN is like MOTOTRBO in that it can support mixed mode, but whats nice unlike MOTOTRBO & D-Star is more than one manufacture making radios & costs less on both accounts.

An ID-RP2C Repeater Controller for D-Star runs about $1500. You need to add an band specific RF voice module such as the ID-RP2000V for 2 meters which is another $1400

Where as the Icom IC-FR5000 Series VHF and UHF Repeaters run about $1500. This NXDN route also provides the analog/digital mixed mode backwards compatibility that D-Star doesn't.

The user end radios between D-Star and NXDN appear to be very similar in price.

The best overview I have found:
http://www.mygmrs.com/nxdn/index.php

I'd like to think that now since Kenwood is making AMBE Digital voice radios for their Nexedge, that one might see a Kenwood D-Star radio here in the US in the not to distant future.

If they do this, I hope they can improved upon the current Icom line.

Poorman's P25 / D-Star repeater using Maxtracs

This diagram on how to use two Motorola Maxtracs is from Tim Warth, AA2RS.

This is perfect if you don't have the 3 grand to put up a D-Star repeater or can't find a good deal on a Motorola Quantar for P25.

Remember this mod is transparent. ANYTHING it hears that breaks squelch, including intermod and spurious noises, will get repeated. Data is not regenerated.


As shown, the TX audio must be routed to the new point of entry, otherwise, it gets filtered and 4 level FSK won't pass. It's recommended to do the Maxtrac power mods and putting active cooling on the radios as these radios get hot.

In most cases a carrier system is less than desirable. Fortunately Rick Parrish, KD4VXY (the author of Unitrunker) has written a software based NAC decoder. Unfortunately at this time it it does not yet have support to provide a serial or parallel port logic output.

It's worth looking at the CML Microcircuits CMX7031, and CMX7041 datasheets. It's A C4FM baseband data processor chip.  After some microcontroller coding, this could work similar to how the D-Star node adapters work.  (Those typically use the CMX589AP4 chip)

1.2 GHz HSMM with the Icom ID-1

Back in June 2004 we inquired about Icom's 1.2 GHz ID-1 D-Star solution for ham radio voice and data communications. We were fortunate enough to be able to evaluate it for a few months.

Our short documentation is located at:

http://www.qsl.net/n9zia/dstar-evaluation/

You can also read the Wisconsin Amateur Packet Radio review here:
http://www.qsl.net/kb9mwr/wapr/0204.html

We were most interested in the data performance and networking ability of the D-STAR system. The only radio that can do any significant data transfer is the 1.2 GHz ID-1. It's listed with a (theoretical value) transmission speed of 128 kbs. We clocked an effective TCP/IP throughput of 90 Kbs. Perfectly understandable considering protocol overheads.

We didn't have a lot of time to mess with it. Our initial path was a 4 mile hop, but that was just on the fringe due to the Packers stadium in the middle. We could communicate using the digital voice mode and analog FM, but not the digital data. A few more feet of height might have done it. We were at 60 feet at the remote end, and 40 at the other.

So we opted to test the data performance on a much shorter path with another local.

The lesson learned is even at 10 watts on 1.2 GHz, verses the 1 watt or less on 900 MHz or 2.4 GHz, microwave path loss doesn't change much.

So in our case for much, much less money we can accomplish the same paths at even higher speeds using other hardware. What would be interesting is to see how well the ID-1 would work mobile. I do believe it would work quite well for this compared to the alternatives.

{edit} Reports indicate that it takes a very solid signal into the Access Point/DD system to work well. And works good over a large area when non-moving, but motion/multipath tears it up. A continuous ping by with a 1.2 GHz radio would start working at very stop light, and stop as soon as was moving.

After having looked at the various documentation, the Digital Data (DD) mode of the 1.2 GHz Icom ID-1 is a rather strange design.

There is reason for concern on that the amount of overhead is huge (D-STAR header + Ethernet header + IP header), and that the FEC as implemented is a bit strange (why does it only apply to the D-STAR header, and not the Ethernet frame?). Further the protocol has no real mention of channel access concerns (collision detection, avoidance, etc). It really looks to me like DV with ethernet frames stuffed into the payload section (i.e. maybe it was somewhat of an afterthought).

All the DD mode appears to do is forward ethernet frames around. On its own, it does not do any acknowledgment/handshaking. This is all left to the upper-layer protocols (i.e. TCP).

It appears that if a collision happens then the DD packet is just lost, and there's no really mechanism to avoid collisions at the DD layer, either. It's up to the higher-layer protocol to do anything about it.

So you really have no indicator of channel quality when using it. The lack of this sort of thing seems like a major oversight. It looks like packet radio done badly, although with better speeds. If it were introduced 15 to 20 years ago we would have hailed it as the savior of packet radio, but now it looks like a poor imitation of WiFi.

To further, it doesn't help most of what you will read on the other D-Star Yahoo groups shows that the ID-1 isn't being used with good RF engineering practice leading to poor results.