[aprssig] APRS Voice links?
Kristoff Bonne
kristoff.bonne at skypro.be
Sun May 19 16:34:59 EDT 2013
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
More information about the aprssig
mailing list