Upgrading a 1D fleet to 2D and QR: which stations actually have to change?

Time：2026-10-09 Views：0

Nobody in your plant decided to go 2D. A supplier started marking parts, a regulator started requiring a unit-level code, a brand put a QR on the pack, and the codes arrive at stations whose readers were bought against a code type that no longer covers what is in front of them. That is a programme decision, not a device decision, with three parts: what the physics allows, which code streams you must satisfy, and how many device classes a site can support without the maintenance bill doubling.

One fact organises everything else. The upgrade is one-way. A 2D imaging reader decodes 1D symbols as a side effect of seeing a picture, so it covers your existing stream. A 1D-only reader cannot be talked into decoding a matrix code, no matter what the firmware version is. Everything after that — phasing, budget, spares — is scheduling around a boundary you cannot engineer away.

Why a 1D-only reader cannot take the step

A laser reader is a single-point instrument. A diode, a sweeping mirror or faceted holographic element, and one photodiode that returns one continuous waveform: bright and dark as a function of time along one line. A linear imager is the same idea with photodiodes lined up in a row instead of swept past the symbol — still one line of samples, still no second dimension.

A matrix code is not a pattern along a line. Its information is the arrangement of modules in a grid: the finder and timing structures tell the decoder where the symbol is and how it is rotated, and the data lives in the two-dimensional positions of the modules themselves. A single scanline through a QR symbol produces a sequence of light and dark that is consistent with a great many different grids, which is why it decodes nothing. No update adds the missing measurement, because the sensor never captured it. That is physics, not a licence level.

Two honest nuances belong here, because they are where suppliers get away with vague wording. First, stacked symbols such as PDF417 and microPDF are built so a linear device can read them, and whether a given reader does is a firmware and optics question — so a device marketed as "1D" may or may not take a stacked code, and only the symbology list settles it. Second, a 2D imager is the general case but not automatically the better one everywhere: at extreme stand-off on narrow linear symbols, purpose-built 1D optics still hold an advantage, which is why sites with very long reach — dock faces, high-rack aisles — check the resolution and range lines before assuming one class covers both jobs.

What brings 2D into a site built for 1D

The trigger is almost always external, and it usually arrives with somebody else's timetable.

What appears in your operation	Why it arrives	What it demands optically	What it does to your fleet
DataMatrix on small metal or plastic parts	Part miniaturisation, and direct part marking instead of adhesive labels that fail in wash and heat cycles	Small modules on a low-contrast, reflective surface, at close range	A different device class at those stations — magnification and illumination geometry, not a settings change
QR and 2D codes on consumer packaging	Brands moving identification and product data into a web-address-bearing code	Larger symbols, but printed on film and cartons at variable quality	Most general-purpose 2D imagers cope; the change is in what the decoded string is, not in the optics
PDF417 and stacked codes on documents and IDs	Identity and routing data packed into a printed document	Enough vertical coverage to see all rows, and tolerance of folded, creased paper	Frequently a firmware-list question for existing linear devices, or a document reader at that station
Serialized 2D on regulated goods	Unit-level traceability regimes for medicines and medical devices, carrying identifier, serial, batch and expiry in one symbol	Reliable first-attempt reads on small printed DataMatrix, at line geometry	A validation and read-rate problem, plus new devices at every point the unit code is touched
More content in one code	Lot, serial, date, GTIN and asset attributes that would need several linear symbols	Same optics, but a 2D matrix rather than a stack of labels	Fewer scan events per item, and a hard stop for 1D-only readers
Electronic labelling	Printed text shrinks and content moves into a data-carrier code	The remaining printed code becomes smaller and denser	Resolution class rises at stations that never needed it before

The retail case is the one to watch, because it moves the largest code stream in consumer trade: GS1 Digital Link puts the identification data a linear symbol carries into a web-address-bearing QR, so the scanned string stops being a short product number and becomes data your system has to route.

The reason this table matters is that each row has a different owner. Serialization comes from a regulator, packaging codes from a brand, direct marking from a design department, and a stacked document code from the paper your receiving clerk is holding. The purchasing schedule has to be built from the streams that can change without telling you, and the notice period for those is usually the length of a product launch.

