DSPRelated.com
Forums

Re: OT: The Truth About Predator Drones

Started by krw December 18, 2009
On 12/19/2009 7:40 PM, Andrew Swallow wrote:
> Eric Jacobsen wrote: >> On 12/19/2009 12:24 PM, Archimedes' Lever wrote: >>> On Fri, 18 Dec 2009 19:04:59 -0600, krw<krw@att.bizzzzzzzzzzz> wrote: > {snip} > >>> >>> You're an idiot. Most digital links can handle up to 10 percent bit >>> error rate before correction coding fails to fix it. >> >> Generally not. Raw BER for BPSK at 0dB is less than 10 percent, and >> few codes can operate that far down. Even capacity-approaching codes >> generally need input error rates higher than that. >> >> Can you name a code and what code rate would be required to operate >> with an input BER of 10e-1? I wouldn't think anyone would use a >> deep-space code on a satellite because of bandwidth efficiency issues. >> > > Tactical military links to a mobile destination are being specified > as static civilian links. An error rate of 1 in 10 on a battle > field is far from impossible. The military will simply have to live > with losing half their bandwidth to the FEC. The links also suffer > badly from block errors - a mixture of motor bike engines and > frequency hopping jammers. No need to be paranoid, the jammers have > operators who are out to get you. > > Andrew swallow
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. So I think there's a lot of misinformation being thrown around this thread, but that's probably not surprising anybody. -- Eric Jacobsen Minister of Algorithms Abineau Communications http://www.abineau.com
On Dec 20, 2:36&#4294967295;am, Eric Jacobsen <eric.jacob...@ieee.org> wrote:
> On 12/19/2009 7:40 PM, Andrew Swallow wrote: > > > > > > > Eric Jacobsen wrote: > >> On 12/19/2009 12:24 PM, Archimedes' Lever wrote: > >>> On Fri, 18 Dec 2009 19:04:59 -0600, krw<k...@att.bizzzzzzzzzzz> wrote: > > {snip} > > >>> You're an idiot. Most digital links can handle up to 10 percent bit > >>> error rate before correction coding fails to fix it. > > >> Generally not. Raw BER for BPSK at 0dB is less than 10 percent, and > >> few codes can operate that far down. Even capacity-approaching codes > >> generally need input error rates higher than that. > > >> Can you name a code and what code rate would be required to operate > >> with an input BER of 10e-1? I wouldn't think anyone would use a > >> deep-space code on a satellite because of bandwidth efficiency issues. > > > Tactical military links to a mobile destination are being specified > > as static civilian links. An error rate of 1 in 10 on a battle > > field is far from impossible. The military will simply have to live > > with losing half their bandwidth to the FEC. The links also suffer > > badly from block errors - a mixture of motor bike engines and > > frequency hopping jammers. No need to be paranoid, the jammers have > > operators who are out to get you. > > > Andrew swallow > > 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. &#4294967295; Yielding half the bandwidth to FEC overhead is actually > practical, and using R = 1/2 coding over satellite channels is quite > common. &#4294967295; 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. > > So I think there's a lot of misinformation being thrown around this > thread, but that's probably not surprising anybody.
I was thinking the same thing. If someone allows me to send 7 FEC bytes for every 1 byte of payload, I could get reliable transmission over a salted wet noodle. -Le Chaud Lapin-
On Dec 20, 2:36&#4294967295;am, Eric Jacobsen <eric.jacob...@ieee.org> 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. &#4294967295; Yielding half the bandwidth to FEC overhead is actually > practical, and using R = 1/2 coding over satellite channels is quite > common. &#4294967295; 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
On 12/20/2009 10:32 AM, Steve Pope wrote:
> On Dec 20, 2:36 am, Eric Jacobsen<eric.jacob...@ieee.org> 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
Eric Jacobsen  <eric.jacobsen@ieee.org> wrote:

