TCP-group 1995
[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: FEC paper, implementation
- To: pe1chl@wab-tis.rabobank.nl
- Subject: Re: FEC paper, implementation
- From: Phil Karn <karn@unix.ka9q.ampr.org>
- Date: Thu, 16 Mar 1995 10:02:33 -0800
- Cc: Jarkko.Vuori@hut.fi, kwi@lesti.hut.fi, geertj@ripe.net, PG@tasma.han.de, martin@gw6hva.demon.co.uk, kohjin@marina.prug.or.jp, ptaylor@email.meto.govt.uk, henkp@paramount.nikhefk.nikhef.nl, tcp-group@ucsd.edu, karn@unix.ka9q.ampr.org
- In-reply-to: <9503161154.AA02088@sys3.pe1chl.ampr.org> (rob@sys3.pe1chl.ampr.org
Rob,
>I think a nice platform to do these experiments would be the DSP4. It
I'm not convinced that a DSP has any special advantage over a general
purpose CPU in executing FEC algorithms. A general purpose CPU (such
as the one already running NOS) is fast enough for ham use, especially
with sequential decoding. My Fano decoder in C runs at roughly 280-320
kilobranches/sec on a 66 MHz 486DX2 in protected (32 bit) mode. That
translates directly to 280-320 kilobits/sec on "clean" packets with
little backward decoder motion.
Even my Viterbi (K=7, r=1/2) decoder program runs over 40 kb/s on the
same machine.
What I *would* like from a DSP is a modem that gives me "soft
decision" samples. This results in an additional coding gain of 2dB on
AWGN channels with linear modulation (PSK), bringing the Eb/N0
requirement for the r=1/2 K=32 sequentially decoded code down to 3dB.
Hardware modems could be modified to do this by replacing the slicer
with an A/D converter having at least 3 bits of precision, but on a
DSP it would just be a matter of software.
I'm currently packaging up my Fano decoder and will be releasing it
shortly for people to experiment. I'll follow up with my Viterbi
decoder.
Phil