Printing a label and writing the chip in the same pass

For most of this year my job has been software. Recently a chunk of it became labels: designing them, printing them, and encoding the chip inside them. I did not expect to enjoy this, and I did not expect it to be as fiddly as it is.

Here is the thing that took me a while to internalise. An RFID label is not a sticker with a tag stuck on afterwards. The inlay, the little antenna and chip, is already sandwiched inside the label stock when it comes off the roll. So when you send a job to the printer, two separate things have to happen to the same piece of material: the printhead burns the artwork onto the face, and an encoder inside the printer writes the EPC to the chip. Both have to work. Either can fail by itself.

The artwork half

Thermal transfer printing is closer to a rubber stamp than to an inkjet. A ribbon sits between the printhead and the label, the head heats up in the shape you want, and the wax or resin transfers across. Nothing is sprayed. That has consequences for design that took me a few ruined rolls to learn.

Grey does not exist. The head is either hot or it is not, so every pixel is black or nothing. A logo with a soft gradient comes out as a muddy dither pattern that looks like a fax from 1997. If the artwork has any tonal work in it, you convert it to 1-bit yourself, deliberately, and choose the dithering, or the driver will choose badly for you.

Thin lines vanish. Below about 0.3 mm a line either disappears or comes out ragged, because the dots are that size and the label is moving while they fire. Small text has the same problem, made worse if you print at 203 dpi instead of 300.

And the label is only as flat as the surface you stick it to. A perfectly nice layout that wraps around a curved crate handle becomes unreadable, because the barcode is now a barcode on a cylinder.

The chip half

The encoding side has its own failure mode, and it is the one that costs money.

When the printer writes the EPC, it does it at a very specific position where the encoder antenna sits. If the write fails, on a good printer the label is marked void, usually with a black bar across it, and the printer feeds and tries again on the next one. So a bad batch does not just produce bad labels. It eats the roll.

Writes fail for boring physical reasons. The inlay is not where the printer thinks it is, because the roll was loaded slightly off. The encoder power is too high and it is writing to the next label along as well as this one. Or the labels are simply too close together for the printer's encoder to isolate one chip, which is a spec problem you cannot fix in software.

The fix is almost always calibration rather than cleverness. Let the printer find the inlay position on the roll, set the encode power down until it writes exactly one tag, and then leave it alone.

What I actually use

Layout happens in Labelsoft or Bartender, depending on the printer. Both let you put the RFID encoding on the label as a field alongside the text and barcode, which is the right mental model: the EPC is another thing printed onto that label, it just happens to be printed with radio instead of heat.

For the artwork itself I have ended up using CorelDRAW most of the time, with Inkscape when I want something quick and vector and free, and Affinity when I am doing anything image heavy. I learnt the basics of all three this year for exactly this reason. Coming from Figma, the adjustment is that these are print tools: they care about millimetres, bleed and CMYK, not about breakpoints.

Why an engineer should care

I could have handed this to a designer and gone back to writing TypeScript. I am glad I did not, for one reason.

Our software writes EPCs. It decides the numbering scheme, it validates the format, it tells the operator when a tag reads wrong. Before this I thought of an EPC as a string in a database. Now I know what it costs to get that string onto a chip, how often it fails, and what it looks like when a whole roll comes out void because someone changed the label size and nobody recalibrated.

That has changed how I build the software around it. There is now a lot more validation before a print job goes out, and the error messages say things like "encoder power may be too high" instead of "write failed".

The general version of that lesson: if your code drives a physical machine, spend a day operating the machine.