Maker Pro
Maker Pro

Barcode Symbologies

D

D Yuniskis

Jan 1, 1970
0
Hi,

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
 
D

D Yuniskis

Jan 1, 1970
0
Grrrr.... s/2/1/ <:-(
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.]

I dunno, lots of choices (checkout Code 11)

http://en.wikipedia.org/wiki/Bar_codes

Hmmm... never heard of Code 11! (and, apparently, most of the
OTS scanners haven't, either! :< )

Just from where I'm sitting, I see Codes 39, 128, EAN13, UPCA
and Codabar :)<). I'll have to take a wander through the warehouse
and see what other codes show up.

I suspect I am just going to have to rely on a large enough
Hamming distance in my symbols to make "coincidences" damn near
impossible (coupled with enforcing the "chosen" symbology).

I'll also have to check to see if I can configure any scanners
to pass "bad reads". One hack might be to deliberately munge
the check digit on a mainstream code so any labels with
*valid* codes I would recognize as "foreign" (?) (i.e., print
all of mine with a check digit guaranteed to be "wrong" -- yet
predictable)
 
D

D Yuniskis

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".

For (ridiculous) example, if I adopt UPC as the symbology, then
there will be lots of "false positives" that I'll have to
worry about as so many products carry UPC labels -- I can't
prevent UPC labels from being in the facility!

This is true of many symbologies. So, my question was to
try to identify a symbology that is so *infrequently* used
that it would be unlikely to "hit" on a label using that
symbology that wasn't placed there by *me*.

If I use a proprietary scanner and/or code, I can do this
quite well (design a code that is incompatible with existing
codes). But, that should be largely unnecessary if I exercise
care in choosing an appropriate symbology as "mine".

I can do this in certain special cases but not without
constraining the "grammar" that defines valid symbols too
much.

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. :-/

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".
 
D

D Yuniskis

Jan 1, 1970
0
Hi Paul,
D said:
1 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.

I only need 8 decimal digits so no need for the more complex
codes. I prefer a 2 dimensional code as it increases the
Grrrr.... s/2/1/ <:-(
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.]
I dunno, lots of choices (checkout Code 11)

http://en.wikipedia.org/wiki/Bar_codes
Hmmm... never heard of Code 11! (and, apparently, most of the
OTS scanners haven't, either! :< )

Just from where I'm sitting, I see Codes 39, 128, EAN13, UPCA
and Codabar :)<). I'll have to take a wander through the warehouse
and see what other codes show up.

I suspect I am just going to have to rely on a large enough
Hamming distance in my symbols to make "coincidences" damn near
impossible (coupled with enforcing the "chosen" symbology).

I'll also have to check to see if I can configure any scanners
to pass "bad reads". One hack might be to deliberately munge
the check digit on a mainstream code so any labels with
*valid* codes I would recognize as "foreign" (?) (i.e., print
all of mine with a check digit guaranteed to be "wrong" -- yet
predictable)

Don't depend on some strange symbology to prevent collisions with other
bar codes. As the readers get smarter, I've found it difficult to find
one that won't read some arcane code, or multiple codes simultaneously.

I understand that. The scanners I have been looking at allow you
to configure the scanner to accept (or ignore) different symbologies.
I plan, in some cases, on enabling *other* symbologies as well
(and configuring the scanner to tag the decoded label with an
indication of the symbology that it applied). I am more concerned
with encountering *labels* in "some symbology" that I am hoping
to make unique to my application (in the particular application
domain -- i.e., don't use UPC if you are operating in a grocery
store!)
You could tack on an application specific fixed preamble to your code
string, calculate and append a CRC and then throw away the preamble.
Upon scanning, prepending the preamble would enable the CRC check to
pass.

Yes, that was my initial plan. Relying *solely* on that, however,
leaves you open to "collisions" with other "unrelated labels"
in that same symbology -- UNLESS YOU CAN GUARANTEE THAT YOUR
LABELS WILL BE "INVALID" (violate some "given") WRT THOSE
OTHER "valid" labels.