>On 12/20/2009 10:32 AM, Steve Pope wrote:
>> On Dec 20, 2:36 am, Eric Jacobsen<eric.jacob...@ieee.org> 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...
>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.
Agree
>Not a lot of difference there from a >capacity perspective.
Correct; as one gets into lower code rates, going to even lower rates tends to give you no additional normalized coding gain (i.e. the additional coding performs no better than a repetition code).
>For uncoded, i.e., raw BER of 1e-1 happens at about -1dB Eb/No
Actually it's about -1.7 dB, but let's say it's -1 for the sake of argument. (or about -4dB (equivalent raw Eb/No) at R = 1/2, and -5.77dB (equivalent raw Eb/No) for R = 1/3. I'm not sure what this sentence means. A rate 1/2 coded system operating at an Eb/No of +2 dB has the same raw BER as an uncoded system operating at an Eb/No of -1 dB. A rate 1/3 coded system operating at an Eb/No of +3.77 dB has the same raw BER as an uncoded system operating at -1 dB. (Unless I'm confused, which has happened before...)
>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.
I'm not too skeptical. I would posit that GSM phones in their basic 2G mode operate under conditions this bad, and 802.11 systems at 1 mbps might also. Steve
On 12/20/2009 3:42 PM, Steve Pope wrote:
> Eric Jacobsen<eric.jacobsen@ieee.org> wrote: > >> On 12/20/2009 10:32 AM, Steve Pope wrote: > >>> On Dec 20, 2:36 am, Eric Jacobsen<eric.jacob...@ieee.org> 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... > >> 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. > > Agree > >> Not a lot of difference there from a >> capacity perspective. > > Correct; as one gets into lower code rates, going to even lower rates > tends to give you no additional normalized coding gain (i.e. the > additional coding performs no better than a repetition code). > >> For uncoded, i.e., raw BER of 1e-1 happens at about -1dB Eb/No > > Actually it's about -1.7 dB, but let's say it's -1 for the > sake of argument. > > (or about > -4dB (equivalent raw Eb/No) at R = 1/2, and -5.77dB (equivalent raw > Eb/No) for R = 1/3. > > I'm not sure what this sentence means. > > A rate 1/2 coded system operating at an Eb/No of +2 dB has the > same raw BER as an uncoded system operating at an Eb/No of -1 dB. > > A rate 1/3 coded system operating at an Eb/No of +3.77 dB has > the same raw BER as an uncoded system operating at -1 dB. > > (Unless I'm confused, which has happened before...)
Doh! I think I went the wrong way with the 3db and 4.77dB differences. I get stuff like that backwards all the time.
>> 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. > > I'm not too skeptical. I would posit that GSM phones in their > basic 2G mode operate under conditions this bad, and 802.11 systems > at 1 mbps might also. > > Steve
I'm less skeptical now. ;) -- Eric Jacobsen Minister of Algorithms Abineau Communications http://www.abineau.com
Eric Jacobsen  <eric.jacobsen@ieee.org> wrote:

>On 12/20/2009 3:42 PM, Steve Pope wrote:
>> A rate 1/2 coded system operating at an Eb/No of +2 dB has the >> same raw BER as an uncoded system operating at an Eb/No of -1 dB. >> >> A rate 1/3 coded system operating at an Eb/No of +3.77 dB has >> the same raw BER as an uncoded system operating at -1 dB.
>> (Unless I'm confused, which has happened before...)
>Doh! I think I went the wrong way with the 3db and 4.77dB differences. >I get stuff like that backwards all the time.
Okay, we're in sync, even if our hypothetical modem isn't.
>> I'm not too skeptical. I would posit that GSM phones in their >> basic 2G mode operate under conditions this bad, and 802.11 systems >> at 1 mbps might also.
>I'm less skeptical now. ;)
Right. The AWGN channel exhibiting 10% raw BER is still 3 dB less noisy than rate 1/3 BPSK capacity, and popular binary convolutional codes generally start functioning when you're 2 dB to 3 dB from capacity. The near-channel-capacity codes are generally functional around 1 dB from capacity, sometimes less. Steve
On 12/21/2009 12:42 PM, Steve Pope wrote:
> Eric Jacobsen<eric.jacobsen@ieee.org> wrote: > >> On 12/20/2009 3:42 PM, Steve Pope wrote: > >>> A rate 1/2 coded system operating at an Eb/No of +2 dB has the >>> same raw BER as an uncoded system operating at an Eb/No of -1 dB. >>> >>> A rate 1/3 coded system operating at an Eb/No of +3.77 dB has >>> the same raw BER as an uncoded system operating at -1 dB. > >>> (Unless I'm confused, which has happened before...) > >> Doh! I think I went the wrong way with the 3db and 4.77dB differences. >> I get stuff like that backwards all the time. > > Okay, we're in sync, even if our hypothetical modem isn't. > >>> I'm not too skeptical. I would posit that GSM phones in their >>> basic 2G mode operate under conditions this bad, and 802.11 systems >>> at 1 mbps might also. > >> I'm less skeptical now. ;) > > Right. > > The AWGN channel exhibiting 10% raw BER is still 3 dB less noisy than > rate 1/3 BPSK capacity, and popular binary convolutional > codes generally start functioning when you're 2 dB to 3 dB from capacity. > > The near-channel-capacity codes are generally functional around 1 dB > from capacity, sometimes less. > > Steve
Yeah, we're on the same page. Since the context was a satellite link, I'd still be skeptical that anyone would bother to use an R = 1/3 code over a satellite, just because of the spectral efficiency (since transponder bandwidth is muy expensive). For R = 1/2, which is more believable, my skepticism remains healthy. -- Eric Jacobsen Minister of Algorithms Abineau Communications http://www.abineau.com
Eric Jacobsen wrote:
> On 12/21/2009 12:42 PM, Steve Pope wrote: >> Eric Jacobsen<eric.jacobsen@ieee.org> wrote: >> >>> On 12/20/2009 3:42 PM, Steve Pope wrote: >> >>>> A rate 1/2 coded system operating at an Eb/No of +2 dB has the >>>> same raw BER as an uncoded system operating at an Eb/No of -1 dB. >>>> >>>> A rate 1/3 coded system operating at an Eb/No of +3.77 dB has >>>> the same raw BER as an uncoded system operating at -1 dB. >> >>>> (Unless I'm confused, which has happened before...) >> >>> Doh! I think I went the wrong way with the 3db and 4.77dB differences. >>> I get stuff like that backwards all the time. >> >> Okay, we're in sync, even if our hypothetical modem isn't. >> >>>> I'm not too skeptical. I would posit that GSM phones in their >>>> basic 2G mode operate under conditions this bad, and 802.11 systems >>>> at 1 mbps might also. >> >>> I'm less skeptical now. ;) >> >> Right. >> >> The AWGN channel exhibiting 10% raw BER is still 3 dB less noisy than >> rate 1/3 BPSK capacity, and popular binary convolutional >> codes generally start functioning when you're 2 dB to 3 dB from capacity. >> >> The near-channel-capacity codes are generally functional around 1 dB >> from capacity, sometimes less. >> >> Steve > > Yeah, we're on the same page. Since the context was a satellite link, > I'd still be skeptical that anyone would bother to use an R = 1/3 code > over a satellite, just because of the spectral efficiency (since > transponder bandwidth is muy expensive). For R = 1/2, which is more > believable, my skepticism remains healthy.
Remember: this is military money. Those birds are $30 million a pop. Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
Eric Jacobsen  <eric.jacobsen@ieee.org> wrote:

>Since the context was a satellite link, >I'd still be skeptical that anyone would bother to use an R = 1/3 code >over a satellite, just because of the spectral efficiency (since >transponder bandwidth is muy expensive). For R = 1/2, which is more >believable, my skepticism remains healthy.
You're right in that the rate 1/2 convolutional code (which is very popular for SATCOM and is specified for such use in MIL-STD-188) just misses working at the 10% raw BER channel condition point. For noisier satellite channels it's more popular to lower the signalling rate than it is to lower the code rate. (We could also have a philosophical discussion as to whether adding spreading constitutes lowering the code rate...) Steve