Re: Barcodes & error detection

In lugnet.robotics, Steve Baker <[email protected]> wrote:

> there is a sharp distinction between error
> DETECTION and error CORRECTION.

   Agreed, and, for this application, the bit overhead to allow on-board
correction is probably just not worth it. After all, if an error is detected,
the forklift can always back up and try to read the barcode again.

> It's also important to characterize the errors you are getting.

   Almost exclusively single bit errors of a specific 'polarity' (to borrow
Kevin's term; a '1' is read as a '0'). In detail, I set Gus to running around an
oval reading barcode representing the numbers from 0 to 11. In more than 1470
barcodes, there were 40 errors, 39 of which were single bit events where a 1 was
read as a 0 (that last error was a "bit doubling", where a single bit was read
twice due to "wiggle" in the motion of the forklift & a barcode that had shifted
to an angle *and* the light sensor was near the edge... yes, I've spent a fair
bit of time troubleshooting ;-).

> For single bit error detection, your parity scheme
> is pretty much the best you can do.

   So I feared. Error correcting codes amaze me, but everything I'd read or
studied tends to apply to long words, not the minimalist ones I'm trying to use.

[snip very interesting theoretical discussion]

> Sometimes, adding single bit error correction can
> actually worsen your overall error rate.

   Very interesting! I never thought of it that way. I was starting to think in
terms of number of errors in certain words relative to others ('1'-poor words,
in my current situation, are more robust), but I certainly didn't take that
thought as far as you have.

-- 
Brian Davis