E.g., *use* UPC in a grocery store *but* deliberately print
an incorrect check digit (9's complement) in all of *your*
labels. This, however, relies on being able to configure
the scanner to give you "bad read" data (so you can examine
the "bad" check digit and verify that it is actually *correct*
for your "scheme")

Or, putting a 14 digit code in a UPC format, etc. (again, this
risks being rejecteed outright by the scanner :< )

The cleanest approach is just to pick a symbology that isn't
likely to be encountered in that application environment and
"further improve your odds" by forcing the label's contents
to fit some other presecription(s) regarding format. E.g.,
some CRC *within* the body of the label (that gets treated by
the scanner as "in band" data).
If you really have some bar code real estate (a 2D code), you could
encode an entire message, pass it through a public key signing
application and print the plain text message with its signature on the
label. The reading app could check the signature block against the
private key before validating it as a correct label. This is tin-foil
hat paranoia, of course.

I think just *thinking* about the types of labels likely to
"coincidentally" be encountered and picking something "highly
unlikely" -- coupled with imposing a structure on the
label's contents -- has got to be "six 9's" :> (hence the
reason for suggesting ABC Codabar)

(note there are always semantic checks that can be applied
after a label is "accepted" so the chances are probably
off the scale)
 
P

Paul Carpenter

Jan 1, 1970
0

Be careful what you pick is not the domain of just one industry that then
changes. E.G. UPC gets replaced with UPC-2012, everyone stops supporting
UPC, because no one uses it and later replacement scanners do not work.
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)
....
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". .....

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. :-/

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".

Be careful you don't end up with a system that is effectively
requiring Code 11 and no newer scanners support it.

Also be sure that the code being used is not one that is used by
so few people that any bugs in code detection are unlikely to
be fixed by scanner manufacturers.

--
Paul Carpenter | [email protected]
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate
 
V

VioletaPachydermata

Jan 1, 1970
0
Hi Paul,
D said:
1 Lucky Texan wrote:
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
Grrrr.... s/2/1/ <:-(

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.]
I dunno, lots of choices (checkout Code 11)

http://en.wikipedia.org/wiki/Bar_codes
Hmmm... never heard of Code 11! (and, apparently, most of the
OTS scanners haven't, either! :< )

Just from where I'm sitting, I see Codes 39, 128, EAN13, UPCA
and Codabar :)<). I'll have to take a wander through the warehouse
and see what other codes show up.

I suspect I am just going to have to rely on a large enough
Hamming distance in my symbols to make "coincidences" damn near
impossible (coupled with enforcing the "chosen" symbology).

I'll also have to check to see if I can configure any scanners
to pass "bad reads". One hack might be to deliberately munge
the check digit on a mainstream code so any labels with
*valid* codes I would recognize as "foreign" (?) (i.e., print
all of mine with a check digit guaranteed to be "wrong" -- yet
predictable)

Don't depend on some strange symbology to prevent collisions with other
bar codes. As the readers get smarter, I've found it difficult to find
one that won't read some arcane code, or multiple codes simultaneously.

I understand that. The scanners I have been looking at allow you
to configure the scanner to accept (or ignore) different symbologies.
I plan, in some cases, on enabling *other* symbologies as well
(and configuring the scanner to tag the decoded label with an
indication of the symbology that it applied). I am more concerned
with encountering *labels* in "some symbology" that I am hoping
to make unique to my application (in the particular application
domain -- i.e., don't use UPC if you are operating in a grocery
store!)
You could tack on an application specific fixed preamble to your code
string, calculate and append a CRC and then throw away the preamble.
Upon scanning, prepending the preamble would enable the CRC check to
pass.

Yes, that was my initial plan. Relying *solely* on that, however,
leaves you open to "collisions" with other "unrelated labels"
in that same symbology -- UNLESS YOU CAN GUARANTEE THAT YOUR
LABELS WILL BE "INVALID" (violate some "given") WRT THOSE
OTHER "valid" labels.

E.g., *use* UPC in a grocery store *but* deliberately print
an incorrect check digit (9's complement) in all of *your*
labels. This, however, relies on being able to configure
the scanner to give you "bad read" data (so you can examine
the "bad" check digit and verify that it is actually *correct*
for your "scheme")

Or, putting a 14 digit code in a UPC format, etc. (again, this
risks being rejecteed outright by the scanner :< )

The cleanest approach is just to pick a symbology that isn't
likely to be encountered in that application environment and
"further improve your odds" by forcing the label's contents
to fit some other presecription(s) regarding format. E.g.,
some CRC *within* the body of the label (that gets treated by
the scanner as "in band" data).
If you really have some bar code real estate (a 2D code), you could
encode an entire message, pass it through a public key signing
application and print the plain text message with its signature on the
label. The reading app could check the signature block against the
private key before validating it as a correct label. This is tin-foil
hat paranoia, of course.

I think just *thinking* about the types of labels likely to
"coincidentally" be encountered and picking something "highly
unlikely" -- coupled with imposing a structure on the
label's contents -- has got to be "six 9's" :> (hence the
reason for suggesting ABC Codabar)

