DSPRelated.com
Forums

Q on Reed-Solomon Uncorrectable Errors

Started by Ken Ryan March 30, 2009
On Apr 1, 8:20&#4294967295;pm, Ken Ryan <newsr...@leesburg-geeks.org> wrote:
> Steve Pope wrote: > > Ken Ryan &#4294967295;<newsr...@leesburg-geeks.org> wrote: > > >> Steve Pope wrote: > > >>> Ken Ryan &#4294967295;<newsr...@leesburg-geeks.org> wrote: > > >>>> Is there some way to characterize X% chance of detecting 3-symbol > >>>> errors, Y% chance of detecting 4-symbol errors, etc.? &#4294967295; > >>> Certainly, these percentages (once you define exactly what > >>> you're talking about) can be stated exactly based on pure > >>> combinatorics. > > >> Do you happen to know of someplace you can point me where I can learn > >> how to do this? > > > Usually you can assume that any uncorrectable error pattern > > gives you a random syndrome (out of the 2^16 syndrome > > patterns for your code). &#4294967295;You can calculate how many of > > these syndromes correspond to 0, 1, or 2 errors. &#4294967295;(Making > > sure you only consider valid error locations for the > > shortened code.) &#4294967295;Those would be the misdecodes, while the rest > > of them would be the detectable uncorrectables. > > > There is a respect in which this assumption is not > > quite exact, but the difference is probably not too > > significant. > > > Steve > > OK, thanks for the explanation. &#4294967295;I need to think on it a bit - this is a > learning curve for me! > > &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; Ken
you spoke about "clumps" of errors.. do you know about "interleaving" ? Mark
<makolber@yahoo.com> wrote:

>you spoke about "clumps" of errors.. > >do you know about "interleaving" ?
I believe Ken's statement, that the nonbinary code would outperform a binary code if the errors are in short bursts, is true independent of interleaving. This is actually a fairly important area of code design. If the errors are bursty, and the first thing you do is interleave, you've actually removed useful information and your coding will now be suboptimal (in the general case). This also ties back to the notion mentioned a couple threads ago that an AWGN channel is actually the worst possible channel for a given noise energy. Steve
makolber@yahoo.com wrote:
> On Apr 1, 8:20 pm, Ken Ryan <newsr...@leesburg-geeks.org> wrote: >> Steve Pope wrote: >>> Ken Ryan <newsr...@leesburg-geeks.org> wrote: >>>> Steve Pope wrote: >>>>> Ken Ryan <newsr...@leesburg-geeks.org> wrote: >>>>>> Is there some way to characterize X% chance of detecting 3-symbol >>>>>> errors, Y% chance of detecting 4-symbol errors, etc.? >>>>> Certainly, these percentages (once you define exactly what >>>>> you're talking about) can be stated exactly based on pure >>>>> combinatorics. >>>> Do you happen to know of someplace you can point me where I can learn >>>> how to do this? >>> Usually you can assume that any uncorrectable error pattern >>> gives you a random syndrome (out of the 2^16 syndrome >>> patterns for your code). You can calculate how many of >>> these syndromes correspond to 0, 1, or 2 errors. (Making >>> sure you only consider valid error locations for the >>> shortened code.) Those would be the misdecodes, while the rest >>> of them would be the detectable uncorrectables. >>> There is a respect in which this assumption is not >>> quite exact, but the difference is probably not too >>> significant. >>> Steve >> OK, thanks for the explanation. I need to think on it a bit - this is a >> learning curve for me! >> >> Ken > > you spoke about "clumps" of errors.. > > do you know about "interleaving" ? >
Yes, I do. In my case, 4-bit symbols are a natural fit for how my data is being stored and transported. My error model (how I expect errors will be introduced into the system) will affect any number of bits within the symbol, but is extremely unlikely to cross symbols. (sorry I can't be explicit as to what I'm doing). As Steve surmised, in my case a uniform distribution of bit errors is entirely the wrong model. Thanks, Ken