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.
| Signal | NQSMHS DE-9 Pin |
Molex 1625-15P Pin |
My Wire Color |
|---|---|---|---|
| Modulator In | 1 | 3 | White/Orange |
| COS/RUS | 2 | 13 | Orange |
| Discriminator Out | 3 | 4 | White/Green |
| PTT | 4 | 8 | Blue |
| Ground | 5 | 2 | White/Blue |
| +12V Power | 9 | 7 | Brown |
| Jumper | - | 1 to 11 | Green |
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
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.
^[A-Z0-9]{1}[A-Z0-9]{0,1}[0-9]{1}[A-Z ]{4,8}[A-Z 0-9]{0,1}$
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.
I have been interested in D-STAR for a number of years and finally took the plunge in 2007 and bought my first D-STAR radio. It is an Icom IC-91AD and I still use it today as my handheld connection to the D-STAR network. Since that time, I received a very nice Icom IC-2820H mobile radio and recently purchased an ID-880H for use at the desk here in the ham shack.
During my whole D-STAR journey I have been intrigued with the software/networking side of things and have studied the various applications that others have written and have goals to write some myself. To that end I am the gateway administrator for a D-STAR repeater system in Bellevue, WA, owned and operated by the Lake Washington Ham Club. This repeater system is a very high end system and sits atop a 42 story building. Consequently, it is a resource for both casual amateur radio use and for two ARES (emergency communications support teams). This is probably not the best place to experiment with new software designs that may take the repeater(s) down.
There is a growing community that has started building D-STAR compatible devices using GMSK modems, called “node adapters.” These devices typically connect to a computer using an USB cable and provide GMSK modulation and demodulation when connected to the discriminator and modulator of a true FM radio, as well as detecting signal presence and providing transmitter keying when there is data to go out. I purchased one of these “node adapters” several months ago and have been playing with it, using various radios available around the shack.
I have never had an interest in owning my own repeater, but I got a hankering to build up a repeater to support my experimentation. With the help of a friend who is in the commercial 2-way radio business, I was able to purchase a used Kenwood TKR-820 UHF repeater with a duplexer. I wired the node adapter to its accessory plug and after a few adjustments and tweaks have a fully operational, albeit low power and short antenna, repeater that talks the D-STAR protocol using GMSK on an FM carrier. It is fully compatible with commercially produced D-STAR radios.
It is on the air, from my garage, on 440.0125 mHz. with a plus 5 mHz. receiver. Even at its low power and without the antenna mounted high above the ground it is still usable for a couple of miles around as I drive and have friends with higher home antennas who have been able to talk through it from a couple of towns away in Brier and Whidbey Island, WA.
In future posts, I will describe, in greater detail, the steps to create a similar repeater.
Several weeks back, I did an interview about D-STAR with Ted Randall on his QSO Radio Show. It first aired on shortwave station WBCQ on 10 December 2009.
It is available as a podcast: WBCQ Interview
Intrigued by the efforts of Jonathan Naylor, G4KLX, I decided I would try building a little, experimental D-STAR compatible repeater.
Jonathan has created a piece of software to act as a controller for both analog and D-STAR repeaters. It runs on Windows and Linux and has a minimum of additional components.
You need the typical radios, duplexer, antenna and so forth to build the repeater. Then you add:
Jonathan’s software, found in the files section of pcrepeatercontroller Yahoo! group, does the rest. It is the GMSK modem and the control logic for the D-STAR repeater.
After obtaining a Velleman (VM110 the assembled version of the K8055 board kit), I first tried this with some Friendcom UHF 301 radios. My documentation isn’t that good on these and they were a bit problematic, though I at least got them to sort of work, but the output signal wasn’t usable — probably my fault rather than the radios. I decided then to try a couple of Yaesu radios, a FT817 for the receiver and an FT847 for the transmitter (they were handy).
Using the standard 6-pin DIN “packet” connector on the back of each radio, I was able to connect them to the USB soundcard and a Velleman VM100 USB project board for COR and PTT.Both radios were configured for 9600 baud packet operation.
Within Jonathan’s D-STAR repeater program, I had to configure my repeater callsign NW7DR B and tell it I was using the Velleman board (his software now supports a serial port or the URI Board for COR/PTT) and set the COR to use inverted logic and the transmitter to invert the signal. Once this was all put together, a little twiddling with levels on the audio and it just worked!
I strapped this together in a couple of hours and the coax is cheap stuff so I have a fair amount of desense so no real range, but around the house it is beautiful.
BTW, this code can also talk to a gateway to interconnect with other D-STAR repeaters.
Loads of fun … 73 for now.
Well, I’ve provisioned a couple of D-STAR gateways, and have helped with some Icom repeater work, but I have never built a repeater from the ground up. I have hit a milestone in that area.
I have been following, with interest the work of G4ULF and his Linux based G2 compatible D-STAR repeater project. It uses the GMSK boards originally created by 7M3TJZ and the new design by PA4YBR. I have the loan of such a GMSK board, but recently G4KLX made major strides with his sound card based controller program and so I thought I would give it a try.
This design requires a cheap, unfiltered sound card like those USB fob type for around $8. A pair of radios that can handle the GMSK modulation (I am working with a Yaesu 817, maybe my 847, and a couple of Friendcom FC-301/D UHF radios, for experimenting – a true repeater needs some solid radios, but these are great for learning the system), a circuit to handle the PTT/COS signalling for the program, currently the Vellman 8055 board (< $50 on the Internet in Kit Form, look for V110 if you want a preassembled unit) is supported. Then the usual duplexer, antenna, power supply, and a PC (Windows or Linux) to drive it.
Tonight, I worked through an issue in getting my transmitter working (pin 8 of a Friendcom must be pulled high to work), and using the 817 as a receiver, I was repeating D-STAR, and the ole’ club callsign was there for a legal ID. I still need to tweak audio levels a bit, as it is heavy R2D2 at the moment — but what a blast. BTW, this code will also talk to a gateway. I don’t have a gateway installed, but on one of my Linux boxes I set up a UDP listener and saw the data coming over for a gateway.
I’m not going to have a lot of chance to work on this again until after Thanksgiving (maybe some time tomorrow, to tweak) — but this is going to be a fun adventure that will hopefully lead to some new applications for D-STAR from yours truly.
73 for tonight
A couple of months back I was contacted about doing an interview for an article on Amateur (Ham) Radio. Today it was published in Computerworld.
I was honored to be asked to be interviewed for this article, it was a lot of fun to remember my more than three decades as a ham radio operator and to talk about some of the ways it has impacted my life and career. I think John Edwards did a great job on the piece.
I did provide him a good overview of our efforts with D-STAR and specifically included kudos to both Robin Cutshaw (AA4RC) and Pete Loveall (AE5PL) for their excellent additions, but that did not make the article.
Read and enjoy.
While discussing the issues surrounding interconnection of non-DSTAR (analog – VOIP/ROIP) systems to D-STAR, I have had several people say “but the ID cannot be translated” between systems. This has been brought up in a couple of person to person discussions in just the past few days. Whether you have such interconnection or not, for the purposes of the US regulations, this is a “red herring” argument.
ID requirements are for the originating transmitter (Rule 97.119). It does not have to be relayed, translated, transcribed, etc. It only has to be copyable on the signal of the original transmitting station. Practical examples of this are link transmitters on linked repeater systems, the link transmitter may use a low frequency tone to CWID its transmitter, but it is filtered out on the link receiver so that it is not relayed on the next repeater. Anyone monitoring the link transmitter would be able to extract the ID, meeting the regulatory requirement, but those on the linked repeater would not. If you have ever been on a wide area linked repeater system, such as the Evergreen or Snowbird interties, you will note that you do not normally hear the IDs of remote repeaters, even though every transmitter (including link transmitters) must ID. Move this to an analog to D-STAR or D-STAR to analog relay and the same situation exists, the transmitting stations must each individually ID; the D-STAR user, the D-STAR repeater, the analog repeater, any links, and the analog user, but there is no requirement that those IDs be heard on every transmitter in the circuit.
This message is not advocating the interconnection, it is merely to point out that the ID argument is not valid. A given gateway operator may have other reasons for not wishing interconnection, and it is within their rights to deny it.
Some other countries have the requirement that the receiving station be able to copy the originating station’s identification to engage in a communication. It is my opinion that this becomes the responsibility of the station in a country with such a regulation to inform the station with whom he is communicating of the need for the identification information, which could be provided a number of ways, as a courtesy, but the network has no responsibility to automatically provide that identification. Each station is responsible to follow the rules and regulations that apply to his individual operation and not the rules and regulations in another country of which he may or may not have direct knowledge.
A response to a question from K2AAU on DSTAR_DIGITAL at Yahoo! Groups
There is a fundamental difference between D-STAR and the VOIP systems like Echolink, IRLP, WIRES, AllStar/Tiara, …
On those other systems, the approach is to take analog audio from a receiver, and with a computer/soundcard, convert that audio into a digital format for transmission across the Internet, where it is immediately switched back to analog audio for a transmitter. The radios and repeaters involved are the same analog FM that has been around since the early amateur radio repeaters in the middle of the last century. This is what people are familiar with and they approach the connectivity issues from that frame of reference. Nothing wrong with that, it is the way we humans approach problems, building on prior experience.
D-STAR is a paradigm shift for the amateur community. It isn’t about merely moving voice (audio) from one location to another. It is, in every sense, a digital mode.
A D-STAR transmitter (for Digital Voice or DV), translates, compresses, and encodes the “audio” into a digital stream using AMBE, at 2400 bits per second, within the radio. That digital stream is also given some forward error correction (FEC) consuming another 1200 bits per second. This FEC is a factor that allows D-STAR transmissions to recover the original audio content and deliver clarity when the signal is very weak (on analog FM it would have a great deal of noise – here is a video comparing the two in real time http://www.youtube.com/watch?v=FyYhLtS-0gE – not english, but clearly shows the difference). The actual transmitted signal is encoded at 4800 bits per second, so removing the 3600 bps for the audio, there is another 1200 bps that can be used for various ancillary communications, including position reporting (GPS coordinates), short message service, and various contextual pieces of data. This additional data has been exploited for some fairly sophisticated applications, such as D-STAR TV (sending images), D-RATS (chat, message passing including email gateway to the Internet, TCP/IP tunneling, …), etc. This combination of digitally encoded audio and ancillary data is always in the data stream in a D-STAR (DV) signal, whether the audio is silent or not — it is there, whether the “data” portion contains all zeros or one or more of the listed data items — it is there – they are inseparable. This data stream is modulated onto a narrow (6.25kHz.) FM signal using GMSK modulation.
A D-STAR receiver, on the other hand, receives the narrow FM signal, and using GMSK demodulation, extracts the data stream, and processes it through the AMBE chip to deliver the audio and the ancillary data mentioned above. If you were to listen with a traditional FM receiver you would hear what I call “structured noise.” You can tell it is not natural, it has patterns in the noise.
A D-STAR repeater doesn’t convert this datastream to audio and ancillary data, though it does examine the data stream to know what to do with the payload (Callsigns, control bits, and so forth). In fact, you cannot tap audio out of the D-STAR repeater directly. In the Icom repeaters, I’ve been told the audio sections of the radios have not been populated. The repeater directs this digital stream from the receiver to the transmitter, in digital form, and optionally sends the digital stream via the controller to co-located repeaters (based on callsign routing) or to a gateway computer. Again, the gateway computer keeps everything at the digital level, and based on information from the datastream optionally directs the datastream to remote gateways, which, in turn, passes that digital signal to a controller, which sends it to the appropriate repeater module, and on to the user radio, where the audio and ancillary data are ultimately decoded.
The gateway computer is connected to the controller using Ethernet, and by specification must be “close” to the controller (from a latency point of view). In most installations the gateway computer is co-located with the controller and repeater decks and the Internet is brought to the computer at the repeater site. (The Greeks report having separated the computer from the controller by some distance using low latency WiFi style connections, but this is not typical.) The Internet connection must be stable, low latency, low jitter (inter-packet timing should be stable, it doesn’t work well through satellite connections, because those circuits will buffer and burst packets creating high jitter), and have an IP address for the computer that changes infrequently. It also requires a router with certain characteristics (LAN side Class-A address space).
The gateway has many functions to perform including keeping a database of all known callsigns on the D-STAR network and what gateways have most recently heard them. This is why on D-STAR you can tell your radio you want to speak to a specific station (callsign) without knowing what repeater (worldwide) the station is monitoring, the gateway system will figure it out and send your signal (datastream) to the right repeater and ultimately to your desired receiving station. In order to keep all of this data up to date, the gateway needs sufficient bandwidth to send and receive the datastreams for each of the attached repeaters to the various destinations, including a potential 128 kbps, usually TCP/IP, stream (from 23cm DD mode – Ethernet over the ether), as well as the command and control, data synchronization, etc.
So, as you can see, this system is much more complex, and powerful, than the VOIP pack (IRLP, Echolink, etc.) that are only concerned with routing audio from one repeater to another over the Internet. In D-STAR, there is simultaneous audio and data, that must traverse the whole network.
For these reasons, you will not be able to provide the services that D-STAR users want and expect without a decent, reliable, and moderately high bandwidth Internet connection. In D-STAR, you need to understand and provision a network, not just a radio link.
STARnet Digital at Yahoo!