(note there are always semantic checks that can be applied
after a label is "accepted" so the chances are probably
off the scale)


Easy answer. UID. Make the select/reject criteria the structure of
your data string(s), not the format you store it with.

That way a read of a similar code would still get rejected by your
inventory control software due to having an incorrect data structure.

Only proper 'good' codes get accepted by your read software.
 
V

VioletaPachydermata

Jan 1, 1970
0
<grin> I used Paradox for my first database. I've since moved
everything to PostgreSQL. Much more robust, capable and
extensible!

Paradox was cool. Still would be were it still around.
 
D

D Yuniskis

Jan 1, 1970
0
Hi Robert,

Use the inverse of the correct check code..aka check bar (pun intended).

Yes, as I mentioned elsewhere: "9's complement"
But, this means I need to be able to get the scanner to
pass "bad data" to the application (many scanners would
just flag this as a bad read and you wouldn't see the
data at all).
 
W

Walter Banks

Jan 1, 1970
0
D said:
Hi,

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.]

Barcode protocols are composed of a transport layer and
data record complete with validation. UPC scanners
in a supermarket for example will reject UPC product
codes that it can not recognize. UPC code groups are
registered.

If I was doing this I would probably use a common
barcode format like code39 and encrypt the data
and add error detection/correction for your application.
The reason is it is well developed and would work
reliably. Code39 specifically can be easily printed
on adhesive labels.


Regards,


Walter..
 
D

D Yuniskis

Jan 1, 1970
0
1 said:
Just as an aside, there's an app for the iphone that will read several
2d codes including the color one (microsoft?).

I think using an uncommon symbology with a custom character imbedded
is a good approach. Perhaps use an odd ascii escape code, greek
charater or alt255 or?

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")
 
D

D Yuniskis

Jan 1, 1970
0
Hi Walter,

Walter 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.

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.]

Barcode protocols are composed of a transport layer and
data record complete with validation. UPC scanners
in a supermarket for example will reject UPC product
codes that it can not recognize. UPC code groups are
registered.

Yes, but handheld scanners just recognize valid "encodings".
I.e., they don't examine the content of the message/label
to determine if the "product exists". E.g., the validity
of a UPC label for the "local" group can't be validated
a priori.

(UPC is a bad choice, for me, as you can find UPC labels too
commonly -- too hard to minimize the risk of a false positive)
If I was doing this I would probably use a common
barcode format like code39 and encrypt the data
and add error detection/correction for your application.
The reason is it is well developed and would work
reliably. Code39 specifically can be easily printed
on adhesive labels.

Code 39 is also widely used and runs the same risk as
UPC -- only different. :> It seems like Code 128, 39
and UPC are the biggest offenders in terms of risk of
conflict. And, since they are all free-form codes
(unconstrained content), there's no way of *reliably*
guaranteeing that some "foreign" label won't conflict
with my "identifier space".

I don't want folks to have to take on the added
responsibility of "scribbling out" (or over-spraying)
any preexisting labels on packaging, merchandise, etc.
Likewise, I want a simple rule: "If you're trying to
scan a label and the system doesn't recognize it, you're
scanning the *wrong* label -- keep looking :> "

(i.e., high first pass read rate, low error rate)
 
W

Walter Banks

Jan 1, 1970
0
D said:
Hi Walter,



Yes, but handheld scanners just recognize valid "encodings".
I.e., they don't examine the content of the message/label
to determine if the "product exists". E.g., the validity
of a UPC label for the "local" group can't be validated
a priori.

(UPC is a bad choice, for me, as you can find UPC labels too
commonly -- too hard to minimize the risk of a false positive)

Code39 is a transport layer of a limited symbol set. A barcode
record is the actual message consisting of symbol characters that
has meaning. A generic barcode reader will read the transport
characters relatively reliably but without additional programming
will not validate the record read or interpret the information.

