VOIP / DV applications and Ham Radio
a loose (messy) collection of notes
D-Star | APCO-25 | DMR | |Asterisk
As of writing, TV broadcasters in the other areas of spectrum are required to be full digital and shut down their analog transmitters in Feb. 2009. The only spectrum broadcasters are required to vacate are channels 64 thru 69 that will become the new "700 MHZ band" that is being auctioned off by the FCC. The vacated areas of this spectrum will be utilized for: Public Wireless deployment (Cellular/PCS); A wide-band private data network that will be shared between public safety and paying customers; and new spectrum for public safety that will butt right up to the re-located NPSPAC National Public Safety Planning Advisory Committee band being moved to 806-809/851-853 by Sprint/NEXTEL. All non-public safety stations to operate on channels with a bandwidth of 12.5 kHz or less beginning January 13, 2013. Until 2013 (maybe), public safety users may continue to use 25-16 (wide band) kHz equipment. Phase 2, which becomes mandatory (maybe) in 2018 would require radios capable of operating at 6.25 kHz. (Digital Non-analog FM). The future of two way radio is digital, and we must also advance in this direction. The digital premise is that it generally allows more use in a more efficient/flexible use of band space.
A process of "refarming" the informal name of a notice and comment rule-making proceeding (PR Docket No. 92-235) opened in 1992 to develop an overall strategy for using the spectrum in the private land mobile radio (PLMR) allocations more efficiently to meet future communications requirements. The FCC created mandates for the two-way radio equipment manufacturers. In 1997, all new two-way radio models had to be capable of operation on the "new 12.5 kHz narrowband" channels. This is often called "dual-mode" equipment since the radio can accommodate both narrow- and wide-band channels. The idea was to begin to move gently toward narrowband channel operation over time. At that time, the FCC did not create any mandates to remove older wideband radio units from service or require you to use a new narrowband channel.
The Part 90 LMR narrowbanding mandate was released 12-23-2004 by the FCC for all Part 90 business, educational, industrial, public safety, and local and state government two way radio system licensees currently operating legacy "wideband" (25 KHz) voice or data/SCADA radio systems in the 150-174 MHz (VHF) and 421-512 MHz (UHF) bands. The executive summary of the FCC order establishes January 1, 2013 deadline for migration to 12.5 KHz technology.
Hams benefit because a lot of used equipment will start showing up. Oddly enough while most ham repeater coordination bodies, coordinate / assume traditional 16 kHz wide-fm bandwidth, D-Star boasts it's spectrum efficiency with a 6kHz bandwidth for ham radio.
While that is nice, it's not necessary at all. Hams are not bound by these narrowband rules, refarming nor will there ever likely even ever be a rebanding. We have oodles of spectrum available to us, most of it un-used.
What is actually disappointing about D-Star is that it's only a 4800 baud total data stream equivalent signal. 2400 bps is reserved for actual digital voice, 1200 bps is reserved for FEC (forward error correction) on the digital voice. (This is for callsign and short message data.) 1200 baud is reserved for serial data low speed digital data . (This is for APRS, and text messages/text query's.) The sad part is 1200 baud data is what we were doing in the 1980's.
So if 4800 baud can fit into a 6kHz bandwidth, we could have had a 12800 (12.8k) baud total data stream equivalent signal fit into our existing 16 kHz bandwidth plans. This could have left us with 9.2k left for data. Or at the very least more could have been given for the digital voice codec, so that we could use other license free-codecs that sound more natural.
Toward Software Defined Radios and Digital Voice
Obviously you gravitate towards things. You don't just expect to, like a light switch, convert everyone to purely digital radio.
It would be logical at this day in age if you're planning on upgrading a repeater system to ensure that it can repeat analog and some form of digital. P-25 systems and Motorobo systems can do just this. Just as if you are considering a new HT or mobile to purchase something that is digital capable like the IC-91AD or the alike.
Technology is ever changing, which makes standards hard to set. This is why open standards are so very important. It expedites production and advancements , as you are effectively working together or sharing information. Be wary of any thing proprietary, as this impedes technology and is terribly unhealthy for the hobby.
Protocols and standards need to be dynamic as possible to avoid equipment obsolesce. This is where the software defined radio (SDR) concept is key. However once again between here and there, manufactures should highly consider flash/field upgradeable firmware.
Just about everything has this, from phones to PDA's to routers. An upgrade can fix a bug or give you added functionality. The most classic example I can think of is the Linksys WRT-54G. They grasped the open source concept and made a product that so many people have written after-market firmware for that has unlocked a wealth of added functionality.
Why don't we have more of this? We are hobbyist and tinkerers that are supposed to be advancing the radio art. Societies electronics evolvement has made traditional homebrewing difficult. Components are smaller and harder to work with, things are designed more throw away. However homebrewing should and will continue. It will evolve to a more modular and software level than component level. As things progress increasingly more digital, the emphasis need to be on firmware upgradeable, open source, and user end flexibility.
Yeasu and others seem to rush radios to the stores probably to beat the competitors, but they often suffer some firmware bugs. The only way to have these resolved is to send the radio in. Unless others follow in the footsteps like Kenwood apparently did. http://www.kenwood.com/i/products/info/amateur/software_download.html
In summary an emphasis should be on dynamic protocols, and products that provide a capability bridge as well as upgradeable platforms. Products that lack in these key areas are potential road blocks to the future. I'm certainly not buying expensive radios every year, so a little foresight is all we need.
Having systems that are open to 3rd party developers, have an active developer and user community, and use open protocols have the best chance of succeeding. Hams like to tinker and also to have someone else to talk to when they need to test their tinkering.
Be wary of any product that isn't built with dynamic architecture. Built-in obsolescence or proprietary features are excuses to force acquisition of new products.
Here are a few potential software ideas that could potentially augment the hobby.
VOIP applications and ham radio
Most present day government communication centers that use analog systems happen to have a VOIP based dispatch console. Many remote sites are tied together using over fiber. This analog to VOIP patching is something that we are presently also embracing in ham radio with IRLP, EchoLink, Yeasu WIRES II, and the like. (See VoIP and Amateur Radio overview By Steve Ford, WB8IMY from QST Feb 2003)
A different hardware board for each of these proprietary VOIP systems that you want to support is required. You also need a need a multi-port repeater controller, to support each hardware boards analog breakout. This seems redundant to me, and is something that slows the advancement. IRLP seems to be the system of choice because it runs on the Linux operating system. This is because Linux is much more stable that Windows, and is an open source development.
Imagine how smoothly and fast things would have unfolded if everything was open source, and no one had to waste time reverse engineering other peoples secrets.
The ARRL made a Interoperability statement in October 2007. This is a pretty serious issue as there a number of proprietary digital voice radio systems out there. None of them natively talk to each other.
There are some keys to consider when it comes to interoperability. The lowest common denominator (aside from frequency) would seem to be the modulation type. D-Star is GMSK, APCO-25 and pretty much everything else is 4FSK modulation. Upon that you have a MAC layer level access protocol, then the actual codec converting the voice to digital. Electronics is so PIC/chip based, modulation changes can be changed without necessarily changing components.
As long as there is a hardware common ground modulation type or ability to speak/receive multiple types (like they did with 802.11b & g - DSSS/OFDM), firmware should be able to be written to take care of any MAC layer differences. Transcoding can take care of the differences between the various codecs. This is where a platform like Asterisk shines.
In 2010, Mikael Styrefors, SM2O unveiled perhaps the most elegant ways to operate remotely. It involves no computer, just two Remote Rig Control (1258MkII) units. The front panel resides with the client while the rest of the rig remains at the host. Both devices connect to Internet routers via Ethernet cables.
RRC boxes are built around reliable ARM microprocessor, and are an intuitive way of utilizing existing VolP technology. Control and remote RRC units utilize three communication channels; a simple text-based SIP protocol is utilized for radio-to-radio communication, while a UDP datagram protocol is used for control and audio streams. The RRC unit also provides two additional serial ports for connecting devices such as an amplifier and a rotator control.
Advances in Remote Site Control without Computers - OH2BH
IRLP & Other VOIP Overview:
While IRLP holds promise, a large part of the hold up on outside and additional developments for IRLP seems to be related to the fact that parts of the IRLP system (the binaries that talk to his hardware board) are not open source. This to me doesn't seem to be in the true spirit of amateur radio. I also read rumors (July 06) that the IRLP system designer (David Cameron, VE3LTD) had developed a similar system to IRLP that is being used commercially, and this to may be part of his proprietary design reasoning. Another reason the board design is unpublished is that the board is the IRLP designers only source of funding to keep things alive. Also to cut down on the number of questions/problems from the non-technical savvy. While neither of these are bad, it still doesn't let technical savvy people do much more than talk over the network. I & others could be developing and contributing ideas though experimentation.
IRLP started in 1997 with Windows and VocalTec's iPhone and a WB2REM interface. David, VE3LTD realized in 6 months time that iPhone was not very stable nor is it controllable. He also ran into a road black when source code for iPhone was not available. David looked for an alternative, and he started getting into using Linux as an operating system and Speak Freely as a client/server. SpeakFreely was open source and he was able modify the source code to his liking to create what we now have today for IRLP. He then designed his own hardware board for PTT & COR logic.
EchoLink natively runs on the Windows operating system and was developed by Johnathan, K1RFD, released in 2002.. He approached this whole concept initially with a view to improving a system then running called "iLINK" (The iLINK system, first appeared around May 2001, was developed by Graeme Barnes, M0CSH, in Kent England), which was an enhanced development from a voip system called IPhone, as was IRLP. But read on.
Initially "Echolink" was un-named, but Johnathan K1RFD, and David, G3VFP started development to provide an alternative graphical user front end to what was then the "iLINK" voip ham system, sometime in late 2001, or early 2002. Unfortunately through no fault of Jonathans, as he tried hard over quite a few months to communicate, with the owner of iLINK. It proved a near impossibility, and reputedly it was stated by the author of iLINK that no third party software would be allowed on iLINK. So Jonathan decided to form another peer to peer voip system completely, using his graphical interface. Which by the way was years ahead of the iLINK GUI.
Open source versions of the EchoLink software are available for Macintosh (EchoMac) and Linux (echoLinux aka CQiNet or SvxLink/Qtel), but they may have limited features compared to the Windows version. At least when comparing the desktop applications.
CQiNet provides "theBridge", which is code that allows one to talk to EchoLink network from Linux or a Mac platform. The primary purpose is to use the Internet to link Ham repeaters with a secondary purpose of providing remote access for users. CQiNet is a family of programs that combine Ham Radio with the Internet using Voice over IP (VoIP) technology. Two programs are currently in the family, "theBridge" and echoLinux. Thebridge is a iLink/EchoLink compatable conference bridge that runs under various versions of Unix as well as Windows EchoLinux is a EchoLink client program for the Linux operating system. Compatibility with EchoLink and IRLP is a goal. TheLinkBox - is program suite (based off CQiNET and "theBridge) to support serial & parallel-port interfaces as well as USB dongles. A full featured multiport hub or repeater controller as well as a VoIP application.
Johnathan, K1RFD tolerates thebridge and EchoIRLP partly because he does not sell EchoLink or any boards that are needed to make it work. Since Dave, VE3LTD derives income from IRLP it should not be surprising that he's less tolerant.
While IRLP is not 100% open, some clever people working with David Cameron, the IRLP system designer have managed to adapt theBridge so that one can have the inter-operability of EchoLink and IRLP using the IRLP hardware. This is called EchoIRLP. Both networks are capable of GSM audio compression (standard for EchoLink and is an option for IRLP as it normally uses ADPCM), and the transport protocols are quite similar.
In this case, those who worked with David, worked out the details where the IRLP binaries are talking to The Bridge which is in turn talks to the Echolink network.
The iLink protocols (the basis of EchoIRLP) were reverse engineered by Tom, WD4NMQ and Skip, WB6YMH without the author of iLINK Graeme, M0CSH (G7BHM) blessing. Without reverse engineering there would be no EchoIRLP.
Taking this one step forward, Svxlink is another step in the right direction. The Svxlink project allows configuration a variety of existing economical radio to PC interfaces, such as the VA3TO interface. What's notable about Svxlink is they have a schematic also released under the GPL so one can homebrew their own radio to PC interface.
Repeater activity graph - Use IRLP hardware to create an automatic daily graph of system activity.
IRLP Node Administration via Web - Simple web admin php script for your IRLP node.
IRLP-Repeater script - More info on useing IRLP as a repeater. Includes configurable repeater hang time, courtesy tones, timeout timer. SCCW for morse IDs, DTMF muting provisions, and anything else you can script.
IRLP board interface schematic Kyle, K0KN's reverse engineered schematic
When questioned in November 2006, about Asterisk and Allstarlink, David Cameron, (VE7LTD) IRLP system designer said they are currently not working or supported pieces of IRLP, although they may be in the future. Dave reported 12/06 & 11/07 that he is working on USB based solution, or a non parallel port IRLP interface card as these are being faded out in modern computers, even more so in embedded systems.
A bit of history about IRLP:
David Cameron, VE7LTD, is the guy that originated IRLP and "pieced together" the code himself. Not being a professional programmer he said he was aware that the code was not going to be the most elegant in the world. When he put it up the GPL license his email was besieged daily by folks flaming him about why he did something this way or that without providing any alternative. Finally in disgust he removed it from the GPL license and continued doing it his "own" way. Thats why the IRLP looks "quite horrible" as it does.
N3GLV is trying to get some of the AMPR.ORG activity back up for ham-voip, contact him (n3glv1963 [at] gmail.com if interested and/or e-mail WB6CYT brian [at] ucsd.edu)
Digital RLC from Link Communications - Digital Linux repeater controller in same box as IRLP. The RLC-DSP404 unveiled at Dayton 2007
Weather Alert Interfacing and Scripts - Hardware and Software approaches to warn of bad weather and provide reports.
Asterisk is an Open Source PBX & Telephony Platform. It's often labeled as the future of telephony.
PBX stands for private branch exchange. It is a machine that handles many businesses telephones calls for you. Its main functions are to transfer calls to different individual phones; play music when somebody is put on hold; to play automated voice responses when a call is received; to provide an options menu for the caller etc.
Asterisk allows one to build their own phone systems. It adds features, functionality and reduces deployment costs in ways which; at first are a little difficult to understand.
Most people don't know that Asterisk was designed from the beginning with
radio applications in mind.
Jim Dixon (WB6NIL) developed pioneering hardware and software and collaborated with Mark Spencer of Digium to make Asterisk a reality. Jim says that compatibility with Amateur Radio applications was always a design requirement for his Asterisk work.
Steve Rodgers (WA6ZFT) is a longtime friend of Jim's and they co-developed the app_rpt module and the Quad Radio PCI card to interface radio equipment to Asterisk. Steve's company QRVC Communications originally offered the Quad Radio PCI cards for sale. They have much been replaced by USB devices.
Steve Henke (W9SH) wanted to use hardware that would provide baseband (receiver discriminator and transmitter modulation) signal processing. This allows noise squelch detect, RSSI, CTCSS and other signaling protocols to be done in software and provide additional features. The answer to this need was found in a low cost USB Sound Adapter. Steve and Jim collaborated on the chan_usbradio driver and Steve's company Xelatec contributed the xpmr radio signal processing routines under the GPL to the project.
In my case, ham radio first introduced me to VOIP, with Echolink and IRLP in the late 90's. Since that time, I've been playing with Asterisk. Asterisk is some very powerful stuff, perfect anyone who is familiar with Linux and likes to tinker.
I have a 2.4 GHz ZyXel WiFi phone. It already operating on overlapping ham frequencies. Fits in well with my interest in using Part 15 802.11 wireless devices under Part 97. On my Asterisk sever I have extensions on can dial to hear Amateur Radio Newsline, ARRL audio news, etc. I also have extensions for weather reports. I've created backdoors into repeaters utilizing analog telephone adaptors and the reverse autopatch control-op listen/break-in mode. I've experimented with a IAX link over 900 MHz using proprietary wireless hardware.
Polycom and Cisco have WiFi phones that also has a Nextel like two-way walkie talkie/PTT functionality. Very cool. I'd also like to tie my Asterisk network in a more direct way to a repeater. I also have my fingers crossed that one of these WiFi phones will have open firmware or possible be based on the Atheros chipset to allow greater frequency freedom.
Developments for an application layer to allow an existing IRLP systems to have added functionality to speak (SIP/IAX2) to an Asterisk system could be a very beneficial contribution to ham radio.
Asterisk with app_rpt can be connected to almost any radio transceiver and network if you have the skills and patience to make the necessary interface and configurations.
Asterisk with app_rpt
provides the following for Amateur Radio stations and systems: A Full Function
Repeater Controller, Touch Tone Command and Control, Autopatch - Reverse and VOX
Operation, CTCSS Decode/Encode Functions, A SIP Telephone Exchange, Voice Mail
and Announcements, Contact Closure Telemetry, Non-Proprietary Software and
PC/Linux Operating System Based, Remote Base Client, Fully Configurable and Programmable Communications Solution
Several different radio makes and models are well supported by vendors who provide ready made interfaces and cables. For frequency agile remote applications, app_rpt can control a multi-band, frequency programmable radio transceiver such as the Icom IC-706.
Radio Transceiver To Asterisk Interfaces
We will now describe two well supported hardware solutions for interfacing PTT radios to Asterisk.
USB RADIO ADAPTER (URA) - The third and most recently developed radio interface is the USB Radio Adapter. The principle advantage of this device is that it has a low cost. For example you can build your own radio cable by attaching it to a $7.00 off-the-shelf commercial USB Sound Adapter. With the USB Radio Adapter, CTCSS and other signaling encoding and decoding is done in the software. And, signal level setting is done in software so there are no physical adjustments to make that require access to the computer and taking the covers off to reach the potentiometers. Additionally, the URA can determine the received signal level in software and use it for squelch and other features.
Repeater Builder Radio USB Interface Module (RB-USB-RIM) - This is an enhanced universal radio interface (URI). Jumper settable COR / CTCSS input logic w/LED indicators.
This USB solution is to facilitate Asterisk applications using app_rpt, AllStar Link and the "chan_usbradio" channel driver. AllStarLink released a USB controller in Feb 2008 thru DMK Engineering This is proposed as a Universal Radio Interface, based in the CM108 chipset. Dec 2006 - Dave, VE7LTD had reportedly started working on a USB solution for IRLP as parallel ports are starting to disappear from computers.
With all of these interfaces, the best and preferred radio connection is directly to a radio's unsquelched and unfiltered receiver audio signal and its flat transmitter audio modulation point. Of course a transmitter activate or PTT connection is required. Connection to a carrier or signaling tone detection point is required for use with the ARIB and QUAD RADIO interfaces and optional for the URA interface.
A nice Linux platform with a nice audio platform like Asterisk
and the USB dongle for the hardware interfacing.... those are all a great start
towards a whole software based repeater controller. And if it had a
modular GUI front end like FreePBX, if think this would really be something.
A nice web-based GUI front end setup for CW ID's, voice messages using text
to speech, a scheduler etc. (See the IRLP Visual Admin Console and Micro Node, these are GUI projects)
Many hams have, and already support the IRLP hardware, and that also runs on Linux. Wouldn't it be nice if there was an application that would provide the inter-operability in much the same manor we have added support for Echolink? (As I've mentioned, the idea of having to have different hardware board for each VOIP system you want to support seems redundant.)
A different hardware board for each of these proprietary VOIP systems that you want to support is required. You also need a need a multi-port repeater controller, to support each hardware boards analog breakout.
The reason is all these systems take an analog audio mixing approach. And this feeds the need for a multi-port repeater controller, to support each hardware boards analog breakout.
Asterisk is the best foundation for digital mixing. Their MeetMe conferencing application is a good example. It uses a hardware timing base/source. When it comes to mixing digital audio streams its often necessary to have a this to ensure that all packets are "in phase" or "sync" with the remote end. Without this digital distortion can be very noticeable, jittery, choppy sound.
IRLP lacks this digital mixing foundation and this is why you can only make/take one connection at a time. You connect to a reflector to be in conference. With EchoLink you can conference independently, but as noted above it usually sounds choppy.
If you want to drive the IRLP board with any other software, its circuitry is fairly simple, because it just talks to the parallel port. Someone would need to code a driver to spy on the parallel port and sound card inputs and outputs so that IRLP or Echolink can be run without modification.
From what I understand the logic signals PTT/COR toggle the "call on hold" field and that's how the standard signaling is sent over a standard SIP/IAX stream.
Configuring two SIP extensions isn't the worst. The part I don't like with the original is the hardware approach. That's why I think it would great of there was a GPL command line SIP client such as "linphonec" that could be torn apart and made to talk to the IRLP hardware board, since most of use are already using that hardware.
Getting something to talk to the IRLP board is step number one, from there it seems to me it should talk in SIP (preferred) or IAX. In my mind, once you have this just about anything is possible, and allows an world of tinkering;
It could allow one to possibly build their own reflector or cross connect IRLP/Allstarlink/Echolink using meetme.
Some repeater systems use phone lines to connect remote receive sites, one might be able configure this as drop in replacement to save telco charges where there happens to be a network connection.
The possibility to support (autopatch) connections to the outside telephone network, such as for 911, instead of having to have a dedicated line at a site.
Some remote repeaters still use their autopatch to call and play newsline. A simple ATA could save some telephone charges.
Just a thought. I'm not sure what would all be involved, but I would like to get a clearer picture of that. However lets focus with something that can talk to the IRLP hardware and speak SIP. Being able to incorporate IRLP audio onto Asterisk systems could be useful. I suspect we'd need a shim application (app_speakfree? ;) ).
When you take a digital radio platform like D-Star, this is where integrating Asterisk could be very powerful. Since the call sign is part of every packet, this could be assigned to a direct inward dialing number (DID) or extension.
asterisk-and-app_rpt.pdf - VoIP Linking for Radio Amateur Chapter 9 excerpt for reference
The Asterisk PBX as a Linked Repeater Controller - By Steve Rodgers, WA6ZFT 10/21/05
Steaming Newsline over an Asterisk extension - new use for your autopatch using a simple analog telephone adaptor
Simple FXS to simplex radio interface - from F6HQZ
Cheap Asterisk radio interface - consists of a modified USB sound device. A channel driver exists in Asterisk that enables certain Cmedia CM108 based USB sound devices to provide the hardware interface between both commercial and amateur private land mobile radio equipment. A pre-fab version is available from DMK Engineering.
Asterisk with app_rpt provides the following for Amateur Radio stations and
systems: A Full Function Repeater Controller, Touch Tone Command and Control,
Autopatch - Reverse and VOX Operation, CTCSS Decode/Encode Functions, A SIP
Telephone Exchange, Voice Mail and Announcements, Contact Closure Telemetry,
Non-Proprietary Software and Hardware,
PC/Linux Operating System Based, Remote Base Client, Fully Configurable and Programmable Communications Solution
Southeastern Asterisk Radio Network http://searn.alertradio.net
Asterisk Radio Networks / Asterisk Amateur Radio Network by Mars Reed, N0PCO http://www.alertradio.net http://asteriskradio.net/
Asterisk Wireless Interoperability Demo http://www.xelatec.com/asterisk/ http://www.xelatec.com/w9sh/asterisk/
The Xelatec XIPAR project
combines the Asterisk VoIP PBX with radio interface software and hardware that
provides the following for Amateur Radio stations and systems:
A Full Function Multi-Site Linking Repeater Controller, Touch Tone Command and Control, Autopatch - Reverse and VOX Operation, CTCSS Decode/Encode Functions, Asterisk VoIP Private Branch Telephone Exchange, Voice Mail and Announcements, Contact Closure Telemetry and Announcements, Non-Proprietary Software and Hardware, Open Source Linux Operating System, Remote Base PTT Dispatch Client Software for PC's, A Fully Configurable and Programmable Communications Solution
Allstar Link Network http://allstarlink.org
Asterisk now supports Bluetooth channels. chan_mobile allows one to use Bluetooth cell / mobile phones as FXO devices. Yaesu came out with a Bluetooth ready 2m/440 FT-10R Mobile. And the Yaesu VX-8 has optional bluetooth. Can the two be written to talk to each other? One would think so.
Alert Interface - This device connects a receiver, such as an "All Hazards" warning receiver, to an Asterisk PBX. The intended purpose is to allow the warning messages to be broadcast over the Asterisk paging system.
Raytheon ARA-1 Analog Radio Adaptor A radio to SIP interface. See this review by Doug Hall titled SIP & Mobility - Bringing Radio to the 21st Century
RtpDir bridge software (Real Time Protocol Director) by Scott, KI4LKF. Basic features: Runs as Echolink/Echolink conference, IRLP reflector/Echolink conference, Echolink+IRLP or a private net. Graphical environment. DTMF control from Windows or Linux. Remote text command control using ssh/Linux or PuTTY/Windows. Can TX/RX IRLP messages without the IRLP board. Any station can connect to rtpDir bridge. It does not have to be IRLP or Echolink. GSM, ADPCM, LINEAR codecs are supported. Protocol conversion between IRLP, Echolink and SOON TO ARRIVE *Asterisk* PBX. ADPCM ---> GSM, GSM ---> ADPCM transcoder included. DTMF processing internal(built-in) or External(hardware). Morse code IDs or Voice. COS "sensing" or VOX or both. Support for all link interfaces(sound mode or ASCII mode, VA3TO, WB2REM, G3VFP, G4CDY,...Rigblasters, MFJ, SignalLink,...) Mark a station as "Mute", "Deaf" or "Mute and Deaf". Timeouts for login, download, connection. Activity reporting. Audio recording and playback. RF station identification(audio, CW). Welcome message(audio, CW or text). Convert text to CW. Runs as server or client. Interfaces with external scripts. Runs with or without a soundcard. Audio signal strength indicator.
In this video, VK5ZEA shows D-Star, IRLP and AllStar/Asterisk linking: http://www.youtube.com/watch?v=oWkFp7S2pXY
D-Star uses the AMBE vocoder from Digital Voice Systems Inc (DVSI). It's $150K if you want the software source but they do offer a single chip solution for $20 single qty and are happy to sell to hams. (The AMBE IC 2020 as of January 2008 is $20. The AMBE 2000, used in the DVDongle, is $33. DVSI's usual policy is to sell in minimum lots of 5 or so chips, they decided to sell the AMBE 2020 in quantities of just one to hams.)
One of the major down falls in my mind with the D-Star is that the D-Star repeaters such as the ICOM ID-RP4000V for VHF is that it's Not reverse compatible with existing analog FM. It only supports D-Star digital voice. Where as a P-25 repeater system can be configured to repeat analog FM and P-25 digital voice. This provides a transition opportunity for users and repeaters owners without the need to setup a whole different digital site, which may not even be an option for some clubs.
Audio samples: D-Star Icom (ID-1) Analog FM vs D-Star DV - Un-decoded
Spectral efficiency. The DV format of D-STAR has a bandwidth of 6 kHz, compared to 16 kHz for analog FM with 5-kHz deviation. This is Via Carson's Rule, BW = 2 x (Peak Deviation + Highest Modulating Frequency) = 2 (5 kHz +3 kHz) = 16 kHz.
Modulation methods: GMSK, QPSK, 4FSK
Data rate: Maximum of 4.8 Kbps
Voice encoding method: AMBE (2020) converting at 2.4 Kbps, FEC at 3.6 Kbps
Occupied bandwidth: Maximum of 6 KHz
D-star is a 4800 baud total data stream equivalent signal. Where: 2400 bps is reserved for actual digital voice, 1200 bps is reserved for FEC (forward error correction) on the digital voice. This is for callsign and short message data. And 1200 baud is reserved for serial data. This is for APRS, and text messages/text query's
There are a few open source D-Star software and hardware projects that showed up in 2007. A completely home brew hardware and software 2-meter D-Star radio was demonstrated at Dayton 2007 by Moe, AE4JY. as well as the makings of a controller (full decoding of hardware handshake with the Icom repeaters and line protocols for the repeater - controller - gateway connections).
The DV dongle is an important development that started in 2007. It was started by AE4JY and AA4RC. It contains the ability to process AMBE full duplex. Presently software applications exist to use this to communicate from a computer to a D-Star gateway. Further development are expected so that it can be interfaced to a radio's packet radio port that has the necessary discriminator connections. This may be a huge milestone. The ability to retrofit an existing repeater could be possible with this. Not only that, but you may be able to retrofit it in such a way that it can be useable in analog and for D-Star. Something to keep an eye on! You can read more notes about both of these here.
These are all good, because the show an interest in D-Star to other vendors and manufactures. As of writing Icom is the only manufacture selling D-Star capable radios in the US. There are rumors that in Japan, Kenwood has a rebadged Icom on the market. A bit of competition could help bring the price down and further the innovation of further advancements and features.
There are a few references to Phase II D-Star out there. Folks are working on that now. Many of those people don't see a Phase 2 D-Star that will force obsolescence of the initial DSTAR products and cause production and support of the initial phase to go away.
This Phase II terminology can get confusing. Interesting enough D-Star uses DVSI's AMBE codec. AMBE is slated to replace the IMBE codec in Phase 2 of APCO 25. That is not a coincidence or accident on the part of the JARL or Icom. Many are sure they looked at open source. We appear to be Icom's lab rat for their rollout of commercial P-25 Phase-2 products. Actually I think AMBE+2 is backwards compatible capable with IMBE.
CHAPTER5.pdf D-Star Communication Between Zone Repeaters and Gateway
DSTARUncovered.pdf D-Star Uncovered by Peter Loveall AE5PL
gmsk_tut.pdf Practical GMSK Data Transmission Tutorial Application Notes
shogen.pdf English D-Star Technical Specification
STD4_3C.pdf Japanese D-Star Specification
VocoderRedux.pdf About the AMBE2020
dvdongletechref100.pdf DV-Dongle Technical Reference www.moetronix.com
m000021-2sch.pdf DV-Dongle Circuit Diagram
Slow Data.pdf The Format of D-Star Slow Data Version 0.2 by Jonathan Naylor, G4KLX
Nifty E-Z Guide to D-STAR Operation - A good reference
http://groups.yahoo.com/groups/dstarsoftware- This group is for Jakub Hruska's (from the Czech Republic) D-Star GMSK decoding software software. It can stream live decoded data to dvtool for realtime playback using DV Dongle. It also decodes callsigns and user text or messages (like GPS position reports). You don't need any special hardware, just connect your soundcard to 9600PKT/discriminator output from your receiver. (Unfortunately his handy tools are compiled .exe's) What it can't do is decode the audio, as the separate DV dongle is needed to decode the AMBE codec. Jakub has said he has no plans to open-source his decoder. You are able to communicated with it using TCP/IP connection (data/voice IN/OUT, some commands) and use it as software modem.
dstardecoder+dvdongle-Eng.pdf OH2LAK shows in this PDF how to use Jakub Hruska's D-Star decoder program in conjunction with the DV Dongle to receive D-Star audio off a analog radio using it's 9600 baud discriminator port.
D-Star to SIP translation - An idea for interoperability by John, K7VE to provide directed reverse autopatch by mapping callsigns to a DID number. A powerful concept for EMCOMM and personal use..
D-Star Repeater Modifications - An under the hood look of the ID-RP2C, and block diagram of how it works.
ID-1's control command specification
Digital Data Packet Structure by Dick, KM4ML
Digital Voice Packet Structure by Dick, KM4ML
D-STAR Digital Voice versus Analog FM Sensitivity.pdf D-STAR Digital Voice Sensitivity versus Analog FM Sensitivity - TAPR PSR Spring 2008 by Mark, N5RFX
D-Star Adapter Satoshi Yasuda's DV and Node Adapter - One of the construction projects is a regenerative GMSK smart modem -tailored for D-Star. The other is a full blown adapter to turn an analog radio in to a D-STAR radio including provisions to encode/decode AMBE. Both interface to varactor and discriminator connections, allowing you to retro-fit an existing analog radio. It started for Satoshi by taking the UT-118 digital voice module and adapted it to work on any radio with a packet port.
Fred N. Van Kempen, PA4YBR has also announced that he too, has a working decoder. GMSK Smart Modem controller.
D-Star International Coordination Council - Announced Dec 2008 -There are at least four groups doing some level of reverse engineering. The council is help reduce the duplication-of-effort and to move forward in a more rapid and coordinated manner.. To publish a full translation of the D-STAR specification.
D-Star RF Characteristics - An analysis of the D-Star RF transmission
http://www.w4cll.com/DStar.htm -D-Star Information, Specs & links, etc.
David G4ULF's Linux D-Star Development http://g4ulf.blogspot.com/
Scott, KI4LKF's open source D-Star /Dextra work - 3 server programs that make up the "ICOM compatible" G2 Gateway. Reflector, GMSK node adapter, DV Dongle modular tools.
Decoding D-Star / AMBE DTMF? - Can a digital pattern be recognized from the raw DV stream without the AMBE chip?
Jonathan G4KLX, started the d_star_development group for his software and reference source code for capturing D-Star transmissions straight from the discriminator. The group is dedicated to discussing and sharing information about implementing D-Star systems using non Icom D-Star hardware, this includes end user and repeater systems, hardware and software.
CHIRP is a cross-platform, cross-radio programming tool. It works on Windows and Linux (and soon, MacOSX). It can program all of the ICOM D-STAR (or D-STAR-capable) radios and exchange data between them. The CHIRP repeater tool provides a way to read and write the frequency setting of ICOM D-STAR Repeater modules from a Linux machine with the command line. By Dan Smith, KK7DS
Bruce, KG7WI has a nice perl routine for to get and put data from/to an IC-91AD using the CIV interface that can be adapted for the IC-92AD as well.
A couple other good resources are; http://opendstar.org and the Texas Interconnect Teams forums.
P25 uses the IMBE vocoder from Digital Voice Systems Inc (DVSI). It costs $150K to get the rights to play with that mode plus $5 a seat. There is no off the shelf IC to do it. Hams would have to salvage the vocoder from existing/surplus gear... good luck with the application data sheet.
A P-25 repeater system can be configured to repeat analog FM and P-25 digital voice. This provides a transition opportunity for users and repeaters owners. Though, it is not perfect. In the business & public safety world, user radios are programmed with PL decode tones and busy channel lockout. Hams often just encode a tone to get into a repeater and listen in carrier. With a mixed mode repeater they will complain of hearing white noise when its repeating digital. If not paying attention an analog user could accidentally "step on" a digital transmission.
Audio samples: Motorola P25 XTS-2500 Ananlog FM vs APCO P25 (Repeater) - Un-decoded
APCO P25 Phase I is the present version that is in used across the country for Digital Public Safety, the P25 "open" standard has been reworked by some manufacturers limiting some of the standardization that the P25 was hoped to present..
P25 Phase I repeaters have the ability to function as a analog system or digital system.
P25 Presently operates via FDMA (Frequency Division Multiple Access) with the plan for P25 Phase II to use TDMA (Time Division Multiple Access), P25 Phase II will also have the capability to roll-back to FDMA for conventional emergency operations.
Phase 1 radios use the IMBE vocoder and Continuous 4 level FM (C4FM) modulation for digital transmissions at 4800 baud and 2 bits per symbol, yielding 9600 bits per second total channel throughput. Where: 4400 baud are associated with the digital voice, 2800 baud are used for error correction on the voice signal, 2400 baud are devoted to signaling overhead.
Receivers designed for the C4FM standard can also demodulate the "Compatible quadrature phase shift keying" (CQPSK) standard, as the parameters of the CQPSK signal were chosen to yield the same signal deviation at symbol time as C4FM while using only 6.25 kHz of bandwidth.
Phase 2 is currently under development with concurrent work being done on 2-slot TDMA and FDMA (CQPSK) modulation schemes. Phase II will use the AMBE vocoder to reduce the needed bitrate so that one channel will only require 4800 bits per second.
Significant attention is also paid to interoperability with legacy equipment, interfacing between repeaters and other subsystems, roaming capacity and spectral efficiency/channel reuse. In addition, Phase 2 work involves console interfacing between repeaters and other subsystems, and man-machine interfaces for console operators that would facilitate centralized training, equipment transitions and personnel movement.
APCO-25.pdf VHF Digital Handbook Chapter 6 excerpt for reference - includes the anatomy of the common air interface
Project 25 for Amateur Radio.pdf By: Mike Kionka, KI0GO - QST Sept 08
A Guide to ASTRO Digital Radios - Authored by r0f / Shaun
quantar tuning.pdf Digital Narrowband P25 VHF High Band Astro Quantar Station Standardized Service & Alignment Procedure
Astro-Spectra-COS-Take-Off.jpg Astro-Spectra squelch logic take off
APCO P25 Standards.pdf APCO Project 25 Standards for Public Safety Digital Radio
APCO P25 Common Air Interface (CAI) - TIA Standard
A Software-Defined Radio Receiver for APCO Project 25 Signals
Eric Ramsey's Thesis-- details an implementation using PC soundcard and analog FM radio.
astro modem card.jpg Astro Modem Daughterboard information
An "amateur" P25 repeater using Maxtracs - by Tim Warth, AA2RS.
WVRA Quantar PL-Strip Information - Dual Mode Quantar with a stripped PL tone on hang time.
http://openp25.org/ - Consideration is being given to enhancing Asterisk app_rpt to support a low-level P25 radio interface.
Decoding P25 - Some miscellaneous notes on peoples efforts, and functional NAC decoder software
openp25.org - A full-featured open source P25 ISSI switch is clearly achievable using the open source Asterisk PBX as good framework on which to build it
Introduction to Motorola Quantar Repeaters
http://p25ham.proboards.com/ - Local P25 Repeater Directory
Open source P25 decoder/analyzer project A project compatible with a GNU Radio or NFM radio connected to a sound card via a discriminator tap.
http://www.sedition.org.au/op25 - OP25 is a project to bring together folks that are interested in implementing APCO P25 using software-defined radio.
DMR / Mototrbo
Digital Mobile Radio (DMR) is sometimes called MOTOTRBO. Which is Motorola's implementation of the standard. DMR originated as a European Telecommunications Standards Institute (ETSI) standard, first published in 2005.
The DMR Association is the industry body promoting adoption of the standard and includes these companies as members: Harris, Hytcra, Icom, JVC, Kenwood, Motorola, Tait Communications, Vertex Standard, and Zetron.
The KA9FLX repeater in Chicago, IL was the first Mototrbo/DMR Amateur Radio Repeater in the US. It was put on the air in 2008. Since then, over 90 repeaters have been reported as up and running.
DMR repeatrs, not only interoperate with digital and analog, but can support two simultaneous conversations using TDMA.
The Beginners Guide To Mototrbo
TRBO Hits the Amateur Bands - By Bob Witte, K0NR - CQ-VHF - Spring 2012
During the 2011 Tokyo Ham Fair, Yaesu presented a new line of digital ham radios. Then a short time later in late 2011, a new page on the Yeasu website titled "The Dawn of Digital Communications in the Amateur Radio World" appeared. "2012 will be a historic year that sees Yaesu lead Amateur Radio into the modern era of Digital Communications."
It appears that Yeasu will be introducing radios to the ham market in 2012 based off DMR using C4FM / FDMA modulation. Just before Dayton 2012, the FT-1DR was unveiled. December 2012, the FTM-400DR mobile radio was unveiled. And at the 2013 ARRL/TAPR DCC the final component, a repeater for the Yeasu digital radios, called "System Fusion" was unveiled.
Sept 2013 System Fusion Product Bulletin - Details key features
Sept 2013 Digital Product Overview - Contains Specifications
There are 3 tiers in the DMR standard (described in ETSI technical standard TS102 361), the FT-1DR appears to be a Tier 1 product. Unfortunately this isn't really compatible with anything else on the market, other than the dPMR products intended for licence-free applications mainly in Europe? (maybe someone can please confirm this)
Quote from the Yeasu PDF:
"The most attractive benefit of digital communication is its ability to transfer large amounts of data. While it is commonly believed that narrowing the occupied bandwidth to efficiently utilize the frequency spectrum, is the primary advantage of Digital radio, we know that if the bandwidth is made narrower we lose the large data transmission advantage. In this situation, it becomes difficult to understand why anyone would want to use Digital communication for this purpose."
"At this point in time, Vertex Standard believes the C4FM (4-level FSK) FDMA
or TDMA are the most suitable selections for Amateur radio applications. In
early 2012, we will release a C4FM (4-level FSK) FDMA Handy-Talky and a Mobile
transceiver into the Amateur radio market.
After our initial introduction, we plan to introduce a C4FM (4-level FSK) TDMA (2 slots) or TDMA Handy and Mobile transceiver into the Amateur market."
Misc DV Related:
Digital Speech Decoder - an open source software package that decodes several digital radio formats off a discriminator tap
Digital Voice Amateur Radio Association - For comparison audio samples P25, D-Star, MotoTRBO and more
There is now a new digital system called NXDN digital (aka Kenwood NEXEDGE, Icom IDAS). Reports are that it really does a fine job, sounds better than Mototrbo and P25 Phase 1 Digital. It really looks quite promising, cost wise as well. Nexedge / Idas repeaters like P25 systems are also capable of mixed mode, reverse compatible with existing analog FM. They also use the AMBE+2 codec that reportedly can fully interoperable with the current P25 IMBE standard. The AMBE+2 can also operate at half rates of 3.6 kbps for Phase 2. The AMBE+2 provides improved voice quality, better noise immunity, tone capability, and other new features. These Enhanced Vocoders significantly improve the voice performance of the P25 system, while facilitating the migration and interoperability between new and existing P25 equipment.
Terrestrial Trunked Radio (TETRA) is a European Telecommunications Standards Institute (ETSI) standard using Time Division Multiple Access (TDMA) with four user channels on one radio 25 KHz carrier. TETRA has been in use in the Public Safety market in Europe, Asia, and Indonesia since the late 1990's. (It's their P25 equivalent). However it wasn't till late 2011 the FCC amended Part 90 for use in the USA. TETRA radios can switch to telephone interconnect providing access to public telephone networks using the SIP Voice over IP standard.
In 2011 the first two-way TETRA amateur radio contact took place in the Netherlands on 434.000 MHz.