[aprssig] APRS Voice links?

[Stephen H. Smith]

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 
forward block.

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 
real-time.

___________________________________