XPost: comp.dsp, sci.crypt, sci.electronics.design
From: eric.jacobsen@ieee.org
On 12/20/2009 10:32 AM, Steve Pope wrote:
> On Dec 20, 2:36 am, Eric Jacobsen wrote:
>
>> The point was really that even from an advanced FEC standpoint an input
>> BER of 1 in 10 isn't practical to work with for the described
>> application. Yielding half the bandwidth to FEC overhead is actually
>> practical, and using R = 1/2 coding over satellite channels is quite
>> common. Using something like an R = 1/6 capacity-approaching code to
>> be able to handle such low input error rates is, I think, not practical.
>
> Last I checked, such a channel is within the operating range of a rate
> 1/3 binary convolutional code...
>
> Steve
BICO capacity for R = 1/2 is at about 0.177dB Eb/No, and for R = 1/3
it's about -0.357dB Eb/No. Not a lot of difference there from a
capacity perspective.
For uncoded, i.e., raw BER of 1e-1 happens at about -1dB Eb/No (or about
-4dB (equivalent raw Eb/No) at R = 1/2, and -5.77dB (equivalent raw
Eb/No) for R = 1/3. The BER curve is pretty flat out there, i.e., it's
asymptotic from 1e-1 at -1dB to 5e-1 at -infinity, so for
capacity-approaching codes they're all going to be in the ballpark of
1e-1 for the code to work.
Maintaining synchronization down in that mud is a whole 'nuther issue,
and satellite transponder bandwidth is expensive enough that it's very
rare to see codes lower than R = 1/2. Keeping a practical demod
synchronized below about 0dB is not at all trivial.
So I'm skeptical. In a practical system, especially a practical
satellite system, I think it'd be very difficult to operate with an
input BER of 1e-1.
--
Eric Jacobsen
Minister of Algorithms
Abineau Communications
http://www.abineau.com
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
