[aprssig] APRS Voice links?
Stephen H. Smith
wa8lmf2 at aol.com
Sun May 19 15:28:19 CDT 2013
On 5/19/2013 1:08 PM, Robert Bruninga wrote:
> At Dayton there was a lot of excitement about FREE Digital Voice (FreeDV)
> Although it is currently being applied to robust HF communications at about
> 1200 baud in a 3 KHz channel, the basic Vocoder works at about 1000 baud or as
> low as 800 bits if the data stream is error protected.
(Ie inside an AX.25
> connected packet).
There is no forward error correction in AX.25. All it can do is request that a
bad packet be resent, thereby interrupting the continuous transmission of data
blocks (i.e. not "repair" the bad packet locally).
All the newer digital radio techniques (D-Star, DMR, P25, Tetra, etc) that are
optimized for real-time voice operation use massive amounts of
forward-error-correcting codes (i.e. data redundancy) embedded in the
continuous data stream that lets errors be fixed on-the-fly without
interrupting the transmission for retrys.
> At the risk of exposing my ignorance, I wonder how close we could get to
> relaying the raw Vocoder over an AX.25 link using our existing 9600 baud modems
> built into the Kenwoods?
The digital audio assumes a continuous transmission stream, not busted up into
little start/stop blocks with lots of overhead, headers, acks, etc added.
Even with the slow TXD delays (500 ms!) in Kenwood
> 9600 baud modems, a conversation could be continuous if the radio was
> transmitting this information at 9600 baud in packets once a second maybe...
Considering that even the Kenwood manual warns you that the signal strength has
be be essentially full-scale on the S-meter before the packet mode works
reliably, the main effect would be eliminate all fringe area operation of the
radio, cutting the usable coverage by about 2/3rds compared to analog FM.
Further, every block transmitted forward will require the receiving station to
key up (with another 500 mS TXD!) and send an ACK back to the sending station,
cutting the net throughput massively, thereby delaying receipt of the next
Any missed packets will have to go through the usual AX.25 NAK/ARQ to the
sender and subsequent re-transmission, each with another TXD + other TX
latencies, resulting in huge delays getting the replacement block, while
further delaying the transmissions of the following blocks.
If it works at all, you are most likely to get a hiccupping stuttering effect
like a crappy digital cellphone in a fringe area, if it works at all.
> This would give experimenters a chance to see what we can do with Digital Voice
> using existing AX.25 links.
> I have no idea what a network would look like, but if IGates could receive
> these 9600 baud connections,
So you would clog igates with continuous streams of connected-mode packets
bearing blocks of voice data ??? Not to mention the several seconds latency
passing through the APRS-IS
This would make L.A.'s APRS congestion look like a clear channel by comparison!
then it would seem like we could cobble together
> some kind of A-STAR system where we use the frton panel controls and APRS to
> set up who we want to talk to and then the IGates link us between any two hams
> anywhewre on the planet along with their APRS traffic.
> Anyway, a whole new exciting area to think about. Remember, it has always been
> my goal to have callsign-to-callsign voice contact (using APRS connectivity to
> set up the call). At first I thought IRLP, then Echolink, then ALL-STARR would
> be the answere. Then D-star actally is now doing it, and we still have not
> gotten organized to simply take what we have and do it too.
Because the D-Star protocol is purpose-built for continuous real-time data
streams like digitized voice, --- unlike AX.25 which was built over thirty
years ago for intermittent bursty transmission of TTY-like text that is not
More information about the aprssig