Code 39 is also widely used and runs the same risk as
UPC -- only different. :> It seems like Code 128, 39
and UPC are the biggest offenders in terms of risk of
conflict. And, since they are all free-form codes
(unconstrained content), there's no way of *reliably*
guaranteeing that some "foreign" label won't conflict
with my "identifier space".

It is actually unlikely the a foreign labile will conflict
with your identifier space. UPC is the classic case
user register the part *their* barcode that makes their
case unique.

http://www.abblabels.com/Products/html/UPCBarcodeLabels.htm

Think is the UPC registration for example as a preamble
followed by the actual information. The registration
has the added advantage of making available the
owner information available to most people using UPC
reader equipment. Registration makes your UPC record unique

This process make false positives very rare.

Code39 does not have the same registration process. In
most of the applications using Code39 record format
and check characters are sufficient to prevent undetected
errors.

For example creating a Code 39 barcode record for
you application might have

*DJ1234567855*

would be a Code39 labile about 1.5" long with
DJ to identify it as yours
8 Data digits
55 two check digits.

All records records you are interested would start with
DJ. Since the text is usually printed in the label as well
there would be a limited ability for false positives.



Regards,


Walter..
 
T

Tony

Jan 1, 1970
0
Walter said:
D said:
Hi,

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.]

Barcode protocols are composed of a transport layer and
data record complete with validation. UPC scanners
in a supermarket for example will reject UPC product
codes that it can not recognize. UPC code groups are
registered.

If I was doing this I would probably use a common
barcode format like code39 and encrypt the data
and add error detection/correction for your application.
The reason is it is well developed and would work
reliably. Code39 specifically can be easily printed
on adhesive labels.

Code 39 is very wasteful as it covers ascii, ITF (interleave 2 of 5)
would be more efficent space wise (if that is important to you)for
decimal only. More space = more characters and fixed digits.

I used this for a encryption system that needed to be programmed with
unique number and readable later on in the process. False reads were
important, although the reader was built into a test fixture. I also
used 3 (fixed) digits for a customer code, of which there were only 3 or
4 customers. The test fixture was set for the appropriate customer at
the start of a shift, non matches where rejected.

The fixed parts help reduce the possibility of a false hit and You can
further reduce your chances of a false read by fixing the number of
digits in the code. Most scanner can be programmed for this. They can
also be programmed whether there the last digit is a check digit or not,
and whether to transmit this.

I also used bearer bars top and bottom to help reduce bad reads further.
 
D

D Yuniskis

Jan 1, 1970
0
Hi Walter,

Walter said:
Code39 is a transport layer of a limited symbol set. A barcode
record is the actual message consisting of symbol characters that
has meaning. A generic barcode reader will read the transport
characters relatively reliably but without additional programming
will not validate the record read or interpret the information.

The scanner will ensure the label adheres to the requirements
of the symbology (i.e., proper bar/space ratios, proper
check digit, adequate whitespace bracketing the label).
Beyond that, the "content" of the label is "application
specific".
It is actually unlikely the a foreign labile will conflict
with your identifier space. UPC is the classic case
user register the part *their* barcode that makes their
case unique.

http://www.abblabels.com/Products/html/UPCBarcodeLabels.htm

Yes, but *I* can opt to use UPC encoding to represent my
data. Doing so suggests that, sooner or later, I will
encounter an item with a "real" UPC barcode printed on it
that my "system" will mistakenly take as "one of my own".
I.e., a box of Cheerios coincidentally has thet same
"identifier" (encoded into the body of the UPC label)
as my "Capacitor, Electrolytic, 25uF, 16WVDC, radial".
(the *scanner* can't tell that it's a box of cheerios!)
Think is the UPC registration for example as a preamble
followed by the actual information. The registration
has the added advantage of making available the
owner information available to most people using UPC
reader equipment. Registration makes your UPC record unique

This process make false positives very rare.

Only rare for folks who are part of that "registered identifier
space". Sort of like OUI's -- I can program *any* MAC into
my NIC. But, there is no guarantee that I won't end up
programming a MAC that isn't already in use, somewhere
(belonging to some other organization).

This is the problem I am trying to anticipate and avoid.
Code39 does not have the same registration process. In
most of the applications using Code39 record format
and check characters are sufficient to prevent undetected
errors.

For example creating a Code 39 barcode record for
you application might have

