My day job is as the IT Executive for MaverickLabel.Com
We launched a new website tonight @ www.mavericklabel.com
Come on by.
My day job is as the IT Executive for MaverickLabel.Com
We launched a new website tonight @ www.mavericklabel.com
Come on by.
The D-STAR network is all gateways and repeaters/simplex access points – USRoot/ircDDB/Japan Trust are all ways to enter or exit the network.
I attended Hamvention® in Dayton, OH again this year. This brings my visit total to around a dozen times, always travelling from the western half of the US.
Hamvention® is a gathering of Amateur (Ham) Radio operators and draws from 20,000 to 30,000+ visitors for one weekend in May every year for over 50 years. It’s a time to catch up with old friends, visit commercial and flea market vendors, and attend some educational seminars, or just plain have fun hanging out with your buddies from all over the world.
Most years I have wandered around the exhibition halls and flea market to see if there was any treasure I could buy at a good price, attend a seminar or two, and socialize with amateurs from around the world. Sometimes, like last year, I would volunteer to man information booths for aspects of the hobby that interest me. This year was going to be different!
I had 3 objectives and they consumed the whole time I was there.
The most minor of these was to look for a good deal on Icom’s latest D-STAR® handheld, the ID-31A. It has a lot of new features that make it a new breed of handheld. It has a built-in GPS which, when activated, reports your position through a repeater and over the Internet, this is an interesting feature, especially in public service, search and rescue, and emergency communications as it keeps you on the map. The ID-31A has an internal database of D-STAR® repeaters, which you can update via a MicroSD card or serial cable using online data, which includes the latitude and longitude of each repeater. Because of this database and GPS, selection of a nearby repeater is a couple of button pushes! If you travel it saves a lot of homework and fiddling with the radio to get it on the right frequency. It’s memory layout is a lot more flexible when you want to change who or what you want to talk to over D-STAR®. So, like I said, I wanted one. To my surprise and delight, I didn’t have to scour the booths for the best price (I heard they may have sold out) as I won one as a door prize at a dinner the first night I was there!
The second objective was to put on a good D-STAR® Forum on Friday afternoon. The purpose of the these forums is to introduce people to the topic if they are new to it, and to provide some tips to those who are more experienced. I was honored to be selected as the forum organizer/moderator this year. I lined up some experts from around the country that had a track record. I went first and took care of the basics of getting digital voice, then introduced topics on DIY radios, repeaters, and gateways. I also presented a quick overview of STARnet Digital. The presentation stand was hot, and we were pressed for time, so I wasn’t as engaging as I like to be in such venues, but I made my time mark. I think overall the forum went well, considering the talented folks who presented. My slides are available here.
Lastly and most importantly, we introduced a new radio by NorthWest Digital Radio. The history and creation of the radio, along with the company, is an interesting tale –
Back in the late 1970s, a digital movement started in Amateur Radio. Ham’s were creating digital protocols for radio, and developed what became known as Packet Radio. At that time, the Internet wasn’t as pervasive and over the radio email, bulletin boards, chat rooms and file sharing were intriguing enough that many hams spent a great time and energy building networks on packet radio. It mostly ran on 1200 bps modems over analog FM radios. I was very involved in the movement, being an early adopter even before standards were settled. Gradually, over the years, the networks fell into disuse as the Internet rose, but a hearty few found applications that used the network and there are very active communities on packet for emergency communications and position reporting (APRS). The path to a higher speed network, that could travel many miles, was and is elusive, so much of the data for these applications is still 1200 baud or less.
Along came the JARL (Japanese Amateur Radio League), who invented some protocols for digital voice and a data service. These protocols are open and available for anyone to implement, and Icom Corporation jumped in providing radios, repeaters, and access points along with software to allow local pockets of activity to reach others via Internet transport. After a slow start, D-STAR has grown to a world wide network of interconnected repeaters and access points.
I got interested in D-STAR a few years ago and was intrigued by the data service side of things, but there were a couple of barriers. The radios for it only operated on the 1240-1300 Mhz. band, which makes putting up good feed lines for antennas expensive, and properly done beyond the average technical skill of the users. The radios also are quite expensive, having a street price in the range of $1000 after nearly a decade on the market and because of the cost of components to generate high power at that frequency range, they only run a few watts to the antenna. So not a lot of hams are ready to put out that amount of money for a 128kbps data radio. It’s a fine radio, but these factors hurt its adoption.
Fast forward to September 2010 and I was giving a couple of talks on D-STAR at the Digital Communications Conference sponsored by TAPR (who brought us much of early packet radio), in Vancouver, Washington. I did a talk on “home brew” D-STAR Repeaters and after going over what was happening in the area of DIY on D-STAR, I had a list of things I would like to see. One item on that list was a radio for D-STAR’s data service (Digital Data or “DD”), it would be a simple “headless” radio, power and Ethernet in one end and a good antenna connector at the other end, affordable, and simple.
After the talk I was approached by a gentleman, who introduced himself as Bryan Hoyer, along with his friend Basil Gunn, and that he would like to build that radio. He lives on San Juan Island between the mainland and Victoria, BC, Canada in Washington State. Over the next several months we three became friends and started meeting to plan the radio.
Bryan, living on an island, is very active in Emergency Communications, and had noted that most of the data communications systems developed by hams were still this 30 year old packet technology, sometimes lashing together an old computer, an old modem/TNC, and an old radio.
Today with very high integration technology both for computing and for radios, all of that can be built into a quite small package and as long as you have a full computer bundled in with the radio, there is no reason not to support multiple protocols and applications in the radio. There’s no extra hardware to do so, it’s a matter of software and firmware.
We stayed true to the original concept, while providing additional capabilities in the design. All digital radio is 1s and 0s going to and from a modem and the transmitter and receiver. After surveying the available components we were able to come up with a design called the Universal Digital Radio or UDR, the break-out model is designated the UDR56K-4. This radio operates on the 420-450 Mhz./70cm amateur radio band at 25 Watts. It is capable of multiple protocols such as packet radio’s (AX.25) standard as well as D-STAR’s Digital Voice and Digital Data services at rates up to 56+Kbps. One constraint is that the data, when modulating the radio through the modem, cannot generate more the a 100 Khz wide signal — however, this is a 46.7x improvement in data rate over what is common on packet radio, and half the rate of the ID-1 (at 40%) of the cost, including a built-in computer.
Announcing the new radio at Hamvention® started a flurry of interest. We have individuals and groups who are ready to lay down cash to get the radio. We won’t take orders until we have a firm delivery schedule, but the interest is very strong.
We had a booth in one of the exhibit halls, and were inundated with folks coming by to learn more. Many of them came with projects they wanted to do, including other protocols for voice and data. The radio is an open development platform built on the Linux open source operating system. Interaction is typically by using a web-browser or custom application.
This occupied the majority of my Hamvention® 2012 weekend!
Since returning home, we have created a community forum on Yahoo! Groups – UniversalDigitalRadio
This weekend we’ll be at the SEA-PAC convention in Seaside, OR to show what we have been working on and answer questions.
[ This first appeared here ]
D-STAR, the protocol, has no notion of linking, reflectors, etc. It was designed to be “stateless”, meaning every transmission is complete in itself and has no inherent relationship to any other transmission. (For Internet Protocol folks, think of it as UDP or User Datagram Protocol). It is also an addressed protocol, meaning the field “MYCALL” is meant to be the address (callsign) that sent the transmission and the “URCALL” is meant to be the address (callsign) to which the transmission is intended. ”CQCQCQ” is meant as a “broadcast” address, meaning that it is intended for any receiver. RPT1 and RPT2 are helper addresses (callsigns) to select relay (repeater) stations.
In this basic D-STAR model a station would set the “MYCALL” to the originating address (callsign), such as MY: K7VE, and the URCALL address would be set to CQCQCQ, if the station was making a “broadcast” transmission, or it would be set to the destination address (callsign) for the receiver for which the transmission was intended, such as UR: KC7PAA. Icom took advantage of this model and added some features in their radios:
This all works well on a local simplex or repeater conversation. It is not, however, intuitive to the person who is making voice transmissions. If they have not applied the callsign squelch, they simply hear all transmissions on the channel. It sounds like any other simplex or repeater voice transmission, except between the radios it travels as a bit stream and you have the benefits (and liabilities) of a digital voice transmission. So to the voice user the utility is the same as their analog counterparts. On the other hand, the D-STAR digital data user (e.g. Ethernet encapsulated in D-STAR packets, not the extra data bits in the digital voice stream), the URCALL and MYCALL addresses (callsigns) become integral to directing traffic to the right receiver.
Moving up from the simplex or local repeater mode to networked communication, these addresses become more powerful. For voice communications, the URCALL again represents the intended receiver of the traffic. The gateway systems that sit behind the repeaters are designed to keep track of all of the addresses (callsigns) of all stations heard on the network. (In the case of Icom G2 and G4ULF gateways, an unregistered transmitter address (callsign) will cause their transmissions to be filtered out before it is relayed to the network.) So when a gateway receives a transmission from an attached repeater, it examines the the URCALL (and MYCALL) and looks to see if the URCALL address was last heard on a remote repeater and, if so, it relays the transmission to the gateway where that remote repeater is connected. To the operator, regardless of digital voice or digital data, it means that the transmitting station doesn’t need to know where the receiving station is located, the gateway system automatically and quietly forwards the transmission.
CQCQCQ is not a registered address, so it does not get relayed beyond the local gateway (and that is why you get an error message on your display when URCALL is CQCQCQ and the RPT2 address is active).
Because of this addressing over the network, the transmitting station can change the URCALL between transmissions and if the intended recipient of the second transmission is on a different remote repeater than the intended recipient of the first transmission, each will only hear transmissions directed to them. This has pluses and minuses:
This model does not work well, if at all, if you have a network of stations using digital voice and they are located at 3 or more repeaters (on 2 repeaters, each station just needs to have their URCALL set to either the address of the remote repeater, e.g. “/NW7DR B” or to the address of a station that is known to be located at the remote repeater).
Robin, AA4RC, looked at this issue, and came up with a solution, in the form of what we now know as DPLUS. DPLUS adopts the traditional notion of linking repeaters as can be found on analog repeaters. These analog repeaters use radio, wire, or voice over IP (VOIP) to relay voice from one repeater to the other and are usually symmetrical, i.e. if any repeater receives a signal it is relayed to all of the other repeaters that are on the link. For better efficiency when linking more than two repeaters, DPLUS adopted the notion found in the VOIP based linking systems, by creating conference bridges called reflectors which become the meeting place for small to very large collections of repeaters. This is a very powerful tool for enhancing wide area, even global, networks of stations, whether formal networks or simply “watering holes” where stations gather for random, non-directed, contacts. DPLUS is the application that is most responsible for the growth in use of digital voice radios in amateur radio over the last few years.
Since D-STAR has no facility, in the protocol, to perform this linking and because the Icom G2 gateway is closed source and proprietary, Robin was forced to create a method that would enable this linking. The Icom G2 system uses UDP port 40000 to relay digital voice between gateways on the Internet and all callsign addressed D-STAR digital voice uses this port on the Internet, and a different UDP port is used to talk to the Icom controller (and by extension, the repeaters), usually port 20000. DPLUS is able to use a technique called packet inspection (or packet sniffing) to watch all digital voice traffic between the controller and gateway, and between the gateway and Internet. DPLUS can then copy that traffic to another port to send it over a link to another gateway or reflector. Conversely, any traffic coming in over a link can be copied to the local controller, using packet insertion, to be sent over the air by the repeater. I will leave out a lot of the detail of the complexity required (some I don’t know, but have an appreciation that its no small feat) to avoid routing loops, separate streams for different repeaters connected to the same controller, handling DVDongles, DVAPs, etc., but fundamentally this what DPLUS linking does. Additionally, DPLUS monitors the packet headers for URCALL addresses that have been overloaded as commands for linking, unlinking, and other housekeeping.
One of Robin’s goals is to make sure every repeater, and by extension every station, on a link hears the digital voice traffic that appears on any other repeater on that same link, including traffic that comes into a gateway via callsign addressing (on port 40000) that would go out a local repeater to its intended recipient, if that repeater was on a link. The intent of that goal is to inform all stations of traffic that could collide if an additional transmission was put on the link. Also, it is intended to help avoid confusion for operators who may not be aware that some traffic is originating elsewhere. A reasonable thing to attempt, however, it does have some side effects:
We are all aware that most repeaters, by themselves, are largely silent. In any given metropolitan area, it is likely that > 90% of repeater traffic is on a handful of repeaters. To provide traffic on a repeater, in hopes of keeping it interesting, some repeaters are always linked to a particular reflector and deny stations the ability to ‘unlink’ or have aggressive watchdog scripts that re-link the repeater to the reflector on failure or if no other link is present. Other systems use reflectors for regional networks.
Most reflectors are likewise mostly quiet with just a few carrying the bulk of traffic. Today, a reflector with 20+ attached repeaters may only see the traffic we saw on a single analog repeater 20 years ago. So there is a lot of “dead air” out there!
A fraction of all D-STAR radio owners have learned to use addressing to direct their transmissions to their intended recipient. These transmissions can easily slip in to this “dead air” and would have no impact on any repeaters other than those directly involved. However, due to linking and reflectors, their transmissions are often sent to unintended destinations, including reflectors, which impacts many repeaters and their users. Some consider this “interference” on their links and have come up with scripts to try to mitigate these unintended incursions by unlinking a repeater when addressed traffic comes into a gateway from a local repeater. Unfortunately, they don’t really accomplish what one might suppose. Let me provide some cases:
Station 1 uses addressing to direct a transmission to Station 2. Station 1′s local repeater has a script that examines the header and unlinks it from a reflector. The transmission goes to the repeater where Station 2 is located and that repeater is linked to a different reflector. DPLUS will note the addressed traffic on Station 2′s repeater and dutifully copy it over its link to the reflector, which in turn copies it to all repeaters (and other devices) connected to that reflector. Possibly sending traffic to hundreds of unintended receivers (who may not notice it is addressed traffic and may attempt to reply, putting more traffic on the reflector intended for Station 1 who will never see or hear it.)
Station 1 addresses a direct transmission to Station 2. Station 1′s local repeater does not have such a script installed and is connected to REF001 C. So Station 1′s transmission is reflected to everyone listening to REF001 C. It arrives at Station 2′s repeater, which is linked to REF014 C, and goes out on Station 2′s repeater but is also copied to REF014 C, and in turn to every repeater linked to REF014 C. Since Station 1′s repeater is linked to REF001 C, stations on REF001 C can reply and be heard by Station 1, but not by Station 2 or anyone on REF014 C. Stations on REF014 C (not on the same repeater as Station 2) will not be heard by Station 1.
As some have suggested, if DPLUS only copied traffic addressed to CQCQCQ (broadcast), then it would greatly reduce the impact to reflector users in the above cases, as every addressed transmission would only be heard on the 2 repeaters where Station 1 and Station 2 are operating and neither repeater would have to unlink. There might be an occasional collision between addressed and DPLUS traffic, but it would almost always be limited to only one repeater instead of the impact to many repeaters as seen in the above scenarios.
DPLUS is Robin’s code and he is absolutely the one who makes the final call on how it works. This discussion is only intended to provide the information on what is happening in a gateway and how it interacts with linking. If you have suggestions on how DPLUS might address your concerns, you should share them with Robin.
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:
- 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.
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.
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.)
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.
I don’t like creating yet another forum for D-STAR, but since STARnet Digital is new there are a lot of questions, and so a forum was setup for those interested:
I love being Grandpa to these sweet little girls.