EPC Checksums and Read-Back: Proving a Tag Holds What You Wrote

The reader says the write succeeded. That sentence is the most misleading sentence in RFID commissioning, because success means the tag acknowledged a command, not that its memory holds the value you intended.

A successful write command is not proof

Acknowledgement and correctness are different things, and only one of them is reported.

• The status confirms the tag received and executed the command, within the conditions it perceived.
• Movement, marginal power and interference can corrupt the value after the acknowledgement.
• A tag written at the edge of the field can acknowledge and store a partial or shifted value.
• Commissioning errors usually surface weeks later as inventory errors, which cost far more than a second scan.
• Verification is therefore a process step you design, not a checkbox in the reader's settings.

What the EPC field actually contains

The memory bank is structured, and the structure matters more than the payload.

• In Gen2 the EPC bank holds a CRC word, a protocol control word and the EPC itself, usually 96 bits.
• The bits travel in 16-bit words, and the tag stores them in a defined order that differs from a naive hex conversion.
• Filter and user memory live elsewhere; a correct EPC says nothing about the user data next to it.
• Reserved memory holds the kill and access passwords and their own lock state.
• Length, padding and byte order conventions must agree between printer, middleware and ERP, or every read will be subtly wrong.

CRC-16: what it protects and what it does not

The checksum catches transmission damage, not human mistakes.

• A CRC-16 covers the EPC bits, and a reader uses it to reject a corrupted read rather than report it.
• It protects against bit errors in the air and in storage, which is exactly the failure mode hardware produces.
• It cannot detect a well-formed wrong value: a duplicated serial number passes CRC every time.
• The CRC is recalculated when the EPC is written, so encoders that skip the step produce rejected reads.
• Treat CRC validity as a necessary condition and never as a proof of correctness.

Read-back verification and the select mask

You have to know which tag you verified.

• Read the whole bank back after writing: CRC word, control word, EPC and any user fields you populated.
• Compare against the intended value, not against the reader's echo of what it transmitted.
• Select on the TID before reading, so verification targets the intended physical tag and not a neighbour.
• Reduce power during verification to shrink the field, which prevents accidental reads from adjacent items.
• Store the verification result against the tag record, with reader, antenna and timestamp.

Passwords, lock bits and permanence

Locks are most useful before they are irreversible.

• The access password gates writes; the kill password gates permanent disablement, and both need a managed store.
• Lock bits are effectively irreversible in common configurations, so a wrongly locked tag is scrap.
• Permalock on the EPC removes any chance of correcting a serial error discovered later.
• Keep passwords per site in a controlled repository, never hard-coded in middleware source.
• Decide the lock policy before mass encoding begins, because retrofitting it means re-labelling the estate.

Blast writes and bulk commissioning

Throughput and uniqueness pull in opposite directions.

• Blast write sends one value to every tag in the field, which only suits a homogeneous, non-serialised SKU.
• Unique serialisation needs per-tag writes and therefore needs singulation.
• Jamming the field to isolate a single tag slows throughput and stresses both reader and tags.
• Shielded tunnel encoders are far more reliable for bulk work than handheld overwrites in open air.
• Always re-verify a sample of tunnel output, because a tunnel failure can still look like a clean pass.

A failure taxonomy with a retry policy

Retrying blindly turns a data problem into a hardware problem.

• Classify outcomes: no response, acknowledged but wrong value, invalid CRC, lock failure, duplicate EPC.
• Retry once in place, then move the tag to a rework bin instead of looping on it.
• Track failure codes per inlay batch; a rising code usually signals a supplier or process change.
• Never retry a write against a tag whose lock state is unknown.
• Close the rework bin daily, or failed tags quietly return to production.

Verification at the encoding station

The station is where verification is cheap and where errors are still fixable.

• Encode at the label applicator where possible, so the inlay and the printed label stay one unit.
• Verify before the label is applied, not after the carton is sealed and palletised.
• A print-verify-apply station should record EPC, TID and result in a single transaction.
• Divert failed labels automatically; manual removal is exactly where errors come back.
• Reconcile the station's output against the ERP order line before the pallet is closed.

Field drift and re-verification

Tags that were right at encoding time do not stay right forever.

• Flexing, heat, moisture and pressure can corrupt user memory without touching the EPC.
• Dock-door read rate is a useful proxy for tag health only when reader settings stay stable.
• Periodic audits should compare a sample of physical EPCs against the ERP record.
• A tag that reads intermittently is a failed tag, not a marginal one.
• In the field, replace rather than reprogram: the labour is similar and the outcome is more certain.

Acceptance criteria and metrics

If you cannot state the numbers, you cannot claim the process works.

• Define per station: first-pass verification rate, failure code mix and rework rate.
• Require the station to prove CRC validity and value equality as two separate checks.
• Keep a reference set of known-good and known-bad tags for monthly spot checks.
• Audit the audit: sample already verified tags and verify them independently.
• Publish the numbers to operations, because encoding quality is invisible until somebody measures it.