*DJ1234567855*

would be a Code39 labile about 1.5" long with
DJ to identify it as yours
8 Data digits
55 two check digits.

All records records you are interested would start with
DJ. Since the text is usually printed in the label as well
there would be a limited ability for false positives.

Yes, this was my point about adding extra digits (I'm
avoiding other characters simply because those other
characters restrict you to using a smaller set of
symbologies). But, you can't *know* (for sure) what
"message/label formats" other people may use. I.e.,
tomorrow, you may start doing business with a company who
labels *all* of their products with "DJ" numbers. :-/
(the longer the 'preface' or other "unique-ifying" data,
the less the chance of random conflict ... "YUNISKIS"
might be a suitably unique choice for a prefix! :> )

For example, Dell uses 6 character identifiers for their
"service tags". What are the chances that using a similar
format would result in eventually coming up with a "hit"
that was unintended? I wonder how many Code 128 labels
have "SN" (Serial Number) as their first two characters?

I am, instead, looking to pick a symbology that is less
likely to be encountered. *Or*, bend the rules regarding
*my* choices of symbols such that "everyone else's"
look invalid to me. I.e., you're advocating making them
look invalid by relying on "DJ" to make them unique;
I'm thinking, instead, of violating some inherent
aspect of the label format -- check digit -- that they
*wouldn't*... because they would want the scanner to
do the check digit verification *for* them whereas I
am willing to take on that task myself -- using a different
"scheme".

For example, using multipart Codabar labels (*very* uncommon)
but printing them as "single part" labels.
 
D

D Yuniskis

Jan 1, 1970
0
Hi Tony,
Code 39 is very wasteful as it covers ascii, ITF (interleave 2 of 5)
would be more efficent space wise (if that is important to you)for
decimal only. More space = more characters and fixed digits.

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).
I used this for a encryption system that needed to be programmed with
unique number and readable later on in the process. False reads were

Not sure I understand your application; did the "programmer"
then print a barcode label on the device? (which was
later read)
important, although the reader was built into a test fixture. I also

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!)
used 3 (fixed) digits for a customer code, of which there were only 3 or

OK, so you presumably chose those "valid" codes to maximize
their hamming distances?
4 customers. The test fixture was set for the appropriate customer at
the start of a shift, non matches where rejected.

The fixed parts help reduce the possibility of a false hit and You can
further reduce your chances of a false read by fixing the number of
digits in the code. Most scanner can be programmed for this. They can

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"?
also be programmed whether there the last digit is a check digit or not,
and whether to transmit this.

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 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]
 
W

Walter Banks

Jan 1, 1970
0
D said:
Hi Walter,



Yes, but *I* can opt to use UPC encoding to represent my
data. Doing so suggests that, sooner or later, I will
encounter an item with a "real" UPC barcode printed on it
that my "system" will mistakenly take as "one of my own".
I.e., a box of Cheerios coincidentally has thet same
"identifier" (encoded into the body of the UPC label)
as my "Capacitor, Electrolytic, 25uF, 16WVDC, radial".
(the *scanner* can't tell that it's a box of cheerios!)

You can also opt to use UPC register and never mistake a
cap for a box of cheerios.
Only rare for folks who are part of that "registered identifier
space".

In the UPC cas that is essentially all users are registered. The
registration cost is very low to encourage participation, the
benefits are data security and rare false positives The standard
UPC record checking will weed out essentially all the rest
of the unregistered UPC images..

UPC was developed to eliminate the problem that you
have been describing. A bunch of years ago the barcode
industry was filled with many different transport layers
and data formats most with a unique application area.
The only security was each company creating their
own encoding and data and record formats.

Sort of like OUI's -- I can program *any* MAC into
my NIC. But, there is no guarantee that I won't end up
programming a MAC that isn't already in use, somewhere
(belonging to some other organization).

This is the problem I am trying to anticipate and avoid.


Yes, this was my point about adding extra digits (I'm
avoiding other characters simply because those other
characters restrict you to using a smaller set of
symbologies). But, you can't *know* (for sure) what
"message/label formats" other people may use. I.e.,
tomorrow, you may start doing business with a company who
labels *all* of their products with "DJ" numbers. :-/
(the longer the 'preface' or other "unique-ifying" data,
the less the chance of random conflict ... "YUNISKIS"
might be a suitably unique choice for a prefix! :> )

