Re: How big could a bar code be if a bar code could be big?

From: Karl Auerbach <karl_at_cavebear_dot_com>
Date: Fri Apr 30 2004 - 16:31:48 CDT

It's my sense that we need to move out of "the demo" thinking and begin
thinking of the first pilot system. And in such a system, I'm beginning
to become fairly convinced that the one-dimensional bar codes don't have
enough space to hold enough information.

Compression doesn't always compress - it's a gamble. Sometimes
compression actually results in more bits than the original.

> As discussed in this OCT thread, we added error detection code...

I haven't seen that in the code. I've seen range and value checks. But I
don't see anything that resembles a CRC or ECC.

(A Hamming ECC code would be a nice touch. Yes, many bar code formats
have built-in error correction, but having an additional layer could catch
errors in the encoding/decoding software routines. My own experience
testing networking software suggests that data encoding/decoding is a
place where many implementations have undetected flaws.)

In light of the potential of having the bar-code digitally signed - this
implies a message digest as part of the data represented by the bar code.
Such digests are typically at least 32 or 64 bits long. An ECC would, I
believe, be best applied as the outermost wrapper, i.e. done after and
appended after the message digest.

I see in the archives a note that the maximum reliable bar code length is
30 symbols - we are using 24 already. Each symbol gives about 6.5 bits of
information. So adding a message digest (32-bits) and ECC (8 bits?) means
about 7 more symbols - bringing us right up to, or even past, the maximum
and not leaving any room for bigger elections.


= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Fri Apr 30 23:17:28 2004

This archive was generated by hypermail 2.1.8 : Fri Apr 30 2004 - 23:17:29 CDT