Connect with us

Barcode Symbologies

Discussion in 'Electronic Design' started by D Yuniskis, May 24, 2010.

Scroll to continue with content
  1. D Yuniskis

    D Yuniskis Guest

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

    Thanks!
    --don
     
  2. D Yuniskis

    D Yuniskis Guest

    Grrrr.... s/2/1/ <:-(
    Hmmm... never heard of Code 11! (and, apparently, most of the
    OTS scanners haven't, either! :< )

    Just from where I'm sitting, I see Codes 39, 128, EAN13, UPCA
    and Codabar :)<). I'll have to take a wander through the warehouse
    and see what other codes show up.

    I suspect I am just going to have to rely on a large enough
    Hamming distance in my symbols to make "coincidences" damn near
    impossible (coupled with enforcing the "chosen" symbology).

    I'll also have to check to see if I can configure any scanners
    to pass "bad reads". One hack might be to deliberately munge
    the check digit on a mainstream code so any labels with
    *valid* codes I would recognize as "foreign" (?) (i.e., print
    all of mine with a check digit guaranteed to be "wrong" -- yet
    predictable)
     
  3. D Yuniskis

    D Yuniskis Guest

    Hi Tom,
    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)

    <grin> I used Paradox for my first database. I've since moved
    everything to PostgreSQL. Much more robust, capable and
    extensible!
    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".

    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".
     
  4. D Yuniskis

    D Yuniskis Guest

  5. D Yuniskis

    D Yuniskis Guest

    Hi Paul,
    I understand that. The scanners I have been looking at allow you
    to configure the scanner to accept (or ignore) different symbologies.
    I plan, in some cases, on enabling *other* symbologies as well
    (and configuring the scanner to tag the decoded label with an
    indication of the symbology that it applied). I am more concerned
    with encountering *labels* in "some symbology" that I am hoping
    to make unique to my application (in the particular application
    domain -- i.e., don't use UPC if you are operating in a grocery
    store!)
    Yes, that was my initial plan. Relying *solely* on that, however,
    leaves you open to "collisions" with other "unrelated labels"
    in that same symbology -- UNLESS YOU CAN GUARANTEE THAT YOUR
    LABELS WILL BE "INVALID" (violate some "given") WRT THOSE
    OTHER "valid" labels.

    E.g., *use* UPC in a grocery store *but* deliberately print
    an incorrect check digit (9's complement) in all of *your*
    labels. This, however, relies on being able to configure
    the scanner to give you "bad read" data (so you can examine
    the "bad" check digit and verify that it is actually *correct*
    for your "scheme")

    Or, putting a 14 digit code in a UPC format, etc. (again, this
    risks being rejecteed outright by the scanner :< )

    The cleanest approach is just to pick a symbology that isn't
    likely to be encountered in that application environment and
    "further improve your odds" by forcing the label's contents
    to fit some other presecription(s) regarding format. E.g.,
    some CRC *within* the body of the label (that gets treated by
    the scanner as "in band" data).
    I think just *thinking* about the types of labels likely to
    "coincidentally" be encountered and picking something "highly
    unlikely" -- coupled with imposing a structure on the
    label's contents -- has got to be "six 9's" :> (hence the
    reason for suggesting ABC Codabar)

    (note there are always semantic checks that can be applied
    after a label is "accepted" so the chances are probably
    off the scale)
     
  6. Be careful what you pick is not the domain of just one industry that then
    changes. E.G. UPC gets replaced with UPC-2012, everyone stops supporting
    UPC, because no one uses it and later replacement scanners do not work.
    Be careful you don't end up with a system that is effectively
    requiring Code 11 and no newer scanners support it.

    Also be sure that the code being used is not one that is used by
    so few people that any bugs in code detection are unlikely to
    be fixed by scanner manufacturers.

    --
    Paul Carpenter |
    <http://www.pcserviceselectronics.co.uk/> PC Services
    <http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
    <http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
    <http://www.badweb.org.uk/> For those web sites you hate
     

  7. Easy answer. UID. Make the select/reject criteria the structure of
    your data string(s), not the format you store it with.

    That way a read of a similar code would still get rejected by your
    inventory control software due to having an incorrect data structure.

    Only proper 'good' codes get accepted by your read software.
     
  8. Paradox was cool. Still would be were it still around.
     
  9. D Yuniskis

    D Yuniskis Guest

    Hi Robert,

    Yes, as I mentioned elsewhere: "9's complement"
    But, this means I need to be able to get the scanner to
    pass "bad data" to the application (many scanners would
    just flag this as a bad read and you wouldn't see the
    data at all).
     
  10. Walter Banks

    Walter Banks Guest

    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.


    Regards,


    Walter..
     
  11. D Yuniskis

    D Yuniskis Guest

    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")
     
  12. D Yuniskis

    D Yuniskis Guest

    Hi Walter,

    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)
     
  13. Walter Banks

    Walter Banks Guest

    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.

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

    Tony Guest

    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.
     
  15. D Yuniskis

    D Yuniskis Guest

    Hi Walter,

    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.
     
  16. D Yuniskis

    D Yuniskis Guest

    Hi Tony,
    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]
     
  17. Walter Banks

    Walter Banks Guest

    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..
     
  18. D Yuniskis

    D Yuniskis Guest

    Hi Walter,

    Walter Banks wrote:

    [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. <:)
    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" :-/
     
  19. Walter Banks

    Walter Banks Guest

    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..
     
  20. D Yuniskis

    D Yuniskis Guest

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

    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)
     
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day

-