False positives are rare, once format, validation and context
are accounted for. For example, the automotive industry
has literally hundreds of suppliers using two or three
standard barcode encodings and don't have a problem
with false positives because of this.
For example, Dell uses 6 character identifiers for their
"service tags". What are the chances that using a similar
format would result in eventually coming up with a "hit"
that was unintended?

Actual Dell now uses a 7 character identifier for service
tags. However you just identified an important point
on identifying barcode, context. Dell uses several barcodes
on the bottom of there laptops top identify product,
manufacturer software licences and service tags.

I wonder how many Code 128 labels
have "SN" (Serial Number) as their first two characters?

Probably quite a few and a lot more Code39. Fewer
using the same field format for the actual serial number
fields which encode manufacture data, product id and
actual identifying number.
I am, instead, looking to pick a symbology that is less
likely to be encountered. *Or*, bend the rules regarding
*my* choices of symbols such that "everyone else's"
look invalid to me. I.e., you're advocating making them
look invalid by relying on "DJ" to make them unique;
I'm thinking, instead, of violating some inherent
aspect of the label format -- check digit -- that they
*wouldn't*... because they would want the scanner to
do the check digit verification *for* them whereas I
am willing to take on that task myself -- using a different
"scheme".

Barcode formats are implemented in layers. Additional
checking in some cases is important. Do it. I am not
sure what you application is? Describing the application
may identify or reject some of the standard solutions.


Regards,


Walter..
 
D

D Yuniskis

Jan 1, 1970
0
Hi Walter,

Walter Banks wrote:

[attributions elided]
You can also opt to use UPC register and never mistake a
cap for a box of cheerios.

But that requires the person operating the register to
be aware of the distinction (pick something other
than caps and cheerios and repeat the exercise)
In the UPC cas that is essentially all users are registered. The
registration cost is very low to encourage participation, the
benefits are data security and rare false positives The standard
UPC record checking will weed out essentially all the rest
of the unregistered UPC images..

UPC was developed to eliminate the problem that you
have been describing. A bunch of years ago the barcode
industry was filled with many different transport layers
and data formats most with a unique application area.
The only security was each company creating their
own encoding and data and record formats.

Exactly. Because the entire namespace ("message space"?)
was available to all users. Imagine if anyone could make up
any FQDN and tried to operate in the presence of other
folks (sharing a namespace).

The problem with the UPC route is it would cause you to use
up huge blocks of numbers needlessly. E.g., imagine if
UPS/FedEx used UPC labels as their "package identifiers".
These are essentially disposable identifiers yet putting
them into a shared/administered namespace would waste
big pieces of that namespace needlessly.
False positives are rare, once format, validation and context

Only if you can pick a unique combination of the above!
Doing this blindly has no guarantees. As I said, if I
arbitrarily picked a 6 character Code 128 identifier
and used that, eventually I *will* scan a label on a Dell
PC and find a coincidental match with some other object
in my database. Granted, you can recover from this.
But, it is a problem that need not happen if I had picked
some other scheme.
are accounted for. For example, the automotive industry
has literally hundreds of suppliers using two or three
standard barcode encodings and don't have a problem
with false positives because of this.

But I imagine they:
- don't let items come into their receiving dock without
rigidly defining how they are labeled; or
- instruct their staff to obscure any other barcodes
that may be on the packaging/items; or
- instruct their staff in *which* barcode is the "correct"
barcode to scan
- etc.

I.e., they can't just scan a barcode -- ANY BARCODE IN THE
BUILDING -- and be assured that it is *the* barcode that they
wanted to scan.

(they are also big enough to be able to enforce their wishes
on their suppliers -- "you will label your parts in this
fashion")

I can work around *some* problem areas by visual cues in
the labels. E.g., location identifiers are affixed to
blue plastic placards so a user "knows" this is a location
identifier and doesn't have to go hunting for it. But,
the software can't tell that the data scanned came from
a "blue plastic placard".
Actual Dell now uses a 7 character identifier for service

I stand corrected. I was looking at a license tag. <:)
tags. However you just identified an important point
on identifying barcode, context. Dell uses several barcodes
on the bottom of there laptops top identify product,
manufacturer software licences and service tags.

Yes. So you either have to know which barcode to scan
or have to encode information in the label that lets
the system figure out which label you've scanned and
prompt you to scan some other (if it is awaiting some
specific piece of information).

