Barcode Symbologies
D Yuniskis
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
1 Lucky Texan
D Yuniskis
> On May 24, 10:36 am, D Yuniskis <not.going.to...@seen.com> 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)
tlbs101
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
(the team) could use. The database was written in FoxPro (not my
choice -- lol).
Tom Pounds
tlbs101
>
> - Show quoted text -
Or... just buy a scanner that supports multiple codes and let the
scanner figure it out.
Tom
D Yuniskis
tlbs101 wrote:
> On May 24, 3:06 pm, tlbs101 <tlbs...@excite.com> wrote:
>> On May 24, 9:36 am, D Yuniskis <not.going.to...@seen.com> 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
>>> 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)
>> (the team) could use. The database was written in FoxPro (not my
>> choice -- lol).
<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".
Greegor
Gonna use a Zebra printer?
http://www.zebra.com/id/zebra/na/en/index/products/printers/industrial_commercial/zm400.html
D Yuniskis
>> 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".
>
> Gonna use a Zebra printer?
>
> http://www.zebra.com/id/zebra/na/en/index/products/printers/industrial_commercial/zm400.html
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.)
Paul Hovnanian P.E.
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.
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.
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.
--
Paul Hovnanian mailto:Pa...@Hovnanian.com
------------------------------------------------------------------
A vacuum is a hell of a lot better than some of the stuff that nature
replaces it with. -- Tennessee Williams
D Yuniskis
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)
1 Lucky Texan
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?
Robert Baer
Paul Carpenter
says...
> Hi Tom,
>
> tlbs101 wrote:
> > On May 24, 3:06 pm, tlbs101 <tlbs...@excite.com> wrote:
> >> On May 24, 9:36 am, D Yuniskis <not.going.to...@seen.com> 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.
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 | pa...@pcserviceselectronics.co.uk
<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
amark
I noticed an entry on Barcodes in Wikipedia a while ago
D Yuniskis
Robert Baer wrote:
> D Yuniskis wrote:
>> 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)
> 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).
VioletaPachydermata
wrote:
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.
VioletaPachydermata
wrote:
><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 Yuniskis
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")
Walter Banks
D Yuniskis wrote:
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..
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com
1 Lucky Texan
Good post, I guess it depends on whether he is building a file or
checking scanned items against an existing file.
D Yuniskis
Walter Banks 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
>> 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)
Walter Banks
D Yuniskis wrote:
> Hi Walter,
>
> Walter Banks wrote:
>
> >
> > 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)
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.
> > 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".
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.
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.
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.
--
Tony
D Yuniskis
Walter Banks wrote:
>
>>> 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)
>
> 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".
>>> 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".
>
> 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 Yuniskis
Tony wrote:
> 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]
Walter Banks
D Yuniskis wrote:
> Hi Walter,
>
> Walter Banks wrote:
> >
> >
> > 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!)
You can also opt to use UPC register and never mistake a
cap for 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".
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.
>
> > 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 lable 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! :> )
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.
D Yuniskis
Walter Banks wrote:
[attributions elided]
>>> 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!)
>
> 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)
>>> 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".
>
> 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.
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".
>> 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
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.
>> 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.
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".
>> 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
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" :-/
Paul Hovnanian P.E.
[snip]
> 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.
One way you can ensure non-collisions is to select a part of the UPC (or
whatever) code space that you are guaranteed not to see in your
application. For example, if you are developing an app for auto parts, code
everything as some sort of vegetable.
Your app will still break if you bring it into the grocery store. It might
also break if some third party has appropriated the same idea as you have
for labels that will appear in your domain.
--
Paul Hovnanian pa...@hovnanian.com
----------------------------------------------------------------------
Have gnu, will travel.
1 Lucky Texan
If it is extremely important to decrease the odds of scanning a false
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
Walter Banks
D Yuniskis wrote:
> 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.
> > 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.
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.
> >> 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.
>
> 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.
D Yuniskis
Paul Hovnanian P.E. wrote:
> D Yuniskis wrote:
>
> [snip]
>> 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.
>
> One way you can ensure non-collisions is to select a part of the UPC (or
> whatever) code space that you are guaranteed not to see in your
> application. For example, if you are developing an app for auto parts, code
> everything as some sort of vegetable.
Yes. I'm essentially trying to do this by picking a symbology
that isn't likely to *ever* be encountered (E.g., ABC Codabar).
Then, increasing the unlikelihood by bastardizing the
normal characteristics of the label (check digit).
Then, adding features that are seldom used (continuation code)
in nonstandard ways. Finally, building meaning into the
format of the label itself (sparse data, checksums, etc)
Since *printing* the labels incurs the same cost regardless
of which symbology/content I use, it doesn't cost me anything
to increase the uniquenexx of the labels.
> Your app will still break if you bring it into the grocery store. It might
> also break if some third party has appropriated the same idea as you have
> for labels that will appear in your domain.
Yup. Unless you can control what stuff you get exposed to,
you can't *guarantee* behavior. E.g., if you have a 1KW load
on the AC mains but can't control the mains, then you
can't guarantee the ~10A fuse will NEVER blow.
Given how ubiquitous barcodes are nowadays, its too hard
to keep foreign labels away from your scanner(s).
RFID tags were a nice alternative (laser'ed serial numbers)
but they are 10 times more expensive. :<
D Yuniskis
> 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)
D Yuniskis
Walter Banks wrote:
>
> D Yuniskis wrote:
>
>> 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.
Yes, similar to OUI's, ISBN publishers, etc.
>>> 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.
>
> 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.
>
>> 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.
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)
>>>> 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.
>> 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.
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).
>> 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.
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.
Bit Farmer
> D Yuniskis wrote:
>
> [snip]
>> 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.
>
> One way you can ensure non-collisions is to select a part of the UPC (or
> whatever) code space that you are guaranteed not to see in your
> application. For example, if you are developing an app for auto parts, code
> everything as some sort of vegetable.
>
> Your app will still break if you bring it into the grocery store. It might
> also break if some third party has appropriated the same idea as you have
> for labels that will appear in your domain.
>
The UCC/GS1 (former name/current name)handled the registration for UPCs'.
The UPC A code is most commonly used for grocery and general merchandise.
The first digit of the UPC is the number system. These select the usage of
the code that follows:
UPC-A encodes 12 numeric digits.
* 0: regular UPC codes
* 1: reserved
* 2: random weight items marked at the store
* 3: National Drug Code and National Health Related Items code
* 4: no format restrictions, for in-store use on non-food items
* 5: for use on coupons
* 6: reserved
* 7: regular UPC codes
* 8: reserved
* 9: reserved
For articles, the next five digits are the manufacturer's identifier.
The next 5 are the article number. The last is the check digit.
Now, not all codes are assigned. Some like 2 and 4 are for in store use.
That is they are for general use. Many frequent shopper cards are coded
using number system 2 or 4. Thus they can be scanned like a regular item
but have meaning only to the system that is reading them.
b. Farmer
D Yuniskis
I thought 6 was also used for coupons?
> * 7: regular UPC codes
> * 8: reserved
> * 9: reserved
>
> For articles, the next five digits are the manufacturer's identifier.
> The next 5 are the article number. The last is the check digit.
>
> Now, not all codes are assigned. Some like 2 and 4 are for in store use.
> That is they are for general use. Many frequent shopper cards are coded
> using number system 2 or 4. Thus they can be scanned like a regular item
> but have meaning only to the system that is reading them.
... meaning the *person* scanning them must ensure that this is
"one of our cards (UPC codes)".
Steve Watt
D Yuniskis <not.goi...@seen.com> wrote:
>tlbs101 wrote:
>> On May 24, 3:06 pm, tlbs101 <tlbs...@excite.com> 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.
>>>> But, I'd be open to other suggestions. [I can't roll my own
>>>> code as I want to use COTS scanners.]
>
>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.
--
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3"
Internet: steve @ Watt.COM Whois: SW32-ARIN
Free time? There's no such thing. It just comes in varying prices...
D Yuniskis
Steve Watt wrote:
>> 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)
>> 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.
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.
>> 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.
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...)
;-)
VioletaPachydermata
wrote:
>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.
VioletaPachydermata
wrote:
>> have "SN" (Serial Number) as their first two characters?
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).
RockyG
>
>Steve Watt wrote:
>>> Rather, the problem is ensuring that the scanner doesn't
>>> "hit" on a label that isn't "mine".
>>
>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).
>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! :-/
What happens if after the fact someone wants to make a 'unique' barcoding
system and happens to choose (after the same thought processes) a code that
is compatible with yours?
Maybe it would be better to register?
---------------------------------------
Posted through http://www.EmbeddedRelated.com
Tony
> Hi Tony,
>
> Tony wrote:
>> 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)
>
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.
>> 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?
>
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.
>> 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 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.
--
Tony
Hans-Bernhard Bröker
> What happens if after the fact someone wants to make a 'unique' barcoding
> system and happens to choose (after the same thought processes) a code that
> is compatible with yours?
Seconded.
It's well-known that "security by obscurity" doesn't work. The OP is
looking for disambiguity by obscurity. That won't work either, for
roughly the same reasons.
D Yuniskis
Tony wrote:
>>> 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)
>
> 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...
>>> 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?
>
> 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 (?).
>>> 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 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.
D Yuniskis
>> Hi Steve,
>>
>> Steve Watt wrote:
>>>> Rather, the problem is ensuring that the scanner doesn't
>>>> "hit" on a label that isn't "mine".
> <snip>
>> 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).
> <snip>
>> 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! :-/
>
> What happens if after the fact someone wants to make a 'unique' barcoding
> system and happens to choose (after the same thought processes) a code that
> is compatible with yours?
What happens if the barcode vendors decide that RFID is
pushing them out of the market (once tags get cheaper)
and decide to stop manufacturing scanners?
> Maybe it would be better to register?
Why doesn't UPS, FedEx, your local library, Dell, etc.
use UPC and "register"? It's a manageable risk. Just
like every other engineering decision.
Walter Banks
D Yuniskis wrote:
> > Maybe it would be better to register?
>
> Why doesn't UPS, FedEx, your local library, Dell, etc.
> use UPC and "register"? It's a manageable risk. Just
> like every other engineering decision.
The real reason is, UPC is registered for commercial reasons.
It is a barcode format that is written by a producer and is
intended to be read by potentially many consumers.
Your problem appears to me to be once written, it is intended
to be read by a limited number of consumers. The kind of
application you described can be reliably implemented
using record syntax and minimal record checking probably
a single character. I can tell you from experience that false
positives are very rare.
"Contemporary applications of optical bar code technology"
Banks,Helmers,Trueblood
Library of Congress HF5416 .B36
http://www.getcited.com/puba/102240291
My choice for your application would be Code39. I
would like to have a total record size of 12 - 15 characters.
Codabar has a slightly higher density than Code39 with
fewer symbols. Actually it has be sometimes known as 2 of 7.
It has some big users (FedEx for example). The plus for you
is it has multiple record field separator characters that have
no data meaning.
JosephKK
wrote:
>Hi Tom,
>
>tlbs101 wrote:
>> On May 24, 3:06 pm, tlbs101 <tlbs...@excite.com> wrote:
>>> On May 24, 9:36 am, D Yuniskis <not.going.to...@seen.com> 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
>>>> 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)
>
>>> (the team) could use. The database was written in FoxPro (not my
>>> choice -- lol).
>
><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.
>
>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. :-/
>
JosephKK
wrote:
>Greegor wrote:
>
>>> 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".
>>
>> Gonna use a Zebra printer?
>>
>> http://www.zebra.com/id/zebra/na/en/index/products/printers/industrial_commercial/zm400.html
>
>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 Yuniskis
JosephKK wrote:
>> 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.
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".