Barcode Symbologies
in [Design]
|
From: VioletaPachydermata on 25 May 2010 08:14 On Mon, 24 May 2010 20:12:08 -0700, D Yuniskis <not.going.to.be(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) 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.
From: VioletaPachydermata on 25 May 2010 08:16 On Mon, 24 May 2010 17:32:19 -0700, D Yuniskis <not.going.to.be(a)seen.com> 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.
From: D Yuniskis on 25 May 2010 08:27 1 Lucky Texan wrote: > On May 24, 10:12 pm, D Yuniskis <not.going.to...(a)seen.com> wrote: >> (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? 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")
From: Walter Banks on 25 May 2010 08:26 D Yuniskis 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.] > 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
From: 1 Lucky Texan on 25 May 2010 09:01
On May 25, 7:26 am, Walter Banks <wal...(a)bytecraft.com> wrote: > D Yuniskis 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.] > > 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 Limitedhttp://www.bytecraft.com Good post, I guess it depends on whether he is building a file or checking scanned items against an existing file. |