Maker Pro
Maker Pro

Barcode Symbologies

D

D Yuniskis

Jan 1, 1970
0
Hi Walter,

Walter said:
UPC registration comes in two parts. A registered
part identifying the owner and a block of numbers
for the registered owner to use.

Yes, similar to OUI's, ISBN publishers, etc.
Barcodes can be made arbitrarily reliable and unique by
trading information space for reliability. Using a standard
transport layer and modest amount of validation of the
record layer can be very reliable. Changing barcode
format to an obscure format will not change the
overall reliability very much.

It doesn;t affect the reliability of the *scanning* (decoding).
But, can affect how likely you are to encounter a foreign
label (same symbology, etc.) and misrecognize it as one of
your own.
In a well implemented barcode system false positives
are rare.


In your proposal, some of the symbol space is translated
into the transportation layer. It is a tradoff but not a
significant one.

Again, I'm just creating simple identifiers. There is no
semantic content in the label. That all resides in a
database.

All the label needs to do is say:
- this is my identifier
- I *am* one of "your" labels and not something that simply
"looks" like one (at whatever level of detail)
The Dell barcodes are on the bottom of most laptops, most
are actually quite short. They have made the choice to scan
the appropriate label. Interesting enough the 6 or 7 character
service tag is still not likely to be miss read. It is has an alpha
numeric format with record type information built into the
order and range of the alphanumeric characters.

So they (Dell) have constrained their choice of "valid"
service tag identifiers. But that doesn't prevent me from
reading one of their service tags and interpreting it
as if it was one of *my* "identifier labels" (assuming
I adopted a seven character alphanumeric identifier in
the same symbology). Granted, the chances of hitting
a *particular* service tag are slim. But, depending on
how you create your (my) identifiers (does AAAABC come
before or after 123456?), you could bump into their
portion of that message space almost immediately (or not).
What you are trying to do is a common problem. Making
the barcode unreadable to most readers is one solution
but there are many other effective solutions most related
to either central registries or common transport layer
and symbols with individual record format.

False reads of the kind you describe almost never happens
in a real environment. Too many simultaneous failures
would need to happen. Barcode standards evolved in
order to prevent chaos of this type.

The standards for most codes don't prescribe anything about
their deployment. They just handle encoding data into a
particular format/symbology.

Most vendors have added a litany of odd "hacks" to allow you
to bend their scanner to *your* hacks (i.e., stripping
off fixed prefixes, etc.).

I think the "chaos" is typically averted simply by limiting
the types of labels encountered in a particular application
domain. I.e., I doubt any of the scanners on Dell;s
assembly line are configured to recognize 2-of-5 labels.
Likewise, I doubt any used in the supermarket are likely
to read Code 39 label. I.e., the nature of the business
tries to enforce (implicitly or explicitly) some discipline
on the labels encountered.

E.g., none of my Digikey parts ever carry a Codabar label
(though I imagine there might be some that carry a UPC
label)

So, you either tailor the solution to a particular
industry or application (e.g., MSI tends to be used
in inventory control) *or* come up with an approach
that can coexist with competing/interfering symbologies
and message formats (e.g., "YUNISKIS 12345 SIKSINUY")

I suspect if I make a 'reasonably good' *choice*
(i.e., not *design*) and put enough other aspects
into the overall "system" (e.g., "The labels
look like *this*"), then the real chances of problems
are minimal.

OTOH, if I just *pick* something and hope for the
best, Murphy will be waiting around the corner
with a SEG.
 
G

Grant

Jan 1, 1970
0
Only a few codes support the full range of ASCII characters (e.g.,
Code 128); others support an alphanumeric subset (Code 39, Code 93),
etc. I only need numeric identifiers so using one of these codes
doesn't buy me much. Though I could examine their encodings
and pick a subset of symbols -- not necessarily the numeric
digits -- to map to '0' thru '9' and possibly increase the Hamming
distance to buy me something (e.g., any label containing *any*
of the characters that I *don't* map to '0' thru '9' would be
known to be "foreign")

Also use a fairly long checksum, as too short a checksum may allow
false positives through.

Grant.
 
S

Steve Watt

Jan 1, 1970
0
tlbs101 said:
I need to pick a barcode symbology that is unlinkey to be
encountered in day-to-day items to minimize conflicts. E.g.,
UPC is non-starter. [ snip ]
But, I'd be open to other suggestions. [I can't roll my own
code as I want to use COTS scanners.]
Thanks!

Rather, the problem is ensuring that the scanner doesn't
"hit" on a label that isn't "mine".

This part's tough for COTS/surplus scanners. Admittedly, it's
been nearly 20 years since I looked around in the market, but
I couldn't find any back then that allowed suppression of the
scan acknowledge "beep". My solution was to find readers that
didn't have a beep and use the terminal[1]'s bell to signify a good
read.
So far, it seems like Codabar fits the bill in terms of
being recognizable by OTS scanners, rare enough that it is
unlikely to "pop up" out of pure coincidence *and* tweakable
enough that I can further minimize the chance of false positives
by "abusing" certain features of the code. :-/

Codabar is still pretty common. I'm staring at a Dell machine
with a M$ tax sticker on it that has two what look like Codabar
lines and a 2D line.

I seem to recall Codabar being very common in libraries, too.
I'll configure the scanner to tag the data with the code
used and parse that in addition to the data. I.e., if the
data isn't in the expected symbology, then it can't be
"one of my labels".

Back then, I chose code 39, and used an additional check
digit inside the regular scan path.

[1] Yes, I'm probably showing my age.
 
D

D Yuniskis

Jan 1, 1970
0
Hi Steve,

Steve said:
Rather, the problem is ensuring that the scanner doesn't
"hit" on a label that isn't "mine".

This part's tough for COTS/surplus scanners. Admittedly, it's
been nearly 20 years since I looked around in the market, but
I couldn't find any back then that allowed suppression of the
scan acknowledge "beep". My solution was to find readers that
didn't have a beep and use the terminal[1]'s bell to signify a good
read.

I've found some that will let you turn off the beep.
Some will even let you *drive* the beep (^G) with
an appropriate interface (i.e., duplex).

If push comes to shove, I can cut the leads to the
transducer (or pour epoxy on it so it can't flex
audibly enough :> ). But, having the beep *in*
the scanner is a real win (especially for the cordless
scanners) as it is "right there" with the user
(instead of at the other end of the cord)
Codabar is still pretty common. I'm staring at a Dell machine
with a M$ tax sticker on it that has two what look like Codabar
lines and a 2D line.

The Dells that I have use 7 character Code128 label for the service
tag, Code 128 on the motherboard, etc. Even the XP license sticker
is Code128 (two linear codes and a 2D code).

I have a little Symbol PDA (Palm III with barcode reader built
in) that has a handy little diagnostic application. Scan
a label and it tells you the label's contents as well as the
symbology used. Quite handy! :>
I seem to recall Codabar being very common in libraries, too.
Yes.


Back then, I chose code 39, and used an additional check
digit inside the regular scan path.

I think there's enough ways that I can "bend" the labels'
format and content that I should be able to drive the
probability of a "bogus read" into the mud. My biggest
fear is *picking* something (i.e., without careful
consideration) and discovering after-the-fact that
some supplier *also* uses that and there are conflicts
every 10 minutes! :< Especially after having tagged
everything! :-/
[1] Yes, I'm probably showing my age.

The fact that you said *bell* (instead of *beep*) gave
you away! (I think bells went away with the ASR33...)

;-)
 
V

VioletaPachydermata

Jan 1, 1970
0
No. I just don't want to end up "being unlucky" and *chosing*
a symbology/format that I later discover some vendor is using
to label their parts; or their shipping containers; or their
invoices; or...


Naw... that could never happen.

How could you possibly think that a STANDARD format would be unique in
your utilization of it?

As I stated before. UID. Who cares who and where it gets used? ALL
utilizations of it can be unique simply by your formatting of the data.

The reading can be set up such that only that unique data structure and
format gets read in, so "the vendor" with the same barcode would still
NOT upset or cause a failure mode with your utilization.

Pick one and use it, just use a unique data string composition.

Easy, greasy, Japanezee.
 
V

VioletaPachydermata

Jan 1, 1970
0
Field structures vary. Some have a <SN> 'field' followed by the actual
s/n in the form <1234567> So you would read out <SN><1234567> and your
computer would "see it" as something like 'comma separated ascii' or the
like and load up the fields in a spreadsheet or database just fine or you
could do it later and simply read it all into a single cell or field.

You can segregate fields in that manner (the odd
containment/segregation characters).
 
T

Tony

Jan 1, 1970
0
D said:
Hi Tony,


Yes, I was acknowledging this in my initial decision to
just stick to pure numeric identifiers (they are just
identifiers -- no need for them to have human readable
content). This gives me the most choices between symbologies.
Also *can* give me better character densities and/or
decoding reliability (by storing less data in a given
space *if* done properly).


Not sure I understand your application; did the "programmer"
then print a barcode label on the device? (which was
later read)

No the labels where all pre-printed and just unique, we could not do a
seperate server based system to support multiple test fixtures at the
time and CEMs can (nearly) always control bar codes to be unique. They
can also easily record and match stuff in a database. The labels
started with the fixed 3 digit customer code. The programmer read the
label and wrote a calculated code to the memory.
With a non contact scanner, you can usually do really good at
reader accuracy (and first pass read rate should be damn near
"six nines"). I've designed wand-type scanners that had to
hit 99% FPRR and 99% accuracy (which is tough because the
user can't be guaranteed to scan at a constant speed *and*
the range of speeds varies over two or more orders of
magnitude!)


OK, so you presumably chose those "valid" codes to maximize
their hamming distances?

No they were set/provided by another person. I just chose to use it in
the bar code to help ensure the factory didn't mix up labels or boards
in the process.
I can handle that in the system software. I.e., I can validate
any identifiers as "mine" by checking:
- symbology used (scanner can tell me this)
- message format (digits, preamble, check digit, etc.)
- "does the identifier exist in the database"?


Is this true of all scanners? I have found it to be the case
of the few that I have examined but haven't seen that as a
"guaranteed feature" (i.e., does The Industry require this
as a "basic feature" or is it an enhancement offered by many/all
scanner vendors?)

I couldn't say for sure, but I tend to assume most scanners can do this.
I've done it with an embedded scanner and a hand scanner (both <£100
each).
I also used bearer bars top and bottom to help reduce bad reads further.

Ah, good point! Though I would think that an examination of
the "read data" could give you this information, as well
(i.e., short read, bad check digit, etc.)

My problem will be making sure some *other* label isn't
accidentally scanned AS IF it was "mine". E.g., I chuckle
watching folks at the "self check-out" at the library
scanning their books and getting frustrated because the
system doesn't recognize the barcode (because they are
scanning the EAN code instead of the library's *specific*
"item number" label). Poorly designed system has the scanner
beeping even on bad scans (so folks who just listen for the
beep wonder why their receipt doesn't have all the items
listed on it!) as well as failing to inform the patron that
"you've scanned the wrong label" (since the system could
easily know that the scanner just saw an EAN label instead
of the library's specific label!)

[people who "assemble" systems from OTS subsystems often don't
think things through completely, IME]

You cannot eliminate the problem completely , but the using a fixed
number of digits and some fixed digits you can dramatically reduce the
probability. Although I have to say I've never tried to calculate it.
 
D

D Yuniskis

Jan 1, 1970
0
Hi Tony,
No the labels where all pre-printed and just unique, we could not do a

Ah, OK. I.e., "read the barcoded label" instead of trying to read
a serial number off a board, etc.
seperate server based system to support multiple test fixtures at the
time and CEMs can (nearly) always control bar codes to be unique. They
can also easily record and match stuff in a database. The labels
started with the fixed 3 digit customer code. The programmer read the
label and wrote a calculated code to the memory.

Understood. Sort of like "unlock codes" for software...
No they were set/provided by another person. I just chose to use it in
the bar code to help ensure the factory didn't mix up labels or boards
in the process.

Oh. So you just used "001", "002" and "003" out of 999 valid codes (?).
I couldn't say for sure, but I tend to assume most scanners can do this.
I've done it with an embedded scanner and a hand scanner (both <£100
each).

I'll see if I can find three or four "compatible" scanners
(compatible in terms of their feature sets). If all of them
have the feature, that gives me three "backup suppliers"
if one goes belly up.
I also used bearer bars top and bottom to help reduce bad reads further.

Ah, good point! Though I would think that an examination of
the "read data" could give you this information, as well
(i.e., short read, bad check digit, etc.)

My problem will be making sure some *other* label isn't
accidentally scanned AS IF it was "mine". E.g., I chuckle
watching folks at the "self check-out" at the library
scanning their books and getting frustrated because the
system doesn't recognize the barcode (because they are
scanning the EAN code instead of the library's *specific*
"item number" label). Poorly designed system has the scanner
beeping even on bad scans (so folks who just listen for the
beep wonder why their receipt doesn't have all the items
listed on it!) as well as failing to inform the patron that
"you've scanned the wrong label" (since the system could
easily know that the scanner just saw an EAN label instead
of the library's specific label!)

[people who "assemble" systems from OTS subsystems often don't
think things through completely, IME]

You cannot eliminate the problem completely , but the using a fixed
Correct.

number of digits and some fixed digits you can dramatically reduce the
probability. Although I have to say I've never tried to calculate it.

Therein lies the rub. I.e., you can calculate the chances of
a fuse blowing given a particular nominal load; you can calculate
the time it takes to respond to an interrupt event; etc. -- but
this sort of thing is really hard to quantify. All you can do is
try to make it "highly unlikely" that you'll have a conflict
in practice. And, design so that the only thing you need to
change are the *physical* labels if a conflict becomes commonplace.
 
J

JosephKK

Jan 1, 1970
0
Hi Tom,
I need to pick a barcode symbology that is unlinkey to be
encountered in day-to-day items to minimize conflicts. E.g.,
UPC is non-starter.
I only need 8 decimal digits so no need for the more complex
codes. I prefer a 2 dimensional code as it increases the
available choices for scanners. I'll probably add a few
digits for my own checksum (above and beyond whatever the
code itself supports). So, maybe 10-12 digits, total.
I suspect ABC Codabar is probably the most obscure (at
least the least likely to be encountered *on* something).
I can even get sneaky and print multipart labels to
be even *more* unique.
But, I'd be open to other suggestions. [I can't roll my own
code as I want to use COTS scanners.]
Thanks!
--don
I used code 93 on a military project, 16 years ago. 93 is linear,
not 2-D, but there were many scanners available at the time that we

Yes, 2D was a typo on my part (OTOH, a 2D code would be far
less likely to give a false positive owing to its relative
scarcity -- at least some of them)

<grin> I used Paradox for my first database. I've since moved
everything to PostgreSQL. Much more robust, capable and
extensible!
Or... just buy a scanner that supports multiple codes and let the
scanner figure it out.

The problem isn't the scanner -- as most scanners can be
configured to support a variety of codes.

Rather, the problem is ensuring that the scanner doesn't
"hit" on a label that isn't "mine".

I think you are barking up the wrong tree here, let the scanner spit out
lots of invalid for you codes and you sort them out. It is not like they
are spitting hundreds of codes per second. And use any 2D code, then
your subset acceptable code space can have huge Hamming distances. Plus
there is enough internal code space to put internal ECC in.
 
J

JosephKK

Jan 1, 1970
0
No. Just print using a laser printer. Print sheets of consecutive
labels. Peel label off, slap onto "whatever". Describe that
"whatever". Move on to the next label.

(there are some cases where you print a specific label but those
are exceptions -- old label was damaged, etc.)

Yep, and there are label printers for doing just that.
 
D

D Yuniskis

Jan 1, 1970
0
Hi Joseph,
Yep, and there are label printers for doing just that.

The problem with those is they allow you to print *any* label
"at will" (i.e., without the "system" being aware of the
label being issued).

They also tend to be thermal (dye transfer) so supplies are
more costly. (I've a pile of portable and small desktop
thermal label printers getting ready for the recycle bin)
As well as the hassle of recharging batteries, etc.

And, you need "another" general purpose printer to print
your "non barcode" items (i.e., now you have to stock
supplies for two different printers).

For non-contact scanners at reduced density, easier to
use a conventional printer to do that "double duty".
 
Top