A powerpoint presentation on D-Star, presented at Utah Amateur Radio Club
The powerpoint is at DStarTalkK7VE
The sound samples are located at DStarSounds
You will need to unzip the soundfiles into a directory and then edit slide ten (10) associating the correct sound file with the speaker icons before giving presentation.
The sound files are courtesy of KC5ZRQ
Please credit K7VE when using the slides or any portion thereof.
A request for better components for D-Star Repeaters
I’ve been mulling over several of the questions that are showing up on the D-Star discussion groups for the last few days.
I think maybe we are barking up the wrong trees.
I would like to ask if there are some RF/EE designers out there who would be willing to volunteer to design some transmitters and receivers as an Open Source hardware project.
The transmitters would take a digital 4800 bps data stream, apply 0.5GMSK and present a 6.25kHz. wide FM signal on the design band (designs initially for 2M, 70cm, and 23cm – later for 10m, 6m, 1.25m, 33cm, …). The transmitters would have very little additional logic, only that necessary to set the frequency of operation and to provide transmit enable.
The receivers would have very sharp selectivity and excellent sensitivity to receive a 6.25kHz. wide FM signal, extract the 0.5GMSK and deliver a 4800 bps data stream. . The receivers would have very little additional logic, only that necessary to set the frequency of operation and to provide carrier detect.
Also create similar transmitters, band appropriate that could take 56 kbps and 128 kbps data streams using GMSK at appropriate bandwidth (130 kHz. For 128 kps data on 23cm, …) with matching receivers.
These transmitters and receivers would become the building blocks for a generation of digital repeaters that could pass the current Icom D-Star implementation as well as other digital formats that fit the GMSK and BPS of the design.
Once these building block transmitter and receivers are available, then there would be two primary controllers that would need to be designed:
A basic controller that is nothing more than a bit-regenerating “bent pipe” that takes the data stream from a receiver and places it on the transmitter, using the carrier detect circuit to fire the transmit enable. The only other “intelligence” in this controller would be to create a periodic D-Star format ID packet for the repeater and insert it at the appropriate interval. This controller would not even look at the address or payload of the packets passing through the repeater. Local D-Star conversations would not use the RPT1 and RPT2 fields, but rather only the UR and MY callsign fields. This would eliminate the “wrong RPT1” concern on the Icom repeaters, the repeater would repeat the captured signal.
A more advanced repeater would have a controller that would replicate the received data stream to a computer that would perform the functions of the current Icom controllers and the Internet Gateway. The advanced controller would look at the RPT1 and RPT2 fields to determine if RPT1 was the local repeater’s callsign and if RPT2 was instructing it to forward the packet to another repeater either off another line on the controller or through the gateway. This controller would also have the capacity to buffer received packets and prioritize them for transmission on the repeater’s output, i.e. if someone was transmitting on the repeater’s input and a packet addressed to a destination the repeater’s output was to come in either over the Internet connection or another repeater’s receiver that was connected to the same controller, it would buffer it and append it to the first transmission when the carrier detect dropped.
I am not an RF or EE designer so there may be big issues with my simple model, but let’s have a discussion and see if there is sufficient interest by some volunteers. I don’t have the skill or knowledge to build these transmitters and receivers, but once we move to the data layer, I can add a lot of value at the application and network level.
These repeaters would also be able to be more flexible such as using the entire 4800 bps on a narrow design for data or voice within a D-Star packet. Experimenters would also be able to play with other CODECs whether open source or proprietary, etc. (The only limitation being the availability of the CODEC on the sending and receiving stations.)
The boards could also be used by experimenters to design and build new user radios with a variety of features and user interfaces.
An interesting topic came up on the Yahoo! DSTAR_DIGITAL group. One of the challenges to digital over FM voice is multipath (one of the potential causes of R2D2). One method to combat it is found in the IC-2820H mobile with its diversity receive. Another possible combatant might be to put circular polarization at the repeater site.
Reference: http://www.qsl.net/n9zia/cir_pol_rpt.html
There is an article on circular polarization antennas in August 2007 QST. It might be interesting to do some research in this area. Bases could use horizontally polarized antennas to cut down interference from man made sources and be 20 db down from adjacent vertically polarized FM repeaters and mobiles. Using slot antenna designs horizontal might also be practical on 23-cm mobiles.
I wrote this to WY0X in response to a question about using audio based linking between a D-Star repeater and other repeater platforms. Originally in IllinoisDigitalHam on Yahoo! Groups.
These are applications that people will try but will mostly leave the user base unsatisfied, with a few possible exceptions.
Here is why:
Part of the real power of the D-Star protocol is the radio-to-radio over network addressing.
I set up my radio thusly:
UR CALL: WY0X
RPT1: WA7GIE B
RPT2: WA7GIE G
MY CALL: K7VE
I press PTT and everyone on the input and output frequencies of the WA7GIE 448.725 mHz. repeater can hear me. The repeater then sees the “G” (Gateway) designation as the next repeater which indicates that the destination radio “WY0X” is somewhere out on the network. The controller WA7GIE/B passes the packet to the WA7GIE/G gateway computer that then does a lookup to find what gateway/repeater last heard WY0X. In our use case we’ll say that WY0X was last heard on the KX0XXX/C 2-meter repeater in Denver, so the packet is routed to the KX0XXX/G gateway that then transmits it on the KX0XXX/C 2-meter frequency where the WY0X radio hears it and decodes the audio “Hello, Nate!” (Along with displaying any text or GPS information that might be associated on the K7VE radio. Typically the WY0X display would at least see the strings “K7VE /John” and “http://k7ve.ampr.org” or my email address). Any other D-Star users in the Denver area would also see and hear the same thing. At this point, WY0X using an IC91AD can press a button that sets up the return route:
UR CALL: K7VE
RPT1: KX0XXX C
RPT2: KX0XXX G (or is it WA7GIE B ? — someone correct this if I have it wrong)
MY CALL: WY0X
WY0X now can press PTT and say “Hello, John” and the packets will traverse from WY0X’s radio to the KX0XXX/C repeater through the KX0XXX/G gateway over the Internet to the WA7GIE/G gateway, on to the WA7GIE/B repeater and finally over the air to K7VE’s radio where it will be returned to voice (again with the accompanying text/GPS information such as “WY0X /Nate”). Also all of the D-Star Users in Salt Lake City will hear and see this conversation.
Simple enough for any D-Star user to collect from this information how to talk to either WY0X or K7VE.
This will be a typical D-Star gateway based QSO. You will note that everything is callsign routed.
Now let’s add an audio based gateway/link to an FM repeater in Denver — this link/gateway is a full time relay of everything that is repeated on the KX0XXX/C repeater. It is facilitated using a D-Star radio or something built up using Moe’s USB dongle and a soundcard to connect to the co-located FM repeater (Callsign KX0FMX). Now the Denver FM users are listening to the above exchange. K0RJC is listening and recognizing K7VE’s voice (K7VE’s ID is in the data stream so he doesn’t need to announce the callsign on voice) as that of his wife’s uncle and calls out on FM “K7VE this is K0RJC”, not knowing that K7VE is in Salt Lake City and not on the local repeater at all – the link radio or software is smart enough to set up the following for the D-Star system:
UR CALL: CQCQCQ
RPT1: KX0XXX C
RPT2:
MY CALL: KX0FMX
The FM signal would travel from K0RJC to the KX0FMX repeater, thru the link to the KX0XXX/C repeater where it would show up in Denver, but for lack of callsign routing information would never make the trip back to Salt Lake City and Richard (K0RJC) would wonder why his wife’s uncle was being so rude as to not respond. However, WY0X would hear K0RJC since the D-Star and FM repeaters are linked. K0RJC has no way to pass back through the D-Star system to contact K7VE. This would be a very confusing and poor user experience. This is why D-Star repeater operators, who have already been down this road, discourage these types of links. If you are an isolated D-Star repeater and want to tie in the local FM crowd this is not so much of an issue, but definitely not a good idea if you have a gateway.
The same scenario exists for P25 and MotoTrbo systems linked at the audio level to a D-Star system. Could be done, not a good idea.
Echolink has major issues when it comes to insuring that the operator is actually who he says he is and can enter the RF realm directly from the Internet, but it and IRLP share the same problems as listed above when connecting to a digital routed system. If we take the above scenario and add an IRLP node onto the KX0FMX repeater, now you have people on the IRLP that hear conversations that may or may not have audio callsigns (remember on D-Star the audio ID is unneeded as the ID is encoded in the data stream) and have no way to know why those operators are not hearing them.
Now with P25 and MotoTrbo, if you can get at the data stream at the repeater (my understanding is that it is often proprietary and closed), I can envision a smart gateway that would map unit IDs to callsigns that would allow a pseudo D-Star gateway to respond as though those P25 and MotoTrbo radios were D-Star radios and transcode the audio between the two formats. This would permit D-Star users to initiate calls to P25 users or MotoTrbo users by using callsign routing through the gateway system. However, the reverse would be impossible without mapping pseudo unit ID in the P25 or MotoTrbo space to callsigns in the D-Star space — possible but would require a lot of administration. (Work around methods are possible using the text messaging for control, but would be less than optimal.)
P25 and MotoTrbo may be excellent for what they were designed for — providing the infrastructure for a tightly controlled and geographically contained fleet. However, I think the ad hoc callsign addressing and routing gives D-Star a lot more flexibility and with the addition of an Open Source gateway and application platform puts a lot more system power into the hands of hams, especially when it comes to extending the system beyond the local repeater.
I guess I would like to see the model the P25 and MotoTrbo crowd has for a national and international network of gateways talking to a very mobile user radio base. (e.g. I’m operating in Atlanta and fly to Seattle and without any prior arrangements with the Seattle P25/MotoTrbo repeater operator be able to operate and have the whole network discover my radio and route calls for me at my new location, and do it all over again when I get to New Orleans)
One other little kink, even in the local D-Star to local FM/P25/MotoTrbo audio linking scenerio. D-Star has a notion of callsign squelch. (This has been intriguing to spouses who are licensed but only want to hear the radio when the call is specifically for them.) The FM/P25/MotoTrbo user has no way to signal that they want the squelch of KC7PAA (K7VE’s better half) to open.
Just some food for thought.
I’ve thought about this a little bit, certainly there are better minds than mine that will ultimately figure it out. But here are some of my thoughts:
[Update: 18 May 2009 - The Icom Repeaters will not handle the proposed "narrow" DD without a firmware change and I have no indication that Icom has plans for the same. However, other repeater controller projects are in the works and at least one experimenter has tried "narrow" DD (6.25kHz.) on the same channel as DV and found that eventhough the Icom radios do not know what to do with the DD traffic, it doesn't harm them either.]
You have a “DD” only radio, 6.25kHz. GMSK. Lower complexity, parts count, to build — would make a neat kit. If it was operating on a channel that had mixed DV/DD traffic, it would watch for packets that contained DV and would back-off to allow the higher priority (real time) DV traffic to take precedence. The DV users would hear nothing on the channel when DD traffic was being passed, as there would be no voice for the AMBE2020 chip to decode. When the channel was free the DV user could initiate a transmission, which would tell the DD radio to take a less aggressive approach to channel usage. When a certain amount of time had passed without any DV traffic on the channel then the DD radio could take a more aggressive approach to channel usage.
A dual-mode (DV/DD) radio would implement the same protocol for DD traffic, since the channel may have other DV traffic, not initiated by itself (e.g. no PTT event). DV radios would also listen for DD traffic on the channel and set a flag, so that if a user goes to transmit and gets inhibited by (DD) traffic on the channel, then it would automatically insert a DV packet at the first opportunity to let DD radios know that there was higher priority DV traffic ready for the channel. (The DV radio, would signal the user when it had sent that packet so that user would then know they could PTT.)
I am not aware of a specification on this.
I would venture in many EMCOMM situations the accuracy and routability of DD traffic (it has full TCP/IP capability) would give it more utility than DV traffic so a repeater asset that is normally used more for DV on a day-to-day basis would see a much higher percentage of DD traffic during a managed incident.
Some have commented that D-STAR cannot support EMCOMM data throughput requirments. I believe this is a just an artifact of viewing D-STAR narrowly through the Icom implementation.
There is more to the story:
I have been pondering the discussion about the D-STAR/P25/Packet data moving capability and throughput.
I was looking over the format of the DV (Digital Voice) and DD (Digital Data) under the D-STAR protocol. It appears to me that there is nothing in the protocol to prevent someone from implementing a DD system that uses the 6.25 kHz. channel and dedicate the entire data stream to data rather than DV. If Icom has designed their UHF/VHF repeaters or the associated controller so that it will not pass a 6.25 kHz./4800 baud DD data stream then it is merely a design flaw that could be fixed with a firmware upgrade. The issue then is to build a radio that formats DD packets using using GMSK on VHF/UHF — this would be a much simpler design than the current D-STAR radios that are being built with the AMBE2020 chips to handle the DV.
Furthermore, I believe (and I’m no expert on GMSK) that to get higher speeds and throughput would only require higher data rate GMSK modulation with its accompanying increased bandwidth up or down to any required data rate.
D-STAR does not equal Icom’s implementation and Icom’s implementation does not equal D-STAR. As was demonstrated at Dayton, a D-STAR radio can be built using readily available components and some associated software/firmware.
Let’s think about the protocol in terms of how it can be applied and work with those who have the skills to design the hardware / software / firmware to implement the types of networks we need. I can’t wait for the open source designs to start appearing on http://opendstar.org/…
I wrote this in response to comments on the Yahoo! group illinoisdigital hams about the need for open source and standards vs. the perceived proprietary nature of the D-STAR via the early implementation by Icom:
I know where you are coming from, I’m a big Open Source (in its broad definition – see Wikipedia article) advocate. I have been using Linux, GNU, MySQL, Apache, … practically from their beginnings. But have another perspective on some of your points.
Open Source is not free. There are implementation, support, and maintenance costs among other things. What it does allow though is open review and community participation in the development of products, which I believe makes them better products. The user/implementor of Open Source can choose from a market of ideas and make trade-offs between paying for the costs or absorbing them through their own labors.
We use all kinds of proprietary products in Amateur Radio, from vacuum tubes to microprocessors. Whether we homebrew or use commercially built products, we use building blocks of proprietary technology.
D-STAR was developed as an open protocol, not open source. I resisted it until recently because I don’t have the design skills to design and build the hardware platform inside a D-STAR radio (nor the math skills to create a great Vocoder from scratch). Icom was the only game in town and while they make great products, they haven’t caught the vision of opening and documenting their interfaces so that others can build on their building blocks. (Which would lead to more sales.) Then I learned that there were a few folks out there working on open designs for hardware, so I took the plunge and bought a D-STAR handheld (an IC91AD) and headed off to Dayton with it in hand (could have saved some money by waiting until I was there BTW) and one of the first things I saw was a working 2 meter D-STAR radio, homebrewed completely from components and user written software (WHOO-HOO, thanks “Mel”), a few months ahead of when I expected to see it. I also saw a board that can emulate the inter-repeater/controller control line protocols Icom has implemented as well as the Internet protocols that gateways use to talk to each other and the builder has written software that can be used to create open source replacements for the controller and gateway. So now, there is hardware and software to build our own repeaters and gateways (that don’t necessarily have to do it the Icom way of implementing the open on air protocol) and create our own applications that run in the network.
One could probably do the same thing with P25 (open specification) on the radio side, replacing the vendor proprietary stuff on the back side and, in software, create a gateway to route between them (at least in the local zone) — It remains to be seen if that could be done with Mototurbo technology (is their on air protocol patented?).
However, in each of the D-STAR (OpenDSTAR – see the coming opendstar.org site) and P25 examples they will still be built using some proprietary components such as the AMBE2020 and IMBE vocoders, A/D and D/A chips, microcontrollers, etc. as building blocks. That is how Amateur Radio has always been done. Our great opportunity is to build really “killer” applications for the technology that brings Amateur Radio back into relevance to the regulators. I don’t care if someone buys the technology or builds it, but open source is important to innovation in our hobby — right now D-STAR is ahead in that game thanks to some pioneers who are providing the tools and building blocks in an open and “free” approach.
Icom’s RS91 Software does not make it easy to load pre-existing frequency and settings into your IC-91AD. This article gives step-by-step instructions for using the D-STARCOM program by AE7Q to modify an Icom .icf file with comma seperated values (CSV) to load the information. This process works for additional radios such as the IC-2820H, check the D-STARCOM program for supported radios.
STARnet Digital at Yahoo!