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 paul@hovnanian.com ---------------------------------------------------------------------- Have gnu, will travel.
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 dunno, lots of choices (checkout Code 11)
Grrrr.... s/2/1/ > available choices for scanners. I'll probably add a few
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 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
Or... just buy a scanner that supports multiple codes and let the scanner figure it out.
Tom
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)
I used Paradox for my first database. I've since moved everything to PostgreSQL. Much more robust, capable and extensible!
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?
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.)
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@Hovnanian.com ------------------------------------------------------------------ A vacuum is a hell of a lot better than some of the stuff that nature replaces it with. -- Tennessee Williams
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!)
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).
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?
Use the inverse of the correct check code..aka check bar (pun intended).
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.
...
....
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@pcserviceselectronics.co.uk
PC Services
Timing Diagram Font
GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
For those web sites you hate
I noticed an entry on Barcodes in Wikipedia a while ago
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.
Paradox was cool. Still would be were it still around.
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).
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
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")
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.