Barcode Symbologies
in [Design]
|
From: D Yuniskis on 25 May 2010 09:31 Hi Walter, Walter Banks 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 >> 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. Yes, but handheld scanners just recognize valid "encodings". I.e., they don't examine the content of the message/label to determine if the "product exists". E.g., the validity of a UPC label for the "local" group can't be validated a priori. (UPC is a bad choice, for me, as you can find UPC labels too commonly -- too hard to minimize the risk of a false positive) > 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. Code 39 is also widely used and runs the same risk as UPC -- only different. :> It seems like Code 128, 39 and UPC are the biggest offenders in terms of risk of conflict. And, since they are all free-form codes (unconstrained content), there's no way of *reliably* guaranteeing that some "foreign" label won't conflict with my "identifier space". I don't want folks to have to take on the added responsibility of "scribbling out" (or over-spraying) any preexisting labels on packaging, merchandise, etc. Likewise, I want a simple rule: "If you're trying to scan a label and the system doesn't recognize it, you're scanning the *wrong* label -- keep looking :> " (i.e., high first pass read rate, low error rate)
From: Walter Banks on 25 May 2010 09:57 D Yuniskis wrote: > Hi Walter, > > Walter Banks wrote: > > > > > 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. > > Yes, but handheld scanners just recognize valid "encodings". > I.e., they don't examine the content of the message/label > to determine if the "product exists". E.g., the validity > of a UPC label for the "local" group can't be validated > a priori. > > (UPC is a bad choice, for me, as you can find UPC labels too > commonly -- too hard to minimize the risk of a false positive) Code39 is a transport layer of a limited symbol set. A barcode record is the actual message consisting of symbol characters that has meaning. A generic barcode reader will read the transport characters relatively reliably but without additional programming will not validate the record read or interpret the information. > > 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. > > Code 39 is also widely used and runs the same risk as > UPC -- only different. :> It seems like Code 128, 39 > and UPC are the biggest offenders in terms of risk of > conflict. And, since they are all free-form codes > (unconstrained content), there's no way of *reliably* > guaranteeing that some "foreign" label won't conflict > with my "identifier space". It is actually unlikely the a foreign labile will conflict with your identifier space. UPC is the classic case user register the part *their* barcode that makes their case unique. http://www.abblabels.com/Products/html/UPCBarcodeLabels.htm Think is the UPC registration for example as a preamble followed by the actual information. The registration has the added advantage of making available the owner information available to most people using UPC reader equipment. Registration makes your UPC record unique This process make false positives very rare. Code39 does not have the same registration process. In most of the applications using Code39 record format and check characters are sufficient to prevent undetected errors. For example creating a Code 39 barcode record for you application might have *DJ1234567855* would be a Code39 labile about 1.5" long with DJ to identify it as yours 8 Data digits 55 two check digits. All records records you are interested would start with DJ. Since the text is usually printed in the label as well there would be a limited ability for false positives. Regards, Walter.. -- Walter Banks Byte Craft Limited http://www.bytecraft.com
From: Tony on 25 May 2010 10:14 Walter Banks 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. > Code 39 is very wasteful as it covers ascii, ITF (interleave 2 of 5) would be more efficent space wise (if that is important to you)for decimal only. More space = more characters and fixed digits. I used this for a encryption system that needed to be programmed with unique number and readable later on in the process. False reads were important, although the reader was built into a test fixture. I also used 3 (fixed) digits for a customer code, of which there were only 3 or 4 customers. The test fixture was set for the appropriate customer at the start of a shift, non matches where rejected. The fixed parts help reduce the possibility of a false hit and You can further reduce your chances of a false read by fixing the number of digits in the code. Most scanner can be programmed for this. They can also be programmed whether there the last digit is a check digit or not, and whether to transmit this. I also used bearer bars top and bottom to help reduce bad reads further. -- Tony
From: D Yuniskis on 25 May 2010 11:17 Hi Walter, Walter Banks wrote: > >>> 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. >> Yes, but handheld scanners just recognize valid "encodings". >> I.e., they don't examine the content of the message/label >> to determine if the "product exists". E.g., the validity >> of a UPC label for the "local" group can't be validated >> a priori. >> >> (UPC is a bad choice, for me, as you can find UPC labels too >> commonly -- too hard to minimize the risk of a false positive) > > Code39 is a transport layer of a limited symbol set. A barcode > record is the actual message consisting of symbol characters that > has meaning. A generic barcode reader will read the transport > characters relatively reliably but without additional programming > will not validate the record read or interpret the information. The scanner will ensure the label adheres to the requirements of the symbology (i.e., proper bar/space ratios, proper check digit, adequate whitespace bracketing the label). Beyond that, the "content" of the label is "application specific". >>> 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. >> Code 39 is also widely used and runs the same risk as >> UPC -- only different. :> It seems like Code 128, 39 >> and UPC are the biggest offenders in terms of risk of >> conflict. And, since they are all free-form codes >> (unconstrained content), there's no way of *reliably* >> guaranteeing that some "foreign" label won't conflict >> with my "identifier space". > > It is actually unlikely the a foreign labile will conflict > with your identifier space. UPC is the classic case > user register the part *their* barcode that makes their > case unique. > > http://www.abblabels.com/Products/html/UPCBarcodeLabels.htm Yes, but *I* can opt to use UPC encoding to represent my data. Doing so suggests that, sooner or later, I will encounter an item with a "real" UPC barcode printed on it that my "system" will mistakenly take as "one of my own". I.e., a box of Cheerios coincidentally has thet same "identifier" (encoded into the body of the UPC label) as my "Capacitor, Electrolytic, 25uF, 16WVDC, radial". (the *scanner* can't tell that it's a box of cheerios!) > Think is the UPC registration for example as a preamble > followed by the actual information. The registration > has the added advantage of making available the > owner information available to most people using UPC > reader equipment. Registration makes your UPC record unique > > This process make false positives very rare. Only rare for folks who are part of that "registered identifier space". Sort of like OUI's -- I can program *any* MAC into my NIC. But, there is no guarantee that I won't end up programming a MAC that isn't already in use, somewhere (belonging to some other organization). This is the problem I am trying to anticipate and avoid. > Code39 does not have the same registration process. In > most of the applications using Code39 record format > and check characters are sufficient to prevent undetected > errors. > > For example creating a Code 39 barcode record for > you application might have > > *DJ1234567855* > > would be a Code39 labile about 1.5" long with > DJ to identify it as yours > 8 Data digits > 55 two check digits. > > All records records you are interested would start with > DJ. Since the text is usually printed in the label as well > there would be a limited ability for false positives. Yes, this was my point about adding extra digits (I'm avoiding other characters simply because those other characters restrict you to using a smaller set of symbologies). But, you can't *know* (for sure) what "message/label formats" other people may use. I.e., tomorrow, you may start doing business with a company who labels *all* of their products with "DJ" numbers. :-/ (the longer the 'preface' or other "unique-ifying" data, the less the chance of random conflict ... "YUNISKIS" might be a suitably unique choice for a prefix! :> ) For example, Dell uses 6 character identifiers for their "service tags". What are the chances that using a similar format would result in eventually coming up with a "hit" that was unintended? I wonder how many Code 128 labels have "SN" (Serial Number) as their first two characters? I am, instead, looking to pick a symbology that is less likely to be encountered. *Or*, bend the rules regarding *my* choices of symbols such that "everyone else's" look invalid to me. I.e., you're advocating making them look invalid by relying on "DJ" to make them unique; I'm thinking, instead, of violating some inherent aspect of the label format -- check digit -- that they *wouldn't*... because they would want the scanner to do the check digit verification *for* them whereas I am willing to take on that task myself -- using a different "scheme". For example, using multipart Codabar labels (*very* uncommon) but printing them as "single part" labels.
From: D Yuniskis on 25 May 2010 11:46
Hi Tony, Tony wrote: > Code 39 is very wasteful as it covers ascii, ITF (interleave 2 of 5) > would be more efficent space wise (if that is important to you)for > decimal only. More space = more characters and fixed digits. Yes, I was acknowledging this in my initial decision to just stick to pure numeric identifiers (they are just identifiers -- no need for them to have human readable content). This gives me the most choices between symbologies. Also *can* give me better character densities and/or decoding reliability (by storing less data in a given space *if* done properly). > I used this for a encryption system that needed to be programmed with > unique number and readable later on in the process. False reads were Not sure I understand your application; did the "programmer" then print a barcode label on the device? (which was later read) > important, although the reader was built into a test fixture. I also With a non contact scanner, you can usually do really good at reader accuracy (and first pass read rate should be damn near "six nines"). I've designed wand-type scanners that had to hit 99% FPRR and 99% accuracy (which is tough because the user can't be guaranteed to scan at a constant speed *and* the range of speeds varies over two or more orders of magnitude!) > used 3 (fixed) digits for a customer code, of which there were only 3 or OK, so you presumably chose those "valid" codes to maximize their hamming distances? > 4 customers. The test fixture was set for the appropriate customer at > the start of a shift, non matches where rejected. > > The fixed parts help reduce the possibility of a false hit and You can > further reduce your chances of a false read by fixing the number of > digits in the code. Most scanner can be programmed for this. They can I can handle that in the system software. I.e., I can validate any identifiers as "mine" by checking: - symbology used (scanner can tell me this) - message format (digits, preamble, check digit, etc.) - "does the identifier exist in the database"? > also be programmed whether there the last digit is a check digit or not, > and whether to transmit this. Is this true of all scanners? I have found it to be the case of the few that I have examined but haven't seen that as a "guaranteed feature" (i.e., does The Industry require this as a "basic feature" or is it an enhancement offered by many/all scanner vendors?) > I also used bearer bars top and bottom to help reduce bad reads further. Ah, good point! Though I would think that an examination of the "read data" could give you this information, as well (i.e., short read, bad check digit, etc.) My problem will be making sure some *other* label isn't accidentally scanned AS IF it was "mine". E.g., I chuckle watching folks at the "self check-out" at the library scanning their books and getting frustrated because the system doesn't recognize the barcode (because they are scanning the EAN code instead of the library's *specific* "item number" label). Poorly designed system has the scanner beeping even on bad scans (so folks who just listen for the beep wonder why their receipt doesn't have all the items listed on it!) as well as failing to inform the patron that "you've scanned the wrong label" (since the system could easily know that the scanner just saw an EAN label instead of the library's specific label!) [people who "assemble" systems from OTS subsystems often don't think things through completely, IME] |