John's Meanderings

Every few months, the various D-STAR forums have someone come on and say that AMBE was a bad choice for D-STAR and that it should be replaced by CODEC2 or some other open source CODEC.  Side note: AMBE is not a codec, its a vocoder.

Here is my latest response.

I don’t think anyone is saying that AMBE/D-STAR is the only way to do digital voice on Amateur Radio.

I think what people that do the work, understand the system, and have been at this for awhile get tired of are just a few key points:

1. Beating up D-STAR over the use of AMBE
• It’s just a part, like a microprocessor, DSP, etc.
• It is the best commercially available, off the shelf, component to provide digital human voice over the radio
• It’s price is reasonable (how it is packaged by some vendors for sale is pretty high for their BOM)
• It is used in other Amateur Radio products (AOR ARD  digital voice, Alinco digital voice, NXDN, MotoTRBO, next generation P25) without the same vitriol.
2. People saying we can just modify D-STAR to use Codec-2 or some other Codec
• Those of us who work with interoperability and implementation standards understand the issues with making non-standard changes to a protocol.
• Standards are controlled through a process (that the JARL doesn’t execute well), which is where changes should be vetted, voted, and documented.
• We shouldn’t confuse consumers of a protocol by implementing something different and give it the same (or very similar) name.
• Introduction of incompatible systems into a working and established network or protocol framework creates unneeded issues.
3. People taking a narrow view of what the protocol means
• If you only look at Digital Voice you are leaving out much of the D-STAR protocol
• Not considering side effects
• Not understanding how one interconnects incompatible protocols  (through the use of bridges, protocol gateways, etc.)
4. Market, social, investment, and cultural aspects
• Acknowledging that most operators want a self-contained radio whether a handheld, mobile, or base.
• Interconnect issues to external devices creating more points of failure
• Aesthetics – lost on the experimenter, but for the larger community there is value in an attractive package.
• They want to buy something off the shelf that is ready to use. (USTrust registration is problematic for this)
• People who have made investments in infrastructure (repeaters, gateways, etc.) don’t want them “broken” by non-compliant systems
• Some people like the clarity of AMBEs vocoder and don’t want it mixed with analog or even other systems that don’t fit the same profile.

I, and I venture many others, look forward to additional digital voice and data options.  Maybe something will come of Codec-2, maybe not.  If it proves to be a better technical (not religious) solution and a manufacturer picks it up to create the self-contained radios to build out an entire network like D-STAR, great, the market will decide.  I believe digital is the future and it will evolve, but basically I think the plea is basically, bluntly, “put up or shut up” — in other words, do the work to build something and put it out, in the meantime use what is available without this continued babble about how evil AMBE/D-STAR is and if “somebody” would just make “this change” it would be so much …

Let’s use the D-STAR and related forums and groups to work on D-STAR.  If one wants to do something different create your own community/forum/group and have at it.

Last week a few changes and improvements were made to NW7DR B, my Kenwood TKR-820 modified for compatibility with D-STAR.

1. With the assistance of my son, James – KC7OSO, the antenna was moved from the deck of my house, to a pole on the roof.
   
2. With the assistance of David Lake, G4ULF, I upgraded the gateway software to NI-STAR and moved the system over to the USROOT Trust Server. Included in this install are DPLUS (linking) and D-PRS (GPS reporting) support.
3. I integrated ircDDB support.
4. Here is the new coverage plot for the repeater as computed by SPLAT! (Coverage is primarily in the yellow and red/orange area — due to low power of the repeater):
   

More later…

Here is a pdf file of the slides I used for the development presentation at DCC on Friday: D-STAR for the Technically Curious

Several of the open source packages mentioned in the presentation seem to have been moved from the locations listed, you can find many of them here: KB9MWR qsl.net VOIP/DSTAR

Here is a pdf file of the slides I used for the introduction presentation at DCC on Saturday: DCC D-STAR Introduction

Converting the Kenwood TKR-820 for use with D-STAR is almost trivial. Here is what you need to do this project.

First you need a TKR-820 (or 720 for VHF) complete with duplexer, antenna, etc., tuned to your repeater pair.  These are currently available on E-Bay (repeater and optionally a duplexer) for around $250-500 as pulled from commercial service. This is a nice little repeater which can run 5W for 100% duty cycle up to around 25W at a decreasing duty cycle. (I’m running around 10 Watts.)

NQMHS w/DE-9 Plugged-In

Next you need to purchase a node adapter.  I use the “Not Quite So Mini Hot Spot” (NQSMHS) board from ENIcommunications. It comes either as a kit for $80 or pre-built for $110.  I chose the prebuilt version and this post is based on using this version of node adapter.  There are others in the marketplace, but I cannot say if additional work will be required to use them with the TKR-820.

The next order of business is building the cable to go from the NQSMHS to the TKR-820.  The NQSMHS uses a DE-9 plug and the TKR-820 has a great accessory jack which is a Molex 1625-15.  I had a DE-9 socket in the junk box, and purchased the 1625-15PRT, socket and plug, from the local Fry’s Electronics.

DE-9 Example

The pinout for the DE-9 is as follows:

1 – Audio to Repeater (Modulator)
2 – Carrier Operated Squelch from Radio (Not actually used with the PA4YBR firmware, but I wire it anyway)
3 – Audio from Repeater (Discriminator Audio)
4 – Key Repeater Transmitter (PTT)
5 – Ground
9 – +12VDC (To power the node adapter, use this instead of USB power for better reliability)

