From: email@example.com (john jardine)
Subject: Re: Designing a barcode reader
Date: 29 Sep 2002 09:19:28 -0700
NNTP-Posting-Date: 29 Sep 2002 16:19:28 GMT
"Dave VanHorn" wrote in message news:...
> I've never seen this, at least not to that degree.
> Were you working with physically large codes?
> I think the most I've seen has been about 25% within a couple chars, and
> that was when we were trying hard to get the effect.
> > The projects complexity is in the machine code, decoding algorithms.
> > There are about 5 patented decoding methods out there. They are
> > pretty much all the same and of course designed to be incomprehensible
> > to anyone reading them.
> :) Mine's just convoluted because I had to fit it into a kword.
The labels originally were about 2.5" by .5", high density '2 in 5
interleaved'. Stuck on a piece of plastic with neat but useless,
moulded, 'road humps' obstructing the landing and take off zones. This
resulted in a swipe having to accelerate from zero to a usable read
rate in about .25" of travel. Label was also stuck on a double curved
surface and had to be read down a trench, usually in sub zero
temperatures, clay, water, diesel fuel, using untrained, sometimes
gloved operators. (yes, totally OTT !)
We didn't realise how solid the algorithms were in the prototype HP
wand, until we needed to do it ourselves and took some stripe timings.
The 'speed profile' problem actually improved somewhat when the
moulding manufacturers started sticking smaller labels on but then
this brought its own hardware/software problems with the need for
greater, stripe width ratios, printing resolution and accuracy.
Barcode label decoding software sorts the men out from the boys. It
has a fixed job to do and must do it well with no excuses. It must, by
its very nature be raw, dirty, fast and effective. Machine code
normally rules the roost.
I left at the time the project was complete but the guys subsequently
got a (GB)patent applied, possibly patent, on their application and
Many of the nancy boy 'structured programmers' out there who
spend their time writing bloated, unreliable, business software using
infinitely fast PCs with infinite memory, would call in sick if they
had to do some real work like this. ;-)