Barcode Symbologies
in [Design]
|
From: VioletaPachydermata on 25 May 2010 21:03 On Tue, 25 May 2010 11:22:11 -0700, D Yuniskis <not.going.to.be(a)seen.com> wrote: >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... Naw... that could never happen. How could you possibly think that a STANDARD format would be unique in your utilization of it? As I stated before. UID. Who cares who and where it gets used? ALL utilizations of it can be unique simply by your formatting of the data. The reading can be set up such that only that unique data structure and format gets read in, so "the vendor" with the same barcode would still NOT upset or cause a failure mode with your utilization. Pick one and use it, just use a unique data string composition. Easy, greasy, Japanezee.
From: VioletaPachydermata on 25 May 2010 21:51 On Tue, 25 May 2010 11:44:42 -0700, D Yuniskis <not.going.to.be(a)seen.com> wrote: >> have "SN" (Serial Number) as their first two characters? Field structures vary. Some have a <SN> 'field' followed by the actual s/n in the form <1234567> So you would read out <SN><1234567> and your computer would "see it" as something like 'comma separated ascii' or the like and load up the fields in a spreadsheet or database just fine or you could do it later and simply read it all into a single cell or field. You can segregate fields in that manner (the odd containment/segregation characters).
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: 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: JosephKK on 3 Jun 2010 01:32
On Mon, 24 May 2010 17:32:19 -0700, D Yuniskis <not.going.to.be(a)seen.com> wrote: >Hi Tom, > >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. >>>> 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 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 > >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) > >>> (the team) could use. The database was written in FoxPro (not my >>> choice -- lol). > ><grin> I used Paradox for my first database. I've since moved >everything to PostgreSQL. Much more robust, capable and >extensible! > >> Or... just buy a scanner that supports multiple codes and let the >> scanner figure it out. > >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". I think you are barking up the wrong tree here, let the scanner spit out lots of invalid for you codes and you sort them out. It is not like they are spitting hundreds of codes per second. And use any 2D code, then your subset acceptable code space can have huge Hamming distances. Plus there is enough internal code space to put internal ECC in. > >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". |