UHF RFID Tag Encoding Best Practices: EPC, TID and Lock Bits Done Right

Encoding is the step where an RFID project quietly succeeds or fails. The readers can be perfect, the antennas optimal and the middleware elegant, but if the EPC written to each tag is not unique, not stable and not verifiable, every downstream number becomes fiction.

The good news is that encoding is a deterministic process. Four decisions, applied in a fixed order, remove almost all of the risk.

What should the EPC schema actually contain?

The EPC should identify the physical item and nothing that changes during its life. Design the schema before the first tag is written, because changing it later means rewriting live inventory.

• Use the SGTIN-96 pattern as the default: company prefix, item reference, serial number. It is globally unique and every Gen2 reader understands it.
• Keep the scheme at or below 96 bits unless you have a specific reason; longer EPCs are slower to read and less universally supported.
• Never encode warehouse location, owner or status into the EPC. Those change, and a tag cannot change with them at warehouse speed.
• Decide the company prefix length with GS1 before ordering tags; a prefix that is one digit too short limits the serial range forever.
• Reserve a documented block for the serial number and never reuse a serial, even after an item is retired.

Write the schema down as a table with field, bit range and example value. Encoding errors usually trace back to a schema that existed only in someone's head.

Why does TID verification matter more than EPC verification?

Reading back the EPC proves that the write landed in the right memory bank. Reading the TID proves the tag is the one you think it is.

• The TID bank is factory-programmed and, on most Gen2 chips, permanently locked, so it is the only trustworthy identity anchor.
• Verify that the TID is non-zero, unique across the batch, and matches the chip vendor and model you specified.
• Some counterfeit or downgraded inlays present a TID that looks valid but does not match the datasheet mask; a mask check catches this in seconds.
• Store TID alongside EPC in the middleware. When an EPC is later misread, the TID tells you whether it is the same physical tag.
• Reject any tag whose TID cannot be read; a tag you cannot identify is not worth applying.

In what order should the memory banks be locked?

Locking is irreversible. Sequence it so that a mistake costs one tag, not the whole batch.

• Write the EPC and the optional user memory first, then verify both by reading back.
• Lock the EPC bank only after verification passes, and only if the application truly requires immutability.
• Leave the user memory unlocked when it carries data that operations may need to correct, such as a batch or expiry date.
• Protect the access and kill passwords before locking anything else, and store the passwords in the middleware, not on paper.
• Never lock during a pilot. Locking belongs to the production run, after the schema is frozen.

For retail and logistics, most deployments lock the EPC bank and leave user memory writable. For regulated goods, user memory may need to stay writable for the entire shelf life.

What does a verification pass actually check?

A verification pass is not "did the printer beep". It is a scripted read-back with a defined failure action.

• Read EPC, TID and user memory from every tag on the roll, not from a sample.
• Compare the EPC against the expected sequence, so gaps and duplicates are caught immediately.
• Confirm the TID is present, unique in the run, and consistent with the ordered chip type.
• Confirm locked banks reject a test write, which proves the lock actually took effect.
• Record pass, fail and rework counts per roll, and keep the log with the batch record.

A roll that fails more than a small percentage should be quarantined rather than hand-corrected on the line. Hand correction is where duplicate EPCs are born.

Which encoder and printer settings cause silent failures?

Most encoding defects are settings, not hardware faults, and they fail silently because the printer still prints.

• Power set too low writes intermittently; the label looks correct and reads fine at 10 cm but not at 3 m.
• Power set too high damages the inlay on thin labels, producing tags that read once and then die.
• Wrong label calibration shifts the write position, so the encoder writes to the gap instead of the inlay.
• Ribbon and inlay mismatch shows up as faded print with a perfectly valid EPC, hiding the real problem from the operator.
• Verifying with a handheld instead of an integrated verifier misses marginal tags that will fail at the dock door.

Set power from the inlay datasheet, then prove it with a read-range test at the distance your portal actually uses.

How do you keep encoding quality stable over months?

Encoding quality drifts. It drifts when the operator changes, when the label lot changes, and when the printer is serviced.

• Run a five-tag read-range check at the start of every shift, and log the result.
• Audit a full roll against the EPC sequence once per lot, not once per project.
• Compare TID vendor masks when a new label lot arrives, because suppliers do substitute chips.
• Keep a known-good reference tag at the station and read it before production runs.
• Treat every duplicate EPC alert as an incident with a root cause, not as a nuisance to clear.

Bottom line

Encoding is where uniqueness is either guaranteed or lost, and no amount of middleware can recover a duplicated EPC.

• Design the EPC schema first, keep it at 96 bits, and never encode mutable attributes.
• Verify TID as well as EPC, because TID is the only factory-anchored identity.
• Lock last, after verification, and never during the pilot.
• Prove encoding quality with periodic read-range tests, not with a printer beep.

If the encoding step is documented, owned and audited, the rest of the RFID project gets a stable foundation. If it is informal, every other investment inherits a data problem it cannot fix.