Barcode Symbologies
in [Embedded]
|
Prev: Extended deadline (15 July 2010): CACS Singapore [EI Compendex,ISTP,IEEE Xplore]
Next: Spore Forming Protozoa
From: D Yuniskis on 25 May 2010 14:19 Hi Paul, 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. :<
From: D Yuniskis on 25 May 2010 14:22 1 Lucky Texan wrote: > 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)
From: D Yuniskis on 25 May 2010 14:44 Hi Walter, 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.
From: Bit Farmer on 25 May 2010 15:46 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. > > 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
From: D Yuniskis on 25 May 2010 16:19
Bit Farmer wrote: > 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. >> >> 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 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)". |