Barcode Symbologies
in [Embedded]
|
Prev: Extended deadline (15 July 2010): CACS Singapore [EI Compendex,ISTP,IEEE Xplore]
Next: Spore Forming Protozoa
From: Tony on 26 May 2010 07:21 D Yuniskis wrote: > 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) > No the labels where all pre-printed and just unique, we could not do a seperate server based system to support multiple test fixtures at the time and CEMs can (nearly) always control bar codes to be unique. They can also easily record and match stuff in a database. The labels started with the fixed 3 digit customer code. The programmer read the label and wrote a calculated code to the memory. >> 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? > No they were set/provided by another person. I just chose to use it in the bar code to help ensure the factory didn't mix up labels or boards in the process. >> 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 couldn't say for sure, but I tend to assume most scanners can do this. I've done it with an embedded scanner and a hand scanner (both <�100 each). >> 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] You cannot eliminate the problem completely , but the using a fixed number of digits and some fixed digits you can dramatically reduce the probability. Although I have to say I've never tried to calculate it. -- Tony
From: Hans-Bernhard Bröker on 26 May 2010 15:45 RockyG wrote: > What happens if after the fact someone wants to make a 'unique' barcoding > system and happens to choose (after the same thought processes) a code that > is compatible with yours? Seconded. It's well-known that "security by obscurity" doesn't work. The OP is looking for disambiguity by obscurity. That won't work either, for roughly the same reasons.
From: D Yuniskis on 26 May 2010 21:03 Hi Tony, Tony wrote: >>> 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) > > No the labels where all pre-printed and just unique, we could not do a Ah, OK. I.e., "read the barcoded label" instead of trying to read a serial number off a board, etc. > seperate server based system to support multiple test fixtures at the > time and CEMs can (nearly) always control bar codes to be unique. They > can also easily record and match stuff in a database. The labels > started with the fixed 3 digit customer code. The programmer read the > label and wrote a calculated code to the memory. Understood. Sort of like "unlock codes" for software... >>> 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? > > No they were set/provided by another person. I just chose to use it in > the bar code to help ensure the factory didn't mix up labels or boards > in the process. Oh. So you just used "001", "002" and "003" out of 999 valid codes (?). >>> 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 couldn't say for sure, but I tend to assume most scanners can do this. > I've done it with an embedded scanner and a hand scanner (both <�100 > each). I'll see if I can find three or four "compatible" scanners (compatible in terms of their feature sets). If all of them have the feature, that gives me three "backup suppliers" if one goes belly up. >>> 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] > > You cannot eliminate the problem completely , but the using a fixed Correct. > number of digits and some fixed digits you can dramatically reduce the > probability. Although I have to say I've never tried to calculate it. Therein lies the rub. I.e., you can calculate the chances of a fuse blowing given a particular nominal load; you can calculate the time it takes to respond to an interrupt event; etc. -- but this sort of thing is really hard to quantify. All you can do is try to make it "highly unlikely" that you'll have a conflict in practice. And, design so that the only thing you need to change are the *physical* labels if a conflict becomes commonplace.
From: D Yuniskis on 26 May 2010 21:05 RockyG wrote: >> Hi Steve, >> >> Steve Watt wrote: >>>> Rather, the problem is ensuring that the scanner doesn't >>>> "hit" on a label that isn't "mine". > <snip> >> 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). > <snip> >> 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! :-/ > > What happens if after the fact someone wants to make a 'unique' barcoding > system and happens to choose (after the same thought processes) a code that > is compatible with yours? What happens if the barcode vendors decide that RFID is pushing them out of the market (once tags get cheaper) and decide to stop manufacturing scanners? > Maybe it would be better to register? Why doesn't UPS, FedEx, your local library, Dell, etc. use UPC and "register"? It's a manageable risk. Just like every other engineering decision.
From: Walter Banks on 27 May 2010 04:57
D Yuniskis wrote: > > Maybe it would be better to register? > > Why doesn't UPS, FedEx, your local library, Dell, etc. > use UPC and "register"? It's a manageable risk. Just > like every other engineering decision. The real reason is, UPC is registered for commercial reasons. It is a barcode format that is written by a producer and is intended to be read by potentially many consumers. Your problem appears to me to be once written, it is intended to be read by a limited number of consumers. The kind of application you described can be reliably implemented using record syntax and minimal record checking probably a single character. I can tell you from experience that false positives are very rare. "Contemporary applications of optical bar code technology" Banks,Helmers,Trueblood Library of Congress HF5416 .B36 http://www.getcited.com/puba/102240291 My choice for your application would be Code39. I would like to have a total record size of 12 - 15 characters. Codabar has a slightly higher density than Code39 with fewer symbols. Actually it has be sometimes known as 2 of 7. It has some big users (FedEx for example). The plus for you is it has multiple record field separator characters that have no data meaning. Regards, Walter.. -- Walter Banks Byte Craft Limited http://www.bytecraft.com |