Barcode Symbologies
in [Design]
|
From: D Yuniskis on 24 May 2010 20:32 Hi Tom, tlbs101 wrote: > On May 24, 3:06 pm, tlbs101 <tlbs...(a)excite.com> wrote: >> On May 24, 9:36 am, D Yuniskis <not.going.to...(a)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".
From: Greegor on 24 May 2010 20:45 On May 24, 7:32 pm, D Yuniskis <not.going.to...(a)seen.com> wrote: > Hi Tom, > > > > > > tlbs101 wrote: > > On May 24, 3:06 pm, tlbs101 <tlbs...(a)excite.com> wrote: > >> On May 24, 9:36 am, D Yuniskis <not.going.to...(a)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". Gonna use a Zebra printer? http://www.zebra.com/id/zebra/na/en/index/products/printers/industrial_commercial/zm400.html
From: D Yuniskis on 24 May 2010 21:30 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.)
From: Paul Hovnanian P.E. on 24 May 2010 21:49 D Yuniskis wrote: > > 1 Lucky Texan wrote: > > On May 24, 10:36 am, D Yuniskis <not.going.to...(a)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) 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:Paul(a)Hovnanian.com ------------------------------------------------------------------ A vacuum is a hell of a lot better than some of the stuff that nature replaces it with. -- Tennessee Williams
From: D Yuniskis on 24 May 2010 23:12
Hi Paul, Paul Hovnanian P.E. wrote: > D Yuniskis wrote: >> 1 Lucky Texan wrote: >>> On May 24, 10:36 am, D Yuniskis <not.going.to...(a)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) > > 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) |