Barcode Symbologies

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)

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)

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.

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.

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

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

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".

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!)

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.

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.

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).

Not sure I understand your application; did the "programmer" then print a barcode label on the device? (which was later read)

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!)

OK, so you presumably chose those "valid" codes to maximize their hamming distances?

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"?

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?)

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 can also opt to use UPC register and never mistake a cap for a box of cheerios.

In the UPC cas that is essentially all users are registered. The registration cost is very low to encourage participation, the benefits are data security and rare false positives The standard UPC record checking will weed out essentially all the rest of the unregistered UPC images..

UPC was developed to eliminate the problem that you have been describing. A bunch of years ago the barcode industry was filled with many different transport layers and data formats most with a unique application area. The only security was each company creating their own encoding and data and record formats.

False positives are rare, once format, validation and context are accounted for. For example, the automotive industry has literally hundreds of suppliers using two or three standard barcode encodings and don't have a problem with false positives because of this.

Actual Dell now uses a 7 character identifier for service tags. However you just identified an important point on identifying barcode, context. Dell uses several barcodes on the bottom of there laptops top identify product, manufacturer software licences and service tags.

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.

Barcode formats are implemented in layers. Additional checking in some cases is important. Do it. I am not sure what you application is? Describing the application may identify or reject some of the standard solutions.

Regards,

Walter..

-- Walter Banks Byte Craft Limited

[attributions elided]

But that requires the person operating the register to be aware of the distinction (pick something other than caps and cheerios and repeat the exercise)

Exactly. Because the entire namespace ("message space"?) was available to all users. Imagine if anyone could make up any FQDN and tried to operate in the presence of other folks (sharing a namespace).

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.

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.

But I imagine they:

- don't let items come into their receiving dock without rigidly defining how they are labeled; or

- instruct their staff to obscure any other barcodes that may be on the packaging/items; or

- instruct their staff in *which* barcode is the "correct" barcode to scan

- etc.

I.e., they can't just scan a barcode -- ANY BARCODE IN THE BUILDING -- and be assured that it is *the* barcode that they wanted to scan.

(they are also big enough to be able to enforce their wishes on their suppliers -- "you will label your parts in this fashion")

I can work around *some* problem areas by visual cues in the labels. E.g., location identifiers are affixed to blue plastic placards so a user "knows" this is a location identifier and doesn't have to go hunting for it. But, the software can't tell that the data scanned came from a "blue plastic placard".

I stand corrected. I was looking at a license tag. tags. However you just identified an important point

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.

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".

I intend to. Beginning with verification of the symbology used in each scanned label.

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!")

The Average Joe isn't going to understand the nuances of "barcodology" :-/

r t

can

, .

If it is extremely important to decrease the odds of scanning a false 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;

UPC registration comes in two parts. A registered part identifying the owner and a block of numbers for the registered owner to use.

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.

In a well implemented barcode system false positives are rare.

In your proposal, some of the symbol space is translated into the transportation layer. It is a tradoff but not a significant one.

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.

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.

Regards,

Walter..

-- Walter Banks Byte Craft Limited

-----------^^^^^^^^^

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)

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)

Yes, similar to OUI's, ISBN publishers, etc.

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.

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)

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).

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.

Also use a fairly long checksum, as too short a checksum may allow false positives through.

Grant.

--
http://bugs.id.au/

[ snip ]

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.

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.

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...

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)

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! :>

Yes.

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! :-/

The fact that you said *bell* (instead of *beep*) gave you away! (I think bells went away with the ASR33...)

;-)

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.

Field structures vary. Some have a 'field' followed by the actual s/n in the form So you would read out 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).

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.

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.

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 > I also used bearer bars top and bottom to help reduce bad reads further.

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

Ah, OK. I.e., "read the barcoded label" instead of trying to read a serial number off a board, etc.

Understood. Sort of like "unlock codes" for software...

Oh. So you just used "001", "002" and "003" out of 999 valid codes (?).

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.

Correct.

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.

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.