Code 128 codeset B length limits: why long labels fail to read

A reader that decodes a five-character codeset B label on every trigger, then rejects a fifteen-character label from the same printer, is not at its hardware limit. Code 128 defines no data-character maximum, so the ceiling is almost always the length range configured in the reader, the read window drawn around the symbol, or the pixel budget across a code that has just doubled in width. The two labels used below are illustrative inputs: a five-character code such as F2781 and a fifteen-character code such as LJ5506000160305, both valid in codeset B. You will get the module arithmetic for any label length, the tests that separate a configured limit from an optical one, ordered by probability, and the fix for each case.

Sort the symptom before you change anything

One or two triggers separate the three causes. Match what you see against this table, then run the matching test from the list further down.

A clean step at a character count points at settings. A gradual loss with distance points at optics. Mixing the two up costs a day of lens swapping that fixes nothing.

How wide a codeset B symbol really is

Code 128, defined in ISO/IEC 15417, builds every symbol from 11-module characters: one start character, one character per data character, a mandatory check character, and a stop character of 13 modules. Codeset B is one of three start codes and carries ASCII 32 to 127, so a mixed letter-and-digit string such as a 15-character serial stays in a single codeset. USS-128 is the legacy name for the same symbology; GS1-128 is the logistics subset that carries application identifiers. The Code 128 structure and character tables are worth one skim; the module count below is all this fault needs.

Run the two example labels through it. F2781 carries 5 data characters: 11 x 5 + 35 = 90 encoded modules, and with the minimum 10-module quiet zone each side the print spans 110 modules. LJ5506000160305 carries 15: 11 x 15 + 35 = 200 encoded modules, or 220 with quiet zones. At a module width of 0.25 mm the short label prints 110 x 0.25 mm = 27.5 mm wide; the long one prints 220 x 0.25 mm = 55 mm. The long label is exactly twice the width of the short one, which is why the failure arrives as a step and not as a drift.

For the optics-side counterpart of this arithmetic — module size against reading angle and distance — see Code 128 barcode module size, reading angle and reader distance.

Cause 1, most likely: the configured length range

Every industrial reader exposes a Code 128 length parameter, usually as any length, one or two discrete lengths, or a minimum and maximum pair. Defaults differ: some scan engines ship with a 32-character ceiling, and a range someone tightened for a previous job reproduces this exact symptom — every label above the window fails, every label inside it reads, on unchanged optics and trigger wiring.

The test is one pass. Open the Code 128 symbology settings, set the length to any (or minimum 1, maximum 20), and retrigger on the 15-character label. If the step disappears, you had a configured window and you can stop looking for optical causes.

Do not leave "any" set in production. A length check is the cheapest anti-substitution filter a decoder offers: for a fixed format, set the exact length — 15 in the example — and a truncated print or a stray second format cannot pass. Where several formats share the station, set a tight minimum and maximum instead.

Cause 2: ROI width, quiet zone and trigger timing

A decoder starts a scan only when the full symbol and its quiet margins sit inside the ROI, and the 15-character symbol needs twice the width: 220 modules against 110. Draw the read window around the longest label the station will ever see, not the shortest one it was commissioned with.

Keep 10 modules of quiet zone on each side, inside the ROI. At 0.25 mm that is 2.5 mm of clear label per side; a tight die-cut edge or neighbouring print inside that margin shows up as failures at the trailing characters. The walkthrough on setting an ROI for inline code reading shows how a few pixels of margin move the read rate.

Timing fails the same way. The read window must stay open while all 55 mm of symbol is in view; a trigger on the product body can close before the trailing characters arrive. Where the line detects labels with a photoelectric sensor, pick one that sees the label itself — photoelectric detection of clear labels on glass jars covers the hardest version of that problem.

Cause 3: the pixel budget across 220 modules

The working numbers for image-based 1D decoding are two pixels per module as the floor, three as the target, and five where blur, tilt or soft print eat margin. Under two, decodes fall apart; between two and three you get the occasional-failure pattern that grows with distance — a different signature from the clean length step.

