What is actually inside the Data Matrix

The small square printed on a medicine carton is a GS1 Data Matrix. People tend to think of it as a picture of a serial number. It is really a structured string, and once you understand that string, most of what goes right and wrong on a serialisation line starts to make sense.

The four fields

The European unique identifier carries four elements. Each one is introduced by a GS1 Application Identifier, a two-digit prefix that tells the reader what the following characters mean.

• (01) GTIN: the product code. Fixed length, 14 digits.
• (21) Serial number: the unique part. Variable length, up to 20 characters.
• (10) Batch or lot: variable length, up to 20 characters.
• (17) Expiry date: fixed length, YYMMDD.

Some Member States add a national reimbursement number, and plenty of markets outside the EU use a different set altogether.

The character that causes the most trouble

Fixed-length fields need no terminator: a reader knows a GTIN is 14 digits and an expiry is six. Variable-length fields do. In the symbol they are ended by the FNC1 function character, which a scanner passes on as the group separator, ASCII 29, often shown as <GS>. You cannot see it.

That one character is behind a surprising number of integration incidents. It does not show in a text editor. Some middleware strips it. It gets mangled when someone copies a code through a spreadsheet during testing. A string can look perfect on screen and still be structurally invalid, and the failure only shows up when a partner’s system parses it, possibly months later and a border away.

If you keep one habit from this article, make it this one: validate the parsed fields, never the concatenated string. A test that compares text will happily pass data that a scanner cannot decode.

Print quality is a measured grade

A Data Matrix is not simply readable or unreadable. Its print quality is graded against ISO/IEC 15415 on a set of parameters (symbol contrast, modulation, reflectance margin, fixed pattern damage, axial and grid non-uniformity, unused error correction, print growth among them), and the overall grade runs from A (4.0) down to F (0.0).

Two consequences follow, and both end up as commercial problems rather than technical ones.

First, a grade C code reads today and may fail tomorrow. Data Matrix carries Reed-Solomon error correction, so a degraded code keeps decoding, right up to the moment it stops. The unused error correction parameter is your early warning. It tells you how much margin is left before the code starts failing in the field, at a wholesaler, with the pallet already delivered.

Second, your grade is not your customer’s grade. The code is graded at your line, under your lighting, on fresh cartons. Downstream it will be read on a worn handheld, under warehouse strip lights, on a carton that has spent a week in a lorry. Aiming for B at the line is not over-caution; that margin is what lets the downstream reads succeed.

What actually degrades a code

The causes we come across most often are fairly mundane.

Substrate and finish come first. A glossy varnish reflects the illumination straight back into the camera and kills contrast, and a recycled board with visible fibre breaks up the module edges. Both are decided in packaging development, long before anyone thinks about the line.

Then print resolution against module size. The printer has to place whole modules. When the module size is not a clean multiple of the print resolution, edges wander and axial non-uniformity pulls the grade down.

Ribbon or ink ageing is the slow one. Grades drift down over a ribbon’s life, so a single verification at qualification says nothing about hour six of a shift. And line speed matters: a carton still moving relative to the print head gets a skewed code. The vision system sees it; the grade tells you why.

Reading and grading are different jobs

A code reader gives a verdict: decoded, or not. A verification system gives a grade. They are not interchangeable, and a line that only reads has no early warning at all. It finds out about degradation when packs start being rejected, which is the most expensive moment to find out.

The sensible set-up is to read every pack and grade a sample continuously, trending the grade over the batch rather than writing it down once. A trend that slopes downward across a shift usually points to a consumable or a mechanical problem, and you can see it days before it turns into a spike of rejects.

For qualification

Three things are worth insisting on in the protocol.

1. Challenge tests with deliberately bad codes. A vision system that has only ever seen good codes has not been tested. Print a set at graded quality levels and prove the system rejects what it should.
2. Reject verification. Prove that what was rejected physically left the line, and that its serial number was recorded as rejected. A pack rejected in the data but still sitting on the conveyor is worse than no rejection at all.
3. Grade trending, not a single snapshot. One grade A reading at OQ shows the line can print well. It does not show that it will still be printing well in month eight.

References

• GS1 General Specifications. Application Identifiers, FNC1 and the GS1 Data Matrix
• Commission Delegated Regulation (EU) 2016/161, the fields the European unique identifier must carry