Barcode Symbologies
in [Design]
|
From: 1 Lucky Texan on 25 May 2010 00:20 On May 24, 10:12 pm, D Yuniskis <not.going.to...(a)seen.com> wrote: > 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) 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?
From: Robert Baer on 25 May 2010 03:06 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) Use the inverse of the correct check code..aka check bar (pun intended).
From: Paul Carpenter on 25 May 2010 04:31 In article <htf5eg$9sc$1(a)speranza.aioe.org>, not.going.to.be(a)seen.com says... > 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. 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 | paul(a)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
From: amark on 25 May 2010 07:47 On May 25, 1:36 am, D Yuniskis <not.going.to...(a)seen.com> wrote: > Hi, > > I need to pick a barcode symbology that is unlinkey to be > encountered in day-to-day items to minimize conflicts. E.g., > UPC is non-starter. > > I only need 8 decimal digits so no need for the more complex > codes. I prefer a 2 dimensional code as it increases the > available choices for scanners. I'll probably add a few > digits for my own checksum (above and beyond whatever the > code itself supports). So, maybe 10-12 digits, total. > > I suspect ABC Codabar is probably the most obscure (at > least the least likely to be encountered *on* something). > I can even get sneaky and print multipart labels to > be even *more* unique. > > But, I'd be open to other suggestions. [I can't roll my own > code as I want to use COTS scanners.] > > Thanks! > --don I noticed an entry on Barcodes in Wikipedia a while ago
From: D Yuniskis on 25 May 2010 08:18
Hi Robert, 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). |