On Wed, 15 Jan 2014 12:49:35 -0600, Les Cargill <lcargill99@comcast.com> wrote:>Tim Wescott wrote: >> On Wed, 15 Jan 2014 02:46:44 +0000, Eric Jacobsen wrote: >> >>> On Tue, 14 Jan 2014 13:24:24 -0600, Tim Wescott >>> <tim@seemywebsite.really> wrote: >>> >>>> On Tue, 14 Jan 2014 16:49:44 +0000, Eric Jacobsen wrote: >>>> >>>>> On Tue, 14 Jan 2014 16:40:12 +0100, Johannes Bauer >>>>> <dfnsonfsduifb@gmx.de> wrote: >>>>> >>>>>> Hi group, >>>>>> >>>>>> when designing an error correcting function it's usually assumed that >>>>>> the error rate is relatively small (i.e. the ratio of "good" bits to >>>>>> "bad" bits is usually well above 1). However, let's assume we have a >>>>>> transmission that is extremely faulty and produces only 1 "good" bit >>>>>> every 10 bits on average. What kind of error correction mechanisms >>>>>> would be applicable to such a distribution? Let's say we want to be >>>>>> able to recover the original bitstream with a 99% probability and >>>>>> still want to keep the overhead to a minimum. >>>>> >>>>> You're going to be looking for very, very, very low rate codes, but >>>>> they must still be very carefully selected. >>>>> >>>>> Julius pointed you in a good direction, in that finding very low rate >>>>> block codes with large distances will be required (assuming random >>>>> error distribution). >>>>> >>>>> That's a very unusual application and I don't know if any such codes >>>>> have already been developed. >>>> >>>> If the errors are truly random, then a good first stage may just be to >>>> average and decimate over a whole bunch of bits (i.e., use a repetitive >>>> code). Eventually you'll end up with something much slower that will be >>>> tractable for conventional FEC techniques. >>>> >>>> In a sense, this is what GPS and other "one-bit ADC" spread-spectrum >>>> receivers do: if you look at it from the right angle you can take the >>>> "one-bit ADC" as being a very error-prone bit decision, which is then >>>> added up coherently to a whole bunch of other error-prone bit decisions. >>>> Then the result is compared to some threshold, and voila! you have >>>> implemented a simple repetitive code over a whole bunch of bits. >>>> >>>> I suspect that the coding gain won't be a heck of a lot less than some >>>> more comprehensive code, and I know the system complexity _will_ be a >>>> heck of a lot less! >>> >>> Repetition codes perform very poorly, far worse than a well-designed ECC >>> or FEC for most energy or bandwidth metrics. Signal processing >>> circuits for processing gain may not be simpler than the equivalent FEC >>> circuit, so there is often not even a complexity advantage. >> >> Even when the information content per bit is going into the dumpster? If >> that's the case, why do we use spread spectrum instead of FEC encoding at >> 10MHz, followed by a receiver that uses a 1000-bit block code? >> > > >I would say "because Viterbi." > >-- >Les Cargilllulz! That works on so many levels. ;) Eric Jacobsen Anchor Hill Communications http://www.anchorhill.com
Error correcting codes for extremely high error rates
Started by ●January 14, 2014
Reply by ●January 15, 20142014-01-15
Reply by ●January 15, 20142014-01-15
On Wed, 15 Jan 2014 12:56:01 -0800 (PST), julius <juliusk@gmail.com> wrote:>On Wednesday, January 15, 2014 12:27:53 PM UTC-5, Tim Wescott wrote: >> >> Do you have an example, then, of super-long codes for very low >> information content binary data that are practical to implement? > >A binary repetition code (r,1) has minimum Hamming distance r. Its code rate is 1/r. It can correct up to r/2 errors. > >The Singleton bound says that the maximum number of codewords in a q-ary block code of length and minimum distance d is <= q^(n-d+1). Surprisingly for the humble repetition code, this bound is pretty much met.Repetition codes are, indeed, very practical to implement. ;) Eric Jacobsen Anchor Hill Communications http://www.anchorhill.com
Reply by ●January 15, 20142014-01-15
On Wed, 15 Jan 2014 11:34:24 -0800 (PST), cincydsp@gmail.com wrote:>On Wednesday, January 15, 2014 9:16:04 AM UTC-5, Eric Jacobsen wrote: >>=20 >>=20 >> The processing gain due to SS is essentially the same as the increase >>=20 >> in SNR due to leaving the psd high to start with. You don't really >>=20 >> gain any reliability from SS. >>=20 > >This truth counters what seems to be one of the largest misconceptions with= > DSSS: you don't get any improvement in BER for a given Eb/No. In fact, it'= >s impossible to do so, due to the principle of reversibility. Since applica= >tion of a spreading code is a reversible process, then the performance of t= >he optimal receiver for the spread and unspread cases must be the same. > >JasonI was visiting a company a few years ago that had had another company do the PHY design for a through-ground system for them (no, not you, Julius, somebody else in a different industry), and they had been sold a SS system because they were told "it was the only way to get processing gain to make the link work." I didn't tell them it was probably really because it was the only way to get the symbol clock stable in less than ten minutes or so, because their symbol rate was very, very low. As you say, the spreading gain is a wash compared to the power concentration gain from not spreading. I've talked to a number of managers and system engineers from cellular companies over the years who lamented that the promises of CDMA's clear superiority over GSM (back in those days) never panned out. Never underestimate the value of a good salesman. Eric Jacobsen Anchor Hill Communications http://www.anchorhill.com
Reply by ●January 15, 20142014-01-15
On Wednesday, January 15, 2014 6:42:25 PM UTC-5, Eric Jacobsen wrote:> On Wed, 15 Jan 2014 11:34:24 -0800 (PST), cincydsp@gmail.com wrote: > > > > >On Wednesday, January 15, 2014 9:16:04 AM UTC-5, Eric Jacobsen wrote: > > >>=20 > > >>=20 > > >> The processing gain due to SS is essentially the same as the increase > > >>=20 > > >> in SNR due to leaving the psd high to start with. You don't really > > >>=20 > > >> gain any reliability from SS. > > >>=20 > > > > > >This truth counters what seems to be one of the largest misconceptions with= > > > DSSS: you don't get any improvement in BER for a given Eb/No. In fact, it'= > > >s impossible to do so, due to the principle of reversibility. Since applica= > > >tion of a spreading code is a reversible process, then the performance of t= > > >he optimal receiver for the spread and unspread cases must be the same. > > > > > >Jason > > > > I was visiting a company a few years ago that had had another company > > do the PHY design for a through-ground system for them (no, not you, > > Julius, somebody else in a different industry), and they had been sold > > a SS system because they were told "it was the only way to get > > processing gain to make the link work." I didn't tell them it was > > probably really because it was the only way to get the symbol clock > > stable in less than ten minutes or so, because their symbol rate was > > very, very low. > > > > As you say, the spreading gain is a wash compared to the power > > concentration gain from not spreading. > > > > I've talked to a number of managers and system engineers from cellular > > companies over the years who lamented that the promises of CDMA's > > clear superiority over GSM (back in those days) never panned out. > > Never underestimate the value of a good salesman. > > > > > > Eric Jacobsen > > Anchor Hill Communications > > http://www.anchorhill.comOne of the beauties of CDMA is the simplicity of adding coverage. I recall at NASCAR events back when I contracted to Sprint/Nextel, the CDMA guys would roll in their portable cell sites a couple of days before the event and be up and running in a few hours. The channelized systems would take a tremendous amount of planning and setup. I recall the Nextel stuff being set up two weeks in advance and being tweaked all of the way up to race day. Clay At tracks like Talladega there would be anywhere from 250,000 to 350,000 people at the event! That's a lot of cell phones to provide coverage for.
Reply by ●January 15, 20142014-01-15
On Wednesday, January 15, 2014 6:31:57 PM UTC-5, Eric Jacobsen wrote:> Repetition codes are, indeed, very practical to implement. ;)I'm not saying it's the best one can do, I'm just saying that if we are to stick with min-distance decoding and binary-only codes, then it's pretty much the only provably good one I can think of!
Reply by ●January 15, 20142014-01-15
On Wed, 15 Jan 2014 16:26:10 -0800 (PST), clay@claysturner.com wrote:>On Wednesday, January 15, 2014 6:42:25 PM UTC-5, Eric Jacobsen wrote: >> On Wed, 15 Jan 2014 11:34:24 -0800 (PST), cincydsp@gmail.com wrote: >>=20 >>=20 >>=20 >> >On Wednesday, January 15, 2014 9:16:04 AM UTC-5, Eric Jacobsen wrote: >>=20 >> >>=3D20 >>=20 >> >>=3D20 >>=20 >> >> The processing gain due to SS is essentially the same as the increase >>=20 >> >>=3D20 >>=20 >> >> in SNR due to leaving the psd high to start with. You don't really >>=20 >> >>=3D20 >>=20 >> >> gain any reliability from SS. >>=20 >> >>=3D20 >>=20 >> > >>=20 >> >This truth counters what seems to be one of the largest misconceptions w= >ith=3D >>=20 >> > DSSS: you don't get any improvement in BER for a given Eb/No. In fact, = >it'=3D >>=20 >> >s impossible to do so, due to the principle of reversibility. Since appl= >ica=3D >>=20 >> >tion of a spreading code is a reversible process, then the performance o= >f t=3D >>=20 >> >he optimal receiver for the spread and unspread cases must be the same. >>=20 >> > >>=20 >> >Jason >>=20 >>=20 >>=20 >> I was visiting a company a few years ago that had had another company >>=20 >> do the PHY design for a through-ground system for them (no, not you, >>=20 >> Julius, somebody else in a different industry), and they had been sold >>=20 >> a SS system because they were told "it was the only way to get >>=20 >> processing gain to make the link work." I didn't tell them it was >>=20 >> probably really because it was the only way to get the symbol clock >>=20 >> stable in less than ten minutes or so, because their symbol rate was >>=20 >> very, very low. >>=20 >>=20 >>=20 >> As you say, the spreading gain is a wash compared to the power >>=20 >> concentration gain from not spreading. >>=20 >>=20 >>=20 >> I've talked to a number of managers and system engineers from cellular >>=20 >> companies over the years who lamented that the promises of CDMA's >>=20 >> clear superiority over GSM (back in those days) never panned out. >>=20 >> Never underestimate the value of a good salesman. >>=20 >>=20 >>=20 >>=20 >>=20 >> Eric Jacobsen >>=20 >> Anchor Hill Communications >>=20 >> http://www.anchorhill.com > >One of the beauties of CDMA is the simplicity of adding coverage. I recall = >at NASCAR events back when I contracted to Sprint/Nextel, the CDMA guys wou= >ld roll in their portable cell sites a couple of days before the event and = >be up and running in a few hours. The channelized systems would take a trem= >endous amount of planning and setup. I recall the Nextel stuff being set up= > two weeks in advance and being tweaked all of the way up to race day. > >Clay > >At tracks like Talladega there would be anywhere from 250,000 to 350,000 pe= >ople at the event! That's a lot of cell phones to provide coverage for.Exactly. The multiple access and frequency planning issues are greatly simplified with CDMA. Eric Jacobsen Anchor Hill Communications http://www.anchorhill.com
Reply by ●January 15, 20142014-01-15
On Wednesday, January 15, 2014 5:42:25 PM UTC-6, Eric Jacobsen wrote:> > Never underestimate the value of a good salesman. >Time to revive an old post of mine But Eric's point about comm specsmanship brings to mind an apocryphal story about how IBM won a contract for a military comm. system. Both the IBM design and Brand X had the same data rate and same BER but the IBM design used a rate 1/2 code while the competing design used a rate 2/3 code. Anyway, IBM won because they told the generals "In our system, we use one parity bit to protect each data bit, whereas in the Brand X system each parity bit has to protect *two* data bits and so their system provides only half as much data protection as ours does."
Reply by ●January 16, 20142014-01-16
On Wednesday, January 15, 2014 10:55:16 PM UTC-5, dvsarwate wrote:> Time to revive an old post of mine > > But Eric's point about comm specsmanship brings to mind > an apocryphal story about how IBM won a contract for a > military comm. system. Both the IBM design and Brand X > had the same data rate and same BER but the IBM design > used a rate 1/2 code while the competing design used a > rate 2/3 code. Anyway, IBM won because they told the > generals "In our system, we use one parity bit to protect > each data bit, whereas in the Brand X system each parity > bit has to protect *two* data bits and so their system > provides only half as much data protection as ours does."We have systems that operate at seconds-per-bit, and there are stories of competitors who manage to convince potential clients that larger seconds-per-bit numbers are better.
Reply by ●January 16, 20142014-01-16
On Thu, 16 Jan 2014 05:32:35 -0800 (PST), julius <juliusk@gmail.com> wrote:>On Wednesday, January 15, 2014 10:55:16 PM UTC-5, dvsarwate wrote: > >> Time to revive an old post of mine >> >> But Eric's point about comm specsmanship brings to mind >> an apocryphal story about how IBM won a contract for a >> military comm. system. Both the IBM design and Brand X >> had the same data rate and same BER but the IBM design >> used a rate 1/2 code while the competing design used a >> rate 2/3 code. Anyway, IBM won because they told the >> generals "In our system, we use one parity bit to protect >> each data bit, whereas in the Brand X system each parity >> bit has to protect *two* data bits and so their system >> provides only half as much data protection as ours does." > >We have systems that operate at seconds-per-bit, and there are stories of competitors who manage to convince potential clients that larger seconds-per-bit numbers are better.You didn't really need that data today, did you? ;) Eric Jacobsen Anchor Hill Communications http://www.anchorhill.com
Reply by ●January 16, 20142014-01-16
On Thursday, January 16, 2014 9:35:52 AM UTC-5, Eric Jacobsen wrote:> On Thu, 16 Jan 2014 05:32:35 -0800 (PST), julius <juliusk@gmail.com> > > wrote: > > > > >On Wednesday, January 15, 2014 10:55:16 PM UTC-5, dvsarwate wrote: > > > > > >> Time to revive an old post of mine > > >> > > >> But Eric's point about comm specsmanship brings to mind > > >> an apocryphal story about how IBM won a contract for a > > >> military comm. system. Both the IBM design and Brand X > > >> had the same data rate and same BER but the IBM design > > >> used a rate 1/2 code while the competing design used a > > >> rate 2/3 code. Anyway, IBM won because they told the > > >> generals "In our system, we use one parity bit to protect > > >> each data bit, whereas in the Brand X system each parity > > >> bit has to protect *two* data bits and so their system > > >> provides only half as much data protection as ours does." > > > > > >We have systems that operate at seconds-per-bit, and there are stories of competitors who manage to convince potential clients that larger seconds-per-bit numbers are better. > > > > You didn't really need that data today, did you? ;) >We consider both "Real-Time" and "Relevant-Time" ;-).
