Faster 1D barcode detection on embedded smart cameras

An embedded smart camera that spends most of its frame decoding a barcode is not under-powered; it is over-tasked. A 1D decoder re-tests every pixel row for every symbology it has enabled, so the cost of a read grows with ROI height and symbology count rather than with the code itself. This guide is for engineers putting 1D reads on AGVs, carts and inline stations where decoding runs on the camera. You will compute the pixels-per-module budget, set an ROI band a few dozen pixels tall, cut the enabled symbology set to the one family your plant prints, and predict the frame-rate gain from a single timing log. When the numbers still fall short, the same arithmetic tells you it is time for a dedicated code reader instead of more tuning.

Why does a 1D barcode slow an embedded camera down?

A 1D decoder scans every pixel row of the ROI once per enabled symbology: with the dozen-odd symbologies many embedded builds enable by default, a 480-row VGA frame costs about 480 × 16 ≈ 7,700 row-scans before the picture has been fully tested.

A 1D symbol carries no finder pattern. The decoder therefore walks the ROI row by row, testing each row against the start and guard patterns of every enabled family, and a row that matches nothing costs the same as a row that decodes. The passes share nothing: Code 128 guard structure tells the decoder nothing about an Interleaved 2 of 5 pattern three rows lower. Open-source decoder libraries commonly used on embedded boards ship with the common set enabled — EAN/UPC, Code 39, Code 128, Interleaved 2 of 5 and more — so the default is the expensive configuration.

The two multipliers multiply each other. Halving ROI height halves the scan work; enabling one family instead of a dozen divides it again. That is the whole mechanism, and it is why a tightened window lifts read rates on standard readers too — Setting an ROI for inline code reading: speed and reliability gains covers that side of the same trade.

2D decoders do not behave this way: a QR or DataMatrix decoder localizes a finder pattern first and then decodes a block, so cost tracks symbol area rather than row count. The levers below are specific to row-by-row 1D decoding.

What do you need before you touch the settings?

Write down four things first: the symbology family your plant prints, the narrow-bar width X in millimetres, the mount geometry as working distance and worst-case tilt, and a way to time frames — a per-frame decode log beats any stopwatch.

• Symbology and check character, so exactly one family survives in the job. A mixed line needs both families named; anything unnamed stays off.
• X dimension in mm, because the pixels-per-module target and the exposure limit both hang off it.
• Working distance, worst-case tilt and placement error, because they set ROI height and depth-of-field margin.
• A timing method — decode milliseconds per frame — so the gain is measured rather than felt.

How do you set the job up step by step?

Work in this order — symbology first, ROI second, pixels per module third, exposure fourth, verification last — because each step multiplies the gain of the one before it, and a later step cannot rescue an earlier one.

1. Enable one symbology family. In the reader job's symbology settings, disable every family your plant does not print; if labels can arrive as either of two families, enable exactly those two. One reversible setting divides decoder work by the number of families switched off.
2. Compute the field of view and millimetres per pixel from sensor width, working distance and focal length, with the lens focal length calculator or the formulas in the next section.
3. Check pixels per module: at least 2, target 3-4. If the number is low, fix it with working distance or focal length, not with software upscaling, which cannot recreate edges the sensor never captured.
4. Set the ROI height. If a fixture holds the label, centre a 40-80 px band across the bars; if placement varies, take the code's pixel height plus a tilt margin of code width × tan(maximum tilt).
5. Pin the exposure. Keep motion blur under a third of a module: exposure time ≤ 0.3 × X ÷ travel speed. At AGV speeds this means sub-millisecond shutters, so add light or gain to hold bar contrast.
6. Log 100 frames before and after — decode milliseconds and frame rate — so the next decision rests on numbers.

What does the arithmetic look like for a floor-label reader?

For a 1/2.9-inch, 1920 × 1080 sensor with a 12 mm lens working 150 mm above a floor label, the field of view is 70 mm wide, the pixel pitch 0.0365 mm, and a 0.25 mm Code 128 lands at 6.9 pixels per module — comfortable decode territory.

Worked example — illustrative inputs; your own log supplies the frame split:

