John's Meanderings

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:

• Linux or Windows Computer
• Cheap soundcard (I use a cheap < US$8 USB sound fob — you want cheap, no filtering)
• PTT/COR device (Velleman board, Serial port, or URI)

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

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.

Tonight I went to a nearby location for the Puget Sound D-STAR Roundtable.
Well nobody showed up, so I did what I have done before and looked for other D-STAR repeaters I knew about. Well, I brought up VE7VIC C and had a lovely QSO with Jim, VE7GOF.  The repeater was strong for me and I showed up at jfindu.com and dstarusers.org -

Now, I’ve used this repeater before, from near my brother’s home in Sequim, WA which is straight across the water, but this was a pretty good shot from Edmonds, WA. (  K7VE 47.78800N 122.36950W).

I plan to visit VE7VIC again from my little perch a couple of blocks from my home.

A response to an email …
A correspondent wrote:

I … got caught in a circular argument with myself. hi hi e.g. it would be neat to couple this [interconnection of multiple VOIP based linking systems] with APRS presence info and route the audio to the closest repeater.

Well, D-STAR (sort of) does this already. When you “key” a D-STAR radio on a repeater that is connected to the international D-STAR network, its presence is known, (after a little time) to the entire network of repeaters, so a call to K7VE on any repeater in the network should reach me, regardless of whether I am in Seattle, Atlanta, Denver, Paris, London, or Melbourne without regard to what band or frequency I am currently on, be it 2m, 70cm, or 23cm. My geography just doesn’t matter from a communications point of view. If I happen to be sending GPS reports into the network, then you certainly can “see” where I am geographically, but you don’t need to know what repeater (node) I am on, what band I’m on, etc.

On D-STAR you have two primary modes DV (Digital Voice) and DD (Digital Data).

DD is only available (currently) on 23cm and is basically an Ethernet pipe over amateur radio at 128 kbps.

DV is a bit more complex than traditional VOIP repeater linking (IRLP,etc.). The first ¾ of the data payload on DV is devoted to passing digitized audio, using FEC (forward-error-correction) on a very low data rate signal (approximately 2400 bps for the audio and 1200 bps for error correction), the other ¼ of the data payload is devoted to a data messaging service. This data messaging service can convey a variety of data, including messages and GPS reporting. There are other applications that use this portion of the signal, for example D-RATS (http://www.d-rats.com/wiki/) and D-PRS (http://www.aprs-is.net/DPRS.aspx). These two items (audio and data) are inseparable on the RF signal, e.g. if you send voice, you are also sending data, if you are sending data, you are also sending voice, whether the accompanying portion contains intelligence or not. You certainly can extract each from the other at some point, but then you loose context and a portion of the communication “package” – so when you link audio VOIP systems to/from D-STAR you are only interfacing a portion of the D-STAR signal. Also, in the D-STAR paradigm, the encoding and decoding is only at the end points — in other words the analog voice to digital and digital to analog voice happens in the radio, not on some node. These are the issues for the D-STAR purist when it connects with a non-D-STAR system, there is loss of function and potentially a critical portion of the communication.

On D-STAR I don’t have to have a separate radio reporting my GPS coordinates into the APRS network, that would somehow be available to IRLP, Echolink, etc. to try to route to my “nearest” repeater. I might not even be on the repeater you are routing to, as I may be in range of dozens, if not hundreds of repeaters. (Sure I could transmit that in the message portion of an APRS message, to be parsed and fed to the routing algorithm, but then you have to remember to update that on APRS and make sure it doesn’t age too much). Actually, it turns out, if you want this functionality its cheaper to buy a D-STAR radio, than buying two radios, a TNC, a tracker, and potentially a PC to update the messages. The network just handles it on a single mike click of the radio in range of a D-STAR repeater.

You can see an example of this reporting at http://dstarusers.org (drill in a bit by clicking on a node callsign)

I’m finally in reach of a DSTAR repeater again.

W7HR put up a DSTAR repeater and I can get into it. Handheld from the parking lot of my office none the less.  Randy and I have been chatting back and forth about this upcoming repeater since before I left Utah.  It is in a great location west of the Puget Sound.  The site info is at http://www.wd7str.org/

No gateway for now, but at least I can get into it.  The other Seattle area D-STAR repeaters (which do have gateways) are at low elevation.

Update (5/12/2009): I visited the repeater site 5/2/2009 and its a great facility. I have procured a rack and server to add the gateway and Randy has radios for an Internet link – woot!

73 for now