The budget arithmetic is short. A 15-character symbol spans 220 modules, so the three-pixel target asks for 220 x 3 = 660 pixels across the symbol, quiet zones included. At 0.25 mm per module the symbol is 55 mm wide, so the label must be seen at 660 / 55 = 12 pixels per mm. For any sensor and field of view: pixels across the symbol = sensor width x (55 / FOV), and pixels per module = that count / 220.

Run your own stand through that check:

Here it is worked for a compact reader. The LS-CRD-0028 carries a 2560 x 2048 sensor behind an 8 mm lens.

With a 120 mm field of view the symbol occupies 2560 x (55 / 120) = 1173 pixels, which is 1173 / 220 = 5.3 pixels per module — comfortable margin. Widen the field to 250 mm to cover the conveyor and it drops to 2560 x (55 / 250) = 563 pixels, or 2.6 per module — the occasional-failure zone where a length fault gets misdiagnosed. Solved backwards, this sensor holds the three-pixel target as long as the field of view stays at or under 2560 x 55 / 660 = 213 mm.

The same stand on a 1.3 MP class sensor (1280 pixels wide) at a 150 mm field of view gives 1280 x (55 / 150) = 469 pixels across, or 2.1 per module — marginal. When the stand distance is fixed by the line, the fix is more sensor: the MV-ID5120RM-08M-RBN is a 12 MP code reader on GigE.

That is roughly three times the pixels of a 1.3 MP sensor on each axis at a similar aspect ratio, and it turns a 2.1 pixel-per-module stand into a comfortable one. Before buying pixels, confirm the software is not discarding them: downscaling before barcode decoding covers the resize that quietly ruins large modules.

The tests, in order

Each test takes one trigger and eliminates one cause.

1. Confirm the label is clean. Print or keep a 15-character codeset B symbol at the production module size and grade it to ISO/IEC 15416; barcode reader verification for label inspection explains the grade report. A bad label poisons every test after it.
2. Open the length window. Set Code 128 length to any (or 1 to 20) and retrigger. Step gone: the configured window was the fault, and you are done diagnosing.
3. Redraw the ROI. Cover all 220 modules plus 2.5 mm of quiet margin per side at 0.25 mm module width. Trailing characters now read: the read window was the fault.
4. Count the pixels. Grab one image at production conditions, measure ten modules edge to edge, and divide by ten. Two or below: optics. Three or above with failures left: back to settings and timing.
5. Read the logs. Record decode time and confidence over 20 triggers; how to judge barcode read confidence gives the thresholds. A timeout that only bites on long labels points at the read window, not the optics.

The fix for each case

• Configured length window. Set the exact production length (15 for the example format), or a tight minimum and maximum where formats share the station. Decision: never leave a default or "any" in production; own the window.
• ROI or quiet zone. Widen the read window to the longest label plus 10 modules per side, and re-time the trigger to the label edge. Decision: commission the ROI from the longest format the station will ever see.
• Pixel budget. Reach three pixels per module: narrow the field of view, move the stand closer with the focal length to match, or step up the sensor. Decision: 12 pixels per mm on the label for a 15-character, 0.25 mm module format.
• Read window too short. Extend the window and confirm from logs. A reader rated at 60 codes/s such as the LS-CRD-0028 has ample headroom per read. The culprit is almost always a window that closes early, not decode time. Decision: measure decode time first, then add margin.

Spec the station for the longest label

One pass at design time keeps this fault away: compute 11 x N + 35 for the longest format, hold three pixels per module across it, put 10 modules of quiet zone inside the ROI, and set the length window to the format. Grade a production-printed symbol before go-live. For short, fixed stands, compact readers cover it: the MV-ID3013PM-12M-WBN pairs a 12 mm lens with a 1.3 MP sensor, the MV-ID813M-05S-WBN-SR pairs a 4.9 mm lens with white light on GigE, and the LS-CRD-0047 reads at 60-120 mm.

Pick the reader against your longest label, not your shortest: start from the fixed code readers, or smart cameras if one device must inspect and read in the same pass. The camera finder filters by interface, resolution and mount; more decoding fixes sit on the code-reading guides page. If your format is unusual, describe it to us through the contact page and we will work the numbers with you.