• Sensor: 1/2.9-inch format, 1920 × 1080, active width about 5.6 mm (typical for the class; use your sensor's exact figure).
• Geometry: 12 mm lens, label 150 mm below. FOV = 5.6 × 150 / 12 = 70 mm. mm per pixel = 70 / 1920 = 0.0365.
• Symbol: Code 128, 6 data characters, X = 0.25 mm. Modules: 11 start + 6 × 11 data + 11 check + 13 stop = 101, so 25.25 mm of bars and about 30.3 mm with 10X quiet zones.
• Pixels per module = 0.25 × 1920 / 70 = 6.9. Code width ≈ 30.3 / 0.0365 ≈ 830 px; a 12 mm printed label height is 329 px.
• ROI: a 48 px band centred on the bars absorbs ±10 px of placement error, and ±2° of tilt slides bar edges 830 × tan 2° ≈ 29 px across the width — well inside the 329 px bar height.
• Decoder work: 1080 × 16 = 17,280 row-scans before, 48 × 1 = 48 after — a 360× reduction.
• Frame budget: suppose the log shows 100 ms per frame (10 fps), split 15 ms capture and output, 70 ms decode, 15 ms row-wise preprocessing. After the change: decode 70 / 360 ≈ 0.2 ms, preprocessing 15 / 22.5 ≈ 0.7 ms (1080 / 48 = 22.5× fewer rows), total ≈ 15.9 ms ≈ 63 fps. The 60 fps sensor cap then sets the real limit — roughly a six-fold gain from 10 fps.

The 360× is the physics; the 70/15/15 split is an example, and your own log turns the same formula into your prediction. The calculator below runs the FOV step and points at matching lenses:

How many pixels per bar does a 1D decoder need?

Two pixels per narrowest bar is the floor and three to four is the comfortable target: at exactly 2 px per module, one blurred or mis-printed edge can consume half a module, which is where intermittent 1D failures begin.

Above the target, extra pixels per module stop buying reliability: 6.9 px per module in the worked example is already generous, and doubling it only shrinks the field of view. Below the floor, decoders cannot separate the 1-2 module intercharacter gaps Code 128 depends on, and reads fail intermittently rather than cleanly. Budget the quiet zones too — 10X of blank label at each end, which is where the extra 5 mm in the example went — and keep total smear, optical plus motion, under a third of a module. Code 128 barcode module size, reading angle and reader distance works this pixel budget for that symbology in detail.

What if the firmware cannot turn symbologies off?

Then the row term is your only lever, and it still pays: cutting a 1080-row frame to a 48 px band removes 95.6% of the row-scans, worth roughly 4-11× the frame rate on a decode-bound unit (Amdahl with decode share p = 0.8-0.95: 1 / ((1 − p) + p/22.5)).

Fixed builds exist, especially on hobby-class and single-purpose boards where the symbology set is compiled in rather than exposed as a job setting. Three legitimate paths remain. First, the band plus presentation discipline — most of the win is the row term anyway. Second, make per-symbology enablement an explicit selection question when you buy: it belongs in the job settings of a code reader or smart camera, and a candidate that cannot answer it is a reason to keep looking. Third, move decode off the camera — grab frames on the device, decode on a controller — and accept the bandwidth and latency cost; Barcode detection pipeline fallbacks: why commercial readers win explains why dedicated decode pipelines tend to win that trade. If the platform for the rest of the cell is still being chosen, selecting embedded control software for faster delivery weighs the same headroom-against-schedule questions.

Which should carry the job — a smart camera or a code reader?

Put the job on a smart camera when the device also does line following, presence or guidance, and on a dedicated fixed code reader when codes are the only job, because readers trade generality for stated decode rates and tighter decode pipelines.

A vision sensor keeps decoding on the device and leaves headroom for the second job. The MV-SCB007EC-12S-WBN pairs a 12 mm manual-focus lens with a 1.6 MP color global-shutter sensor on Fast Ethernet — the 12 mm geometry the worked example assumed.

Where the frame-rate ceiling should be stated rather than benchmarked, the LS-SMC-0063 publishes 60 fps with a 16 mm lens and white light.

When codes are the whole job, a fixed code reader dedicates its processor to decoding and states the outcome as a rate. The LS-CRD-0028 states 60 codes/s from a 2560 × 2048 frame with an 8 mm lens.

Close fixed mounts with glare suit the MV-IDB005EXI-05NRP, which focuses at 70 mm with a 4.63 mm lens and a polarized front.

Both ranges sit in the camera finder; the smart cameras and fixed code readers category pages hold the rest of the field. Size lens, distance and lighting together in the system configurator before ordering — the ROI band is free, the geometry is not.

How do you verify the gain and catch the real bottleneck?

Log at least 100 frames before and after and split one frame into capture, decode and output: decode below a third of the frame means ROI tuning is done, while a rate still short of demand with decode above half sends the job to a dedicated reader.

Log these, per frame:

• Decode milliseconds, so the decode share is measured, not guessed.
• Frame rate at the job's real duty cycle, including idle time between triggers.
• Decode confidence per read — Barcode read confidence: how to judge whether a decode is trustworthy — so speed is not bought with silent misreads.
• Behaviour on the worst label in the batch, lowest print grade and most glare; 1D barcode preprocessing for rotation, blur and glare covers the image-side fixes.

Four mistakes eat the gain:

• An ROI so tight that 2° of tilt drops part of the code out of it — the tilt margin exists for this.
• A window that crops the quiet zones; decodes turn intermittent, and intermittent reads masquerade as a speed problem.
• Auto-exposure stretching shutter time in dark corners of the frame; fix the exposure and add light instead.
• A rolling-shutter sensor on a moving cart, which shears rows during travel; a global shutter avoids it.

Reading on a moving line rather than a moving cart changes the geometry, not the arithmetic; High speed conveyor barcode reading: choose the reader and setup walks that variant.

What is the decision for each case?

Enable one symbology family and set a 40-80 px band ROI first — the change costs nothing and reverses in one setting — and in the worked example's budget it alone takes a decode-bound unit from 10 fps to its 60 fps sensor cap.

• Decode-bound smart camera with selectable symbologies: make both changes, then stop when the sensor's frame-rate cap is reached — about 63 fps computed, 60 delivered in the example.
• Symbology set compiled in: band ROI only, worth roughly 4-11×; if that is still short, buy symbology-selectable hardware rather than re-tuning blind.
• Decode below a third of the frame after tuning: the bottleneck has moved to exposure, transfer or the output handshake — fix that stage; the ROI work is finished.
• Still short of line demand with decode above half: the job belongs on a dedicated fixed code reader with a stated codes/s rate.
• A 1D symbol is a pointer into your database, not a data container; if the string must travel with the part, step up to a 2D symbology and budget a slower decode or a 2D-capable reader.

More worked code-reading setups are on the code-reading topic page. Send the symbology, X dimension and a sketch of the mount through the contact page and we will check the pixels-per-module budget and the ROI band with you — free expert support comes with every order.