Re: FEC paper, implementation
- To: email@example.com
- Subject: Re: FEC paper, implementation
- From: Phil Karn <firstname.lastname@example.org>
- Date: Fri, 17 Mar 1995 10:08:29 -0800
- Cc: Jarkko.Vuori@hut.fi, email@example.com, firstname.lastname@example.org, PG@tasma.han.de, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
- In-reply-to: <9503162316.AA04204@sys3.pe1chl.ampr.org> (email@example.com
>Ok, I realize that I forgot to mention it, but my main reason for suggesting
>the DSP4 was that you could run the code tightly coupled with the moodem,
Yes. A DSP card directly on the PC bus would make this a lot easier. Also,
Bob Stricklin has been designing an Ethernet interface for the DSP-93
that would make it easier to move the much larger amount of data in soft
decision samples to the PC host for decoding.
>Right. And the ideas like moving the sampling interval to get best eye
>pattern are easier to realize when there is a tight coupling between the
>A/D and the FEC processing.
One idea I've had here in conjunction with my new protocol is to use
the sync vector for symbol timing. That is, you sample the baseband
data stream at some multiple of the symbol rate and run it through a
correlator looking for the sync vector at the front of the packet
(this sync vector is tentatively 64 bits long, so it should be very
reliable). When the correlator peaks, you declare packet sync and
begin "blindly" clocking off symbols from that point. As long as the
transmit and receive clocks are reasonably close in frequency, and as
long as the packet isn't too long, this should provide good symbol
timing no matter how many fades you have within the packet.
The sync vector could be interleaved with the (fixed size) packet header
to make it a little less vulnerable to short fades.
The correlation is of course a natural job for the DSP.