Molex 1625-15P Example

The Molex 1625-15P (plug) pinout:

Jumper pin 1 to pin 11.  This tells the Repeater it is being controlled by an external controller via the accessory plug (green wire in photo).  Note: if your repeater happens to have an ID-8 module, you will get a CW-ID periodically.  You want to remove or disable it.

Pin 2 is used for ground to the NQSMHS board.
Pin 3 is the modulator input (audio from the NQSMHS)
Pin 4 is the discriminator output (audio to the NQSMHS)
Pin 7 is a +12 VDC source (1 AMP – verify fusing when sourcing)
Pin 8 is the external PTT line
Pin 13 is the carrier operated squelch (COS) also documented as RUS by Kenwood.

Check all of your wiring.

Please verify these pinouts against documentation for each device. These work for my configuration, but your repeater may be different. No warranty is expressed or implied. Perform at your own risk.

You will note that no conditioning of lines, such as bypass capacitors, resistors, etc. are included in these instructions. My repeater and board just play together nicely.

This should complete your cable.  If you haven’t guessed I used a piece of CAT-5 cable between the connectors. (Shielded/Stranded cable would be better – I also add some clamp on ferrite cores to this and especially the USB cable.)

Plug the DE-9 into the NQSMHS (as above), and the Molex 1625-15P into the repeater.

Molex 1625-15P Plugged into TKR-820

Attach the antenna (or service monitor) and power, adjust the NQSMHS and the modulator for approximately 1.2 Khz deviation.  Adjust power for your use.

Using the firmware tools, insure that transmission is of the proper format (inverted/not inverted) and adjust the NQSMHS for proper detection of data coming from the repeater.

Screen of DVAR Hotspot in operation

You can now fire up DVAR Hot Spot, with proper configuration.  With a properly registered callsign and configuration you should now be able to link to repeaters, reflectors, and other HotSpots. Note: I tried a netbook to run DVAR with this NQSMHS and it would not key PTT, I think it was a USB drive level. switching to a full size computer solved the problem.

Here is the final product for the NW7DR repeater:

This is the NW7DR Repeater in operation

My repeater is literally a classic “garage repeater.” The TKR-820 should perform in traditional repeater settings, though for such high RF installations better cabling and packaging of the NQSMHS (shielded) is probably warranted.  The NQSMHS could be mounted internally to the case, pushing the Molex socket inside and running the USB cable out the opening to the controlling computer.

My plan is to move this repeater over to G4ULF’s G2 compatible gateway software after release.  I have a lovely 1U Linux server just waiting to replace the surplus Windows/XP tower currently attached to the NQSMHS.

[UPDATE]

I am currently running Jonathan Naylor’s ircDDBGateway, to support STARNet Digital, along with the GMSK repeater in pcrepeatercontroller.

You can see the Dashboard at NW7DR

[/UPDATE]

Good luck with your conversion!

The question was asked by a Russian ham:

“Do we have a procedure to implement this feature (air interface authentication) in D-Star?
For radio digital protocol it should not be difficult technically.”

There is nothing in the protocol to support authentication, it only provides identification.  Current generation radios implement the standard and that standard has no mechanism for authentication.  Authentication would have to be an add on application and for current radios, that would mean some form of external device to handle the authentication mechanism.  Any true authentication would have to have an irrefutable token, probably some public/private key mechanism with distribution of keys to licensees off the air (e.g. via secure Internet transfer).  In some countries it may be problematic to use such an authentication system since it might include an encrypted token between radios and some countries forbid encryption on RF, though this might be considered a control signal.  Such a system also would be fairly impractical because of database size and updates for mobile stations.

You can’t depend on a network based authentication service as such an extension would, by definition, have to support simplex transmissions off the network.

For most of us, there is no need for such a system as this is amateur radio, a hobby, and largely self policed.  There are regulations that can support prosecution of those who choose to abuse the hobby.  For example, in the US it would be very easy to say that anything other than the operator’s station callsign in the “MYCALL” field of a D-STAR signal would be a false identification, which is expressly forbidden in the US Regulations  97.113a(4) “…messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein; obscene or indecent words or language; or false or deceptive messages, signals or identification;” …  There will always be callsign pirates and those who do not identify at all, and weak authentication just will encourage increased anti-social behavior.

At the repeater/gateway level, it would be fairly easy to filter out calls that don’t have recognized callsigns.  This should probably be implemented.  I have written a regex (Regular Expression) filter that is pretty effective in finding patterns that look like amateur callsigns or one could implement a filter that checks a database of callsigns (such as the G1/G2 registration system), but none of these prevent pirates.  One hazard of such a filter is bit loss in the address fields creating an unrecognizable callsign, which would be rejected for an otherwise legitimate transmission, with no feedback to the transmitting operator who may speak for an extended period.

I support a no pre-registration approach. A new user should be able to buy a radio, program MYCALL, and get on the network from RF (network connected devices are another story).  This means either the filter has rules of what a MYCALL should look like, or have automatic lookup of any and all callsigns issued — pretty easy to do in countries like the US where the license database is a public record and freely distributed (with daily updates) but may be nearly impossible in countries where such data is not freely and regularly available.

So “technically” solutions could be derived, but from a regulatory, D-STAR standard extension, and pragmatic point of view, this may be very difficult.