Searching \ for 'Barcode and the PIC [OT]' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Barcode and the PIC [OT]'.

Truncated match.
PICList Thread
'Barcode and the PIC [OT]'
1997\09\15@024139 by mikesmith_oz.nosp*m

flavicon
face
On 15 Sep 97 at 0:55, Walter Banks wrote:
{Quote hidden}

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)

1997\09\15@160624 by Harold Hallikainen

picon face
       Not quite bar code... but I did something similar quite a while
back in 6800 assembly.  I had a tape drive (from Exatron, I think).  I
used a bar code sort of technique to store data on it.  A short time
between transitions was a mark, a long time was a space.  I then just put
down standard 8 bit asynchronous data.  This was a replacement for the
then standard Bell 202 tones on audio cassette.  On playback, there was
some leading mark codes, then the data.  The software determined had a
period of time it would use to determine whether the incoming pulse was a
mark or a space.  Once the pulse was in the appropriate "bin" and the
appropriate one or zero output, the pulse duration was used to help
determine the tape speed and adjust the transition time between mark and
space.
       Someone else has suggested capturing the barcode to RAM, then
figuring it out, instead of trying to do it on the fly.  It was pointed
out that this could take a bit of RAM.  One way to minimize the amount of
RAM would be to just store the amount of time since the last barcode
edge.  These times could then be analyzed after the scan.

Harold

1997\09\16@005406 by mikesmith_oz.nosp*m

flavicon
face
On 15 Sep 97 at 16:04, Harold Hallikainen wrote:

> On Mon, 15 Sep 1997 05:56:22 -0400 Kahn-Syd <spam_OUTklassTakeThisOuTspamSUN-LINK.COM>
> writes:
> > What Kind of barcode am I decoding - (The easiest to decode ?- sorry
> >;-)
> >well I have already found a 3 of 9 bar code freeware font on the net
> >and
> >that seemed to solve one part - getting the stickers for the books.
> >unless
> >you suggest something otherwise.  they have nothing now and I could
> >use
> >anything.
>
>
>         Lots of books already have a bar code on the back cover.
>         One
> that I just looked at SEEMS to be related to the ISBN number... but
> is not it exactly.  Might be nice to use the existing numbering
> system and bar codes, though this would not allow you to keep track
> of individual copies of duplicate sets.

Which is the dilemma between selling multiple quantities of an
identical item, and using the barcode as a asset number.  Since ppl
don't need to remember barcodes, why not add an extra, say, 128 bits
at the manufacture stage, starting at 0 for every unique product.
You wouldn't need to store the entire number, hashing it with the
unique product number would do...
MikeS
<mikesmith_oz@nosp*m.relaymail.net>
(remove the you know what before replying)

1997\09\16@005817 by mikesmith_oz.nosp*m

flavicon
face
On 15 Sep 97 at 16:04, Harold Hallikainen wrote:

>         Someone else has suggested capturing the barcode to RAM,
>         then
> figuring it out, instead of trying to do it on the fly.  It was
> pointed out that this could take a bit of RAM.  One way to minimize
> the amount of RAM would be to just store the amount of time since
> the last barcode edge.  These times could then be analyzed after the
> scan.

Another variation I thought of - use an ISR to store incoming data
into a circular buffer, and decode it in the main program...
MikeS
<mikesmith_oz@nosp*m.relaymail.net>
(remove the you know what before replying)

1997\09\16@095712 by Walter Banks

picon face
Mike Smith wrote:

> Which is the dilemma between selling multiple quantities of an
> identical item, and using the bar-code as a asset number.  Since ppl
> don't need to remember barcodes, why not add an extra, say, 128 bits
> at the manufacture stage, starting at 0 for every unique product.
> You wouldn't need to store the entire number, hashing it with the
> unique product number would do...

UPC effectively is what you just suggested. UPC is a quite a secure
bar-code method (Very difficult to get a wrong valid answer) It is a
well thought out industry driven standard. A lot of thought was put
into the kind of things that would be sold vs. the kind of things
that would be inventoried.

Library books are typical of one type
of inventory with multiple copies that each has to be handled
separately. Mr. Jones has a copy of the book that is overdue but
Mr. Smith is not overdue until next week. And the book's author
is Doe, J. W. and library has three copies two are currently out
the third is on the second floor. This problem has often been
solved in libraries using CODE39 with a unique number on each
book. Since CODE39 is a character oriented bar-code a inventory
number is machine generated which includes a check digit often
either a checksum or credit card type modulus. Libraries solve
the multiple use (whose got and what is it) is solved in a
very library fashion of many different cross indexes on the
inventory data base.

I2of5 is generally used as an inventory control where we
control what is in the inventory and we may three of an item
and we cannot tell the difference and don't care. Each item
type has a different number. The system has a master index.
An example is an automotive plant parts index. If you live
in North America the stickers on a new car are Iof5.

UPC is another inventory control type code that has a the
problem of being printed by many different printers and
on products that don't really like to be bar-coded. To
name three of the common problems, pop bottles where you
have white on black when the bottle is full and white on
clear when it is empty (or upside down). This code was
designed to be read with bars of both lighter or darker
contrast in the same context. It was designed to be read
in both directions with equal ease. The two remaining
problems are the ice-cream container very cold on a hot
day covered with frost and the un-frozen frozen vegetables.

UPC is an inventory control system where the supplier is
important and local product inventory pricing is important.
The supplier and general product area can be identified from
the code on a product. This information is useful in tracking
down information on a uninventoried product. There is enough
information to maintain a local inventory. UPC is compact
with good checking capability and easy to read in very bad
conditions. UPC is an industry controlled standard.

Walter Banks
http://www.bytecraft.com

More... (looser matching)
- Last day of these posts
- In 1997 , 1998 only
- Today
- New search...