D
D Yuniskis
- Jan 1, 1970
- 0
Hi Walter,
Yes, similar to OUI's, ISBN publishers, etc.
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.
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)
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).
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.
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.