[aprssig] APRS Voice links?

[Kristoff Bonne]

Hi Robert,



On 19-05-13 19:08, 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).

Just to get some figures correct:

FreeDV uses the codec2 vocoder. That codec exists in a couple of 
different speeds: 1200, 1400, 2400 and -I think- also 3600 bps. FreeDV 
uses the 1400 bps version.

The first version of FreeDV used 1400 bps on HF, so the 1400 bps codec 
without any FEC. The new version (now implemented in the FreeDV clients) 
uses 1600 bps on HF, so adding FEC on some parts of the voice. The 
bandwidth on HF using SSB is 1.25 Khz.


BTW. There is a 2nd modem for codec2: c2gmsk, which is a GMSK based 
modem for 10 meters, VHF and UHF. The version now in on github is 4800 
bps using a very based FEC system. I am working on incorperating the 
test-code for the 2400 bps version in the code.
The gmsk modem exists as some test-applications -mainly oriented towards 
small linux-boards like the raspberry pi- and as an API.
Work is being done to get the GMSK modem into FreeDV.


> 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?   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...

Well, it depends.
I think the major issue is not end-to-end bitrate. It's how the network 
layer will have to deal with transmission errors.


I'll first explain this:

There is a conceptual difference between "digital data" and "digital voice".
David (Rowe, designed of cocec2) has done quite some work to make the 
codec as robust as possible concering biterrors.

The basic idea is this: in DV, "not all bits are equal". The audiable 
effect when certain bits of a DV frame are corrupted will differ quite a 
bit when other bits are destroyed.
This is very different from "digital data", where the network layer has 
no idea about the contents is of the data its carries, so it has to 
concider all bits equality imporant.


The big advantage for this is that, if you know how "important" certain 
bits in the stream are, you can apply FEC much more selectively then

Also, in voice, the FEC system used on DV actually provides information 
on the number of biterrors on the stream. If it noticed that a certain 
frame is corrupted real bad, it can take some special steps: e.g. repeat 
the previous frame or replace the frame with silence.

So, in the end, it's not necessairy a dissaster if you loose -say- 50 or 
100 ms voice once in a while. The human brain will "correct" that anyway.



So, let's get back to DV over packet.
Appart from the aspect of throughput, you have to compair it to how it 
deals with errors.

When using a DV protocol (like D-STAR), the big advantage is this: a 
station starts transmitting a stream, it arrives at a repeater, this 
then send the stream to some other repeater over the internet, where it 
is rebroadcast as a GMSK stream to the remote receiving radio.

If there are transmission errors (e.g. on the path from the sender to 
the repeater), they are just carried from the local site to the remote 
side and will actually arrive at the remote radio.
But, -if you are lucky- the FEC system on the remote radio will be able 
to correct it. If not, the radio or the brain of listener will have to 
the  deal with it.

This is -correct me if I am wrong- very different from a packet-switched 
network. To run DV over packet, it will be very important that you find 
a way to replicate this behaviour. All components have to know how to 
deal with packets that contain errors (i.e. have CRC errors) and still 
forward them to the correct place.

If that is not the case, and require a 100 % correct packet every time 
-or else you drop the whole packet-; you completely lose the advantage 
of a DV protocol.
Especially when dealing with mobile or portable stations as these 
streams (as received by the repeater) really contains lots of errors.

 From my (althou limited) knowledge of the HAM packet networks, this is 
a completely different situation then what you have now.


> 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.  See http://aprs.org/avrs.html

To be honest. When I was still active on D-STAR, I once did a check on 
the log-files of our local D-STAR repeater to check how many people used 
callsign routing and how many used "CQCQCQ" contacts via a reflector or 
using starnet groups).
It was less then half a percent!

Compaired to the work needed to keep the whole callsign routing 
infrastructure running, I never understood why it will worth all the 
trouble!



> Maybe this new FreeDV can serve as a spark for some new thinking…
> Bob, Wb4APR

Don't get me wrong. I have absolutely not egainst  DV over packet driven 
networks; nor do I see GMSK or any other DV protocol as "the only way". 
I am a very big fan of allowing people to experiment.


I just want to point out the fundamental difference between DV (a 
real-time application where the network layer has knowledge of the 
information it carriers) and a generic data network.


BTW.
I would be very interested to see a voice-messaging service on top of 
the packet-switched networks. Using a vocoder like codec2 (when using 
the 1200 bps version, i.e. garanteed error-free), you can stuff a 
complete 1 minute message in 1200 octets!


73
kristoff - ON1ARF