British Columbia Frequency Modulation Communications Association
BCFMCA D-STAR System
The BCFMCA is proud to be able to offer ICOM's latest and greatest technology to amateur radio, D-STAR.
What is D-STAR?
D-STAR stands for Digital Smart Technologies for Amateur Radio. The purpose of D-STAR is to allow amateur (ham) radio operators to speak further and clearer using digital voice while sending data from 1200 BPS on up at the same time.
The D-STAR system covers communications on VHF and radio bands while defining interfaces for both radios, repeaters, internet interconnections, and PC interfaces.
D-STAR is the result of research by the Japan Amateur Radio League to investigate digital technologies for amateur radio.
D-STAR transfers both voice and data via digital encoding over the 2m (VHF) and 23cm (1.2 GHz) amateur radio bands. Voice is encoded as a 2400 bps data stream using AMBE encoding with 1200 bps FEC. The combined data stream is sent at 4800 bit/s (3600 bit/s voice + 1200 bit/s low-speed data) on the 2 m and at 128k bps on the 23cm band.
Radios providing data service use a RS-232 or USB connection for low speed data (1200 bps) and ethernet for high speed connections (128k) to allow easy interfacing with computer equipment.
The VHF radio supports a 1200 bit/s low-speed data channel, in addition to digital voice. The 1.2GHz radio offers 128 kbit/s high-speed data in digital data (DD) mode.
Most D-STAR user radios will operate in either analog voice or digital voice modes, making them compatible with existing repeater systems.
D-STAR repeaters only operate in digital voice (DV) mode, they will not repeat an analog signal.
For more in-depth information on D-STAR equipment, check out our D-STAR site.
The BCFMCA has a full D-STAR repeater stack (less UHF, which was converted to DMR) on the air.
This includes the following parts:
The repeaters are now (as of April 2018) connected to the internet via the ICOM G3 Gateway software. This allows users to connect to other D-STAR repeaters arround the world!
To register on our G2 Gateway, please follow the steps on the D-STAR Registration Page. If you are working with an ID-1, you will also want to see the ID-1 Supplement.
Please note, currently we are only approving applications on the gateway for users that are within the local coverage area of the repeaters. All other foreign call registrations will be deleted, unless prior arrangements have been made.
If you run into trouble, or need further assistance, please contact VE7FET (see contacts).
In addition to giving Lower Mainland hams a opportunity to explore D-STAR with a wide-area repeater system, we will be working with the BCWARN to develop applications based on D-STAR to integrate into Emergency Communications.
All of the repeaters in the stack are run off the DC battery plant for continuous operation.
Both 1.2GHz repeaters operate off the same antenna up on the very top of the tower. The repeaters run through a home-brew combiner network and a Sinclair 1.2GHz duplexer. The feedline is about 75 feet of Andrew LDF5-50A Heliax.
There are some conventions that are being suggested to make life a little easier for D-STAR users, primarily the assignments the RF repeaters are configured for on the RP2C controller.
In general, the "standard" setup follows:
The Band Identifier is of most importance when deciding where you want your transmission on a D-STAR system to be heard. It gets programmed as part of the repeater callsign, as seen below.
Figuring out what to program into the various slots in your D-STAR radio can be a daunting and confusing task to say the least. The manual is anything but clear, and often adds more to the confusion.
Jay Maynard, K5ZC, wrote a pretty clear explanation of how it all works, it was originally posted on the ICOM D-STAR forums, and has been reproduced here for reference (with some minor changes to make it applicable to our system).
Remember, the information that relates to gateway calls will only be applicable once we get our internet gateway installed and operational.
"First, a note on how routing entries are shown here. In nearly all cases, there will be one or more spaces in a routing entry. Since fonts differ, and the number of spaces matters, they'll be shown here as an underscore ( _ ). Be sure to replace the underscore with a space when you enter it into your radio.
Perhaps the hardest concept to understand is that the whole purpose of routing is not to get your signal to the ham you're talking to. It's to get the signal to the repeater the ham you're talking to is using. He'll hear your signal when the repeater puts it out. He'll also hear every other signal the repeater puts out, so you don't have to specifically send it to him. As long as it gets to the repeater he's using, he'll hear it. The same goes in the other direction: he only needs to get the signal to the repeater you're using.
MYCALL is the easiest to understand. It's just that, the callsign of your amateur station. It doesn't figure into routing decisions, except that it tells D-Star Internet gateways which repeater it can send stuff to you at. This happens every time you transmit through a repeater with an attached gateway, as long as you're registered as a gateway user anywhere on the system. When you change systems, a short transmission is all that's needed to tell every gateway in the entire network where you are.
RPT1 is the repeater you're talking to (the first "hop"). If you're talking on simplex, set it to NOTUSE*, so other stations won't wait for a repeater to retransmit it. If you're using a repeater, set it to the repeater's callsign, plus the band identifier in the 8th position. This means that, for example, if you're using a repeater with the callsign VE7RAG on 2 meters, you'd set it to VE7RAG_C, since C is the band identifier for 2 meter repeaters. If you're using the K5TIT system in Dallas on 1.2 GHz, you'd set RPT1 to K5TIT__A (using two spaces to get the A in the 8th position).
If you just set RPT1 to your local repeater, and RPT2 to NOTUSE*, your signal will go to your local repeater and be repeated, but it won't get sent any farther along than that. This is useful in itself, but it's not where the real magic of D-Star lies. After all, all we've done so far is reinvent the local repeater. This is where RPT2 comes in.
RPT2 is there to tell your local repeater where else to send the signal (the next "hop") besides its own transmitter (it always does that). If your local D-Star system has more than one band unit, you can cross-band repeat by setting RPT2 to the repeater's callsign and band ID of the other band you want to use.
So far, so good, but the real magic of D-Star is in gateways. A gateway isn't a repeater, itself. It has no RF hardware at all. What it does have is the intelligence to look up a callsign and automatically send your signal to wherever that callsign is on the network. You tell the gateway what to look up by setting URCALL. Up until now, the URCALL setting hasn't really mattered. The default is CQCQCQ, which is a general destination, not any specific ham. Unfortunately, the gateway has no idea what to do with CQCQCQ. You have to tell it what to look up.
There are two possible ways to get there. The first is the equivalent of CQCQCQ on a remote system. That's specified by putting a / in front of the repeater's callsign and band ID. The band ID, as always, is in position 8, so the CQ destination on VE7RAG's 2 meter port would be /VE7RAGC (note the lack of a space). A user on VE7RAG who wanted to talk to anyone at all on VA7ICM's 1.2 port would set RPT1 to VE7RAG_C (as always), RPT2 to VE7RAG_G (G is the gateway's band ID), and URCALL to /VA7ICMA. When the gateway sees / and a callsign and band ID in URCALL, it simply routes the signal there, with no further processing.
What if you want to talk to a particular ham, but don't know which system he's on? You'd set URCALL to the callsign of the ham you want to talk to, RPT1 to your local repeater (as always), and RPT2 to the gateway. The VE7RAG 2 meter user who wanted to talk to VA7SOL would set RPT1 to VE7RAG_C, RPT2 to VE7RAG_G, and URCALL to VA7SOL. This will route the signal to VE7RAG's gateway, which will see that the destination is VA7SOL, look up where he was seen last, and then route the signal there. If VA7SOL is listening to that repeater, he'll hear your signal, and can respond to your call by reversing the process. (Some radios, such as the IC-91AD, can do this automatically.)
Since all signals are retransmitted by the repeater that receives them, either from its RF input or another repeater (locally or through a gateway), others can join in on the conversation. To do so, they'd use the same routing settings as one of the other local stations they're talking with, which will cause their signals to be routed the same way. The exception is URCALL, since it's only used by the gateway to look up the destination repeater, it can be anyone on the other repeater system, or that system's general destination (/callsign), if it's known.
D-Star routing isn't as complex as it's made out to be, or as it appears from the documentation. Once you understand what each piece of the puzzle does, setting it up to do what you want is straight forward."
A summary of different types of calls:
A user on VE7RAG's 2 meter port would set:
There is a limitation (pitfall) of networked D-STAR repeaters that you should be aware of. At this time, there are no means to connect two systems together and listen to all the traffic (like linking systems in IRLP). So, if you are making a gateway call to a remote system, you have no way of knowing whether there is a QSO in progress on that remote system when you make your call.
There are some neat tools that may playing with D-STAR easier, follow these links to check them out:
To see the current activity and what is linked to/from VE7RAG, check out the DPLUS Dashboard. Note that this is running on the D-STAR Server, so you may get a security warning.
Use the Lastheard report to see where the activity is on the D-STAR network.
Want a hand configuring your radio to talk to someone? Try out the D-STAR Web Calculator.