The resolution arithmetic, done at fleet level

The comparison that decides the budget is between the new code's module size and the existing device's optics, and it has three terms.

and imaging grading under ISO/IEC 15415 works the same way on a 2D symbol. A 0.25 mm-module DataMatrix demands that the device resolve that element; a general-purpose reader whose best case is around three times that will simply never see it.

more on degraded print — which is what converts "resolves in the lab" into "reads your worst label on Monday".

other in the lens. A device optimised to read a 40 mm marking on a machined part at arm's length cannot also read a pallet label at four metres, and no single SKU in the middle of those two designs does both well.

Element size against aperture. Linear grading practice expresses a reader's capability as the narrowest element it can resolve,
Pixels across the module. As a starting point, a decoder needs at least two samples across the narrowest module and comfortably
Field of view and depth of field against working distance. Resolution, reach and tolerance of distance error trade against each

The conclusion buyers do not expect: small-module 2D forces a different device class, not a settings change. That is why fixed-mount scanners exist as a catalogue line at all — a marking read on a machined part is a magnification, illumination and triggering problem, and reading it on a moving belt at line speed is a separate discipline again; the site's IP67 fixed-mount reader for fast-moving codes on a conveyor belt and the industrial barcode scanner category describe that class, and this article stays with the fleet decision.

Do the arithmetic per station, not per department. A department-level "we need 2D scanners" line item is what produces a purchase of sixty general-purpose readers that still fail on the twelve marked parts.

The symbology survey that must happen before you request quotes

Requesting quotes before you know what you actually scan guarantees an argument with yourself later. The survey is a day of walking and an hour of sorting.

What to collect at each scan point	How to record it	What it decides in the RFQ
Every code the station really reads	Photograph each one in situ, do not copy the string	The symbology list the device must carry
Smallest code on site, and the most damaged	Macro photograph with a scale reference; keep the physical sample	The resolution class and the print-quality tolerance
Direct-marked parts, if any	Photograph on the part, in the station's own light	Whether that station needs a different device class at all
Typical and maximum working distance	Measure it; note whether the code is in hand, on a bench, on a rack or on a screen	Optics: field of view, depth of field, aiming arrangement
Surface and environment	Metal, film, cardboard, laminate, shrink-wrap, outdoor, cold store	Illumination geometry, ambient light immunity, sealing class
Who owns the code, and can it change	Name the supplier, brand or regulator; note the notice period	Which stations are on borrowed time and get scheduled first
Scan volume and shift pattern	Reads per hour at peak, one operator or three	Duty cycle, battery and dock architecture, spares depth

Walk the site on a normal shift, not a prepared one: the codes that break a fleet are the ones that only appear on inbound from two specific suppliers, and a quiet-week survey misses them.

Three honest replacement strategies

Replace everything. Highest capital outlay, lowest support load, and it removes the standing risk that a supplier-controlled code migrates without notice. It is right when the site is small, the fleet is already near end of life, or the survey finds that every station touches a stream somebody else owns.

Buy 2D only where the new codes appear, keep 1D at the old stations. Usually cheapest, and genuinely correct where the codes at a station are yours — internal location labels and bin cards are printed by you, so you can decide they stay linear forever. The exposure is every station where somebody else's paper arrives: a receiving dock is not an internal station, and a supplier's label revision will reach it before it reaches your planning meeting. If you choose this route, write the risk down station by station, and keep one 2D device per shift as the fallback reader for the code that turns up unexpectedly.

Hybrid devices everywhere. Worth being precise about, because the marketing word means two different things. Symbology-wise, a 2D imager already is the hybrid: it reads your linear codes and the new matrix codes, which is why it is the default replacement unit. The other sense — a handle carrying both a long-reach laser and a close-range imager — is real but niche, and it buys that capability with two optical systems to align, seal, service and re-order. The genuine hybrid question at your site is not which symbologies but which resolution and reach class each station gets.

Whichever you pick, replace per code stream, not per department or per building, and treat every 1D-only device within reach of an externally owned code as scheduled rather than as working.

Spares, standardisation and the bill a mixed fleet creates

