Barcode Symbologies
in [Design]
|
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: Grant on 25 May 2010 18:05 On Tue, 25 May 2010 05:27:32 -0700, D Yuniskis <not.going.to.be(a)seen.com> wrote: >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") Also use a fairly long checksum, as too short a checksum may allow false positives through. Grant. -- http://bugs.id.au/
From: Steve Watt on 25 May 2010 18:17 In article <htf5eg$9sc$1(a)speranza.aioe.org>, D Yuniskis <not.going.to.be(a)seen.com> wrote: >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. [ snip ] >>>> But, I'd be open to other suggestions. [I can't roll my own >>>> code as I want to use COTS scanners.] >>>> Thanks! > >Rather, the problem is ensuring that the scanner doesn't >"hit" on a label that isn't "mine". This part's tough for COTS/surplus scanners. Admittedly, it's been nearly 20 years since I looked around in the market, but I couldn't find any back then that allowed suppression of the scan acknowledge "beep". My solution was to find readers that didn't have a beep and use the terminal[1]'s bell to signify a good read. >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. :-/ Codabar is still pretty common. I'm staring at a Dell machine with a M$ tax sticker on it that has two what look like Codabar lines and a 2D line. I seem to recall Codabar being very common in libraries, too. >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". Back then, I chose code 39, and used an additional check digit inside the regular scan path. [1] Yes, I'm probably showing my age. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3" Internet: steve @ Watt.COM Whois: SW32-ARIN Free time? There's no such thing. It just comes in varying prices...
From: D Yuniskis on 25 May 2010 18:48
Hi Steve, Steve Watt wrote: >> Rather, the problem is ensuring that the scanner doesn't >> "hit" on a label that isn't "mine". > > This part's tough for COTS/surplus scanners. Admittedly, it's > been nearly 20 years since I looked around in the market, but > I couldn't find any back then that allowed suppression of the > scan acknowledge "beep". My solution was to find readers that > didn't have a beep and use the terminal[1]'s bell to signify a good > read. I've found some that will let you turn off the beep. Some will even let you *drive* the beep (^G) with an appropriate interface (i.e., duplex). If push comes to shove, I can cut the leads to the transducer (or pour epoxy on it so it can't flex audibly enough :> ). But, having the beep *in* the scanner is a real win (especially for the cordless scanners) as it is "right there" with the user (instead of at the other end of the cord) >> 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. :-/ > > Codabar is still pretty common. I'm staring at a Dell machine > with a M$ tax sticker on it that has two what look like Codabar > lines and a 2D line. The Dells that I have use 7 character Code128 label for the service tag, Code 128 on the motherboard, etc. Even the XP license sticker is Code128 (two linear codes and a 2D code). I have a little Symbol PDA (Palm III with barcode reader built in) that has a handy little diagnostic application. Scan a label and it tells you the label's contents as well as the symbology used. Quite handy! :> > I seem to recall Codabar being very common in libraries, too. Yes. >> 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". > > Back then, I chose code 39, and used an additional check > digit inside the regular scan path. I think there's enough ways that I can "bend" the labels' format and content that I should be able to drive the probability of a "bogus read" into the mud. My biggest fear is *picking* something (i.e., without careful consideration) and discovering after-the-fact that some supplier *also* uses that and there are conflicts every 10 minutes! :< Especially after having tagged everything! :-/ > [1] Yes, I'm probably showing my age. The fact that you said *bell* (instead of *beep*) gave you away! (I think bells went away with the ASR33...) ;-) |