On 15 Sep 97 at 0:55, Walter Banks wrote:
>
> First what type of barcode are you using?
>
> All barcodes have three things in common.
>   1) Calibration information
>   2) Clocking information
>   3) Data.
>
> Most barcode formats also use the size of
> the space between bars for some purpose.
>
> Many years ago Carl Helmers, Ralph Trueblood and I
> wrote a book on barcode technology. The book was titled
> "Contempory applications of barcode technology" It
> contained some simple barcode reader code. The code
> in the book was all written in Pascal and was designed
> to run on an Apple ][ (Did I say it was a while ago?)
>
> PIC's should not have any trouble reading hand wand
> code.

Indeed.  I wrote a decoder in basic on a z80 platform (CPM and a very
early MS Basic interpreter).  The easiest way is to sample the
photo-transistor return and store it into array, then got thru it
afterwords.  This has the advantage of allowing you to check for
differing bar-code standards. (and the disadvantage that you need a
fair bit of ram, and a start sampling indication)

>
> One assumption that is useful is to remember the
> fastest measured speed of a hand held wand was
> 42in/sec  (~1m/sec)

Reminds me of a fun party trick of mine (when I had a barcode
reader),  I'd take a 3mm permanent marker and draw barcodes by hand -
then scan them to prove their accuracy.  Trick is to remember to draw
them BIG.  Fairly easy for 3 of 9.  I wouldn't try EAN/UPC though.

Wonder why checkout operators in supermarkets seem to think that
scanning a rejected package faster will make it scan better?  This
applies to the EFTPOS magstripe readers too.  They give it a fast
swipe - it doesn't work - then swipe it at the speed of sound and
seem surprised when it still doesn't work.
MikeS
<mikesmith_oz@nosp*m.relaymail.net>
(remove the you know what before replying)