Support cost scales with the number of distinct device families, not with the number of devices. Each family brings its own dock and cradle, cable set, spare pool, configuration profile, spare window or glass, and its own version of "how do I get this back to a known state". Ten readers of two types is a manageable maintenance shelf; ten readers of five types is the reason a site's spares cupboard costs more than the original purchase.

The practical rules: cap the number of handheld families you will carry through a refresh, insist that new purchases match an existing dock and accessory set rather than introducing one, retire a family on a stated date instead of letting it drift, and keep the older 1D-only units by re-sorting them into stations the survey proved are permanently linear — which is how a fleet shrinks in cost without shrinking in coverage. The same logic applies one level down: the scan engine inside a device has its own lifecycle, and a reader family whose engine is discontinued is a spares problem you will discover late. For finished handhelds, the handheld barcode scanner catalogue lists models that read 1D and 2D together — for example W41-10, titled a wireless portable 2.4G Wi-Fi/Bluetooth "1D 2D QR" cordless warehouse handheld scanner — which is the standardisation option in hardware form: one family covering both streams keeps the accessory and spare pool single.

Standardising on one or two device classes is normally sourced as an OEM/ODM programme; the factory describes quantities from 100 units, roughly fifteen-day samples and thirty-day series production, which is what makes a phased rollout schedulers can plan against — OEM/ODM for the programme, and product documentation for the spec sheets your maintenance team will want.

Decision table: trigger, consequence, cheapest workable response

Trigger for the change	What it forces	Cheapest workable response
A supplier adds a DataMatrix to delivered components	Every station that receives those components must decode matrix codes	2D imager at inbound stations plus one mobile fallback unit per shift
Small metal parts get directly marked instead of labelled	Module size drops, contrast drops, working distance shrinks	A close-range / magnified reader class at that station — not another handheld
A regulated line comes under serialization and aggregation	First-attempt read rate becomes a validated, documented number	Devices at the code's size and geometry, then timing and rejection handling designed at line level
A brand puts a QR carrying a web address on retail packs	The decoded string is a long URI rather than a short number	2D readers where the pack is scanned, and a decision about where that string is meant to go
Labels shrink because of electronic labelling or pack redesign	Element size falls below what current optics resolve	Resolution class raised station by station, starting where the smallest labels land
Codes arrive on a phone or terminal screen instead of paper	Inverted, low-contrast, refreshed display with glare	Imaging readers specified for screen codes, tested on the actual device
Linear-only work at long reach continues unchanged	Nothing — for now	Keep the existing device, but record it as externally exposed if any inbound code reaches it

FAQ

Can a 1D barcode scanner read a 2D or QR code? No, and it is not a matter of licensing or firmware: a 1D laser reader samples one line of reflected light and a linear imager samples one row of pixels, so neither captures the two-dimensional arrangement of modules that a QR or DataMatrix symbol stores, which is why decoding matrix codes requires an imaging sensor and why the phrase "1D-only" on a specification is a hard boundary rather than a soft one.

What is the difference between a 1D and a 2D barcode? A 1D symbol encodes data in the widths and spacing of parallel bars along a single axis and holds a short string, while a 2D symbol encodes data in light and dark modules arranged in a grid, so it carries substantially more information in a smaller area, survives orientation changes and tolerates damage better through error correction — one DataMatrix can hold a product identifier, serial, batch and expiry where the linear equivalent needs several codes and label room the pack does not have.

Do I have to replace every 1D scanner when 2D codes appear? No — a 2D imaging reader decodes your existing linear symbols, so the upgrade runs in one direction, and the defensible position is to replace at the stations the code survey proves are touched by an externally owned code stream while keeping proven linear-only devices at stations whose codes you print yourself, because replacing the entire fleet buys capability you will never use in those locations.

How do I know which stations need a new 2D device class rather than a settings change? Because it comes down to the arithmetic between the smallest module you must now read and each installed device's resolution and depth of field: where the element size falls below what the optics resolve, or the working distance outside the depth of field, no configuration fixes it and the station needs a different device class, while a code that is only a different symbology inside the same reach envelope is usually a symbology-list question on the device you already own.