I want to be able to have a label scanned and be able
to tell the user authoritatively that it is the "right"
label to scan and/or the right label 9item) he is looking
for.
Probably quite a few and a lot more Code39. Fewer
using the same field format for the actual serial number
fields which encode manufacture data, product id and
actual identifying number.

But 123-45-5678 from Dell means something different from
12-34-556-78 from T.I. (bogus examples). I.e. the
namespace (messagespace) isn't standardized. I suspect
folks like Dell make this work by having *lengthy* labels,
possibly with large hamming distances or lots of enforced
redundancy -- and by controlling the items that can
get "on the floor" *with* "foreign labels".
Barcode formats are implemented in layers. Additional
checking in some cases is important. Do it. I am not

I intend to. Beginning with verification of the symbology
used in each scanned label.
sure what you application is? Describing the application
may identify or reject some of the standard solutions.

Loosely speaking, inventory tracking. But, using the labels
throughout -- to identify parts, to identify stock locations,
to identify shipping manifests, to identify the individuals
picking/packaging/shipping the items, etc. Their just
manifestations of "universal identifiers". I just want to
minimize the chance of some *other* (foreign) label being
erroneously interpreted as "one of mine" and having the
process stop while folks sort out why the item the item they
seek isn't in "this" location ("Oh, you scanned a barcode
that *Digikey* had applied to a component; *not* the little
blue plastic placard that we use to identify locations!")

The Average Joe isn't going to understand the nuances
of "barcodology" :-/
 
W

Walter Banks

Jan 1, 1970
0
D said:
The problem with the UPC route is it would cause you to use
up huge blocks of numbers needlessly. E.g., imagine if
UPS/FedEx used UPC labels as their "package identifiers".
These are essentially disposable identifiers yet putting
them into a shared/administered namespace would waste
big pieces of that namespace needlessly.

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

Only if you can pick a unique combination of the above!
Doing this blindly has no guarantees. As I said, if I
arbitrarily picked a 6 character Code 128 identifier
and used that, eventually I *will* scan a label on a Dell
PC and find a coincidental match with some other object
in my database. Granted, you can recover from this.
But, it is a problem that need not happen if I had picked
some other scheme.

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.

In a well implemented barcode system false positives
are rare.
Yes. So you either have to know which barcode to scan
or have to encode information in the label that lets
the system figure out which label you've scanned and
prompt you to scan some other (if it is awaiting some
specific piece of information).

I want to be able to have a label scanned and be able
to tell the user authoritatively that it is the "right"
label to scan and/or the right label 9item) he is looking
for.

In your proposal, some of the symbol space is translated
into the transportation layer. It is a tradoff but not a
significant one.
But 123-45-5678 from Dell means something different from
12-34-556-78 from T.I. (bogus examples). I.e. the
namespace (messagespace) isn't standardized. I suspect
folks like Dell make this work by having *lengthy* labels,
possibly with large hamming distances or lots of enforced
redundancy -- and by controlling the items that can
get "on the floor" *with* "foreign labels".

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.

Loosely speaking, inventory tracking. But, using the labels
throughout -- to identify parts, to identify stock locations,
to identify shipping manifests, to identify the individuals
picking/packaging/shipping the items, etc. Their just
manifestations of "universal identifiers". I just want to
minimize the chance of some *other* (foreign) label being
erroneously interpreted as "one of mine" and having the
process stop while folks sort out why the item the item they
seek isn't in "this" location ("Oh, you scanned a barcode
that *Digikey* had applied to a component; *not* the little
blue plastic placard that we use to identify locations!")

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.


Regards,


Walter..
 
D

D Yuniskis

Jan 1, 1970
0
1 said:
If it is extremely important to decrease the odds of scanning a false

-----------^^^^^^^^^

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...

(labels are physical items so changes can be expensive)
positive, perhaps there could be special lighting or filters used.
maybe a UV illuminated label or a specific color/special inks?

this may be overkill as capacity - but might be easily recognized as
the 'correct' label due to color;
http://en.wikipedia.org/wiki/High_Capacity_Color_Barcode

I suspect readers are expensive. And, if it is unique today,
will it be tomorrow? (I suspect that particular code will
go away -- too expensive to produce and scan when compared to
other monochromatic 2D codes)
 
Top