Technology 📅 October 4, 2026 ⏱ 12 min read

Writing the EPC Bank: PC Word Length, Padding, and Why Tags Read Truncated

Diagram of a Gen2 EPC memory bank from address 00h showing CRC, PC word length bits, toggle and the EPC field

A tag that reads every time, with a clean CRC and no error anywhere in the log, can still hand your system the wrong identifier. The commonest way this happens on a commissioning line has nothing to do with RF. It is a field five bits wide, in the Protocol Control word at address 10h of EPC memory, still holding the value written for the previous EPC scheme.

This page puts three things normally scattered across two standards on one screen: the EPC memory bank field by field, the word-count arithmetic that fills the Length field, and the decode validity test that catches a corrupted identifier before it becomes a business event. Everything below cites the GS1 EPC Tag Data Standard Release 2.3 (Ratified, Oct 2025) and the EPC Gen2 air interface standard Release 3.0.1 (Ratified, Feb 2026), by clause.

The failure this page prevents

A tag is commissioned with a numeric serial — urn:epc:tag:sgtin-96:3.9521141.012345.4711. That is a 96-bit EPC, six 16-bit words, and the encoder writes a Length value of 6 into the PC word.

Weeks later the tag is re-commissioned with an alphanumeric serial, 4711A. SGTIN-96 cannot carry letters, so the scheme becomes SGTIN-198 and the encoder writes 208 bits from 20h. The write succeeds; every byte is physically present in the tag.

If the job did not also rewrite the Length field, the tag still says six words. Gen2 clause 6.3.2.1.2.2 defines the L bits at 10h–14h as bits that “specify the length of the EPC that a Tag backscatters in response to an ACK, in words,” and states that if an interrogator changes the EPC length through a memory write and wants the new length backscattered, it must write new L bits into the tag’s StoredPC. The tag obeys: it sends 96 bits of a 208-bit EPC and drops the other 112 on every read.

Why nothing errors

Gen2 clause 6.3.2.1.2.1 specifies that the tag computes its StoredCRC “over the StoredPC and the EPC specified by the length (L) bits in the StoredPC.” The PacketCRC sent during backscatter covers the PC word, any XPC words and the backscattered EPC. Both checksums are computed over the truncated view, so they agree perfectly. The air interface has no opinion about whether the EPC it was told to send is the whole EPC.

	Correctly commissioned	Length field not updated
EPC written from 20h	208 bits	208 bits
PC Length field	01101 (13 words)	00110 (6 words)
Bits backscattered	208	96
Hex returned	3676451FD40C0E5A3762C608 0000000000000000000000000000	3676451FD40C0E5A3762C608
CRC result	Valid	Valid
Decodes to a valid EPC	Yes	No — 96 bits for a 198-bit scheme

The diagnostic is in the hex. The header byte reads 36, which declares an SGTIN-198 and therefore 198 bits, but only 24 hex characters came back. A header promising more bits than you received is the signature of this fault, visible in one glance.

The EPC memory bank, field by field

Gen2 clause 6.3.2.1.2 lays out EPC memory as a StoredCRC at 00h–0Fh, a StoredPC at 10h–1Fh, the EPC from 20h, and optional extended PC words at 210h–21Fh and 220h–22Fh. Bit 00h is the most significant bit of the bank and every field is stored MSB first. Table 9-3 of the Tag Data Standard defines the PC bits.

Bits	Field	What it holds
00h–0Fh	StoredCRC	A 16-bit CRC the tag computes over the StoredPC and the EPC specified by the L bits. A tag refuses a write here and treats the parameters as unsupported.
10h–14h	L4–L0 (Length)	Five bits: the number of 16-bit words comprising the EPC field from 20h, including any optional AIDC data appended to the EPC.
15h	UMI / RUM	User Memory Indicator on Gen2v2 and earlier, where bit 15h may be fixed by the tag manufacturer or computed by the tag; Read User Memory indicator on Gen2v3 and later, which the tag always computes.
16h	XI	XPC_W1 indicator. Calculated by the tag and ignored when written, so the encoding procedure disregards it.
17h	T (Toggle)	0 indicates a GS1 EPCglobal application encoded per TDS. 1 indicates a non-GS1 application, the bank holding a UII rather than an EPC.
18h–1Fh	Attribute / RFU / AFI	With T=0: Attribute bits on Gen2 v1.x tags, reserved for future use on Gen2v2 and Gen2v3. With T=1: the Application Family Identifier.
20h onward	EPC / UII	The binary encoding, followed by enough zero bits to reach a word boundary.

Two things surprise people who have only handled EPCs as hex strings. The CRC is the tag’s job, not yours — and Table 15-1 tells encoding software not to be concerned with it at all. And bits 17h–1Fh are collectively the Numbering System Identifier: when the toggle is zero the numbering system is always the EPC, and the Attribute bits are capture hints the standard says are not part of the EPC and not intended as master data.

What goes in the Length field

Table 15-1, the recipe for filling Gen 2 EPC memory from an EPC Tag URI, states the rule for bits 10h–14h in one sentence: the number of bits N in the EPC binary encoding, divided by 16, rounded up to the next higher integer if N was not a multiple of 16.

Same table, bits 20h onward: the N bits from the encoding procedure “followed by enough zero bits to bring the total number of bits to a multiple of 16 (0 – 15 extra zero bits).” The Length field counts the padded words, not the meaningful ones.

SGTIN-96. N = 96. 96 ÷ 16 = 6 exactly, no rounding. Length field = 6 = 00110. Padding = (6 × 16) − 96 = 0 bits.
SGTIN-198. N = 198. 198 ÷ 16 = 12.375, rounded up to 13. Length field = 13 = 01101. Memory = 13 × 16 = 208 bits. Padding = 208 − 198 = 10 trailing zero bits.

That single increment from 6 to 13 is the whole subject of this page.

Scheme	Header	Bits (N)	Words	Length field	Memory	Padding
SGTIN-96	30	96	6	00110	96	0
ITIP-110	40	110	7	00111	112	2
GRAI-170	37	170	11	01011	176	6
SGLN-195	39	195	13	01101	208	13
SGTIN-198	36	198	13	01101	208	10
GIAI-202	38	202	13	01101	208	6
ITIP-212	41	212	14	01110	224	12

SGLN-195, SGTIN-198 and GIAI-202 all carry Length 13. A Length field matching what you expect is necessary but not sufficient — the header byte decides the scheme, and three schemes share this word count.

The ceiling on the field

Five bits give a maximum of 11111 = 31 words = 496 bits. Gen2 clause 6.3.2.1.2.2 adds a qualification worth knowing before designing a long payload: a tag supporting only XI=0 may use the full 11111, but a tag supporting XI=1 has a maximum Length of 11101 — 29 words, or 464 bits — and refuses a write attempting more.

Reading the PC word back

The PC word earns its place by arriving before the EPC. In reply to an ACK the tag backscatters a PC word, optionally one or two XPC words, then the EPC, then a PacketCRC — so the reader knows how many words are coming before it has received them. That is what keeps an inventory round efficient at a busy portal.

StoredPC is not always PacketPC

Gen2 requires a tag to implement a PacketPC in addition to the StoredPC, and the two differ precisely in their L bits. When XI=1 and XEB=0 the tag sends an XPC_W1 before the EPC and increments the PacketPC L bits by one; when both XI=1 and XEB=1 it sends two XPC words and double-increments. The standard adds that this does not alter the bits stored at 10h–14h — the tag increments the backscattered copy and leaves memory alone.

So a PC word reading one or two higher than what you wrote is not necessarily a fault. It may be a tag telling you an XPC word is on the wire. Log the XI and XEB flags alongside and the ambiguity disappears.

Never infer length from the header alone

It is tempting to see header 36 and assume 198 bits. The decoding procedure in clause 14.4 does the opposite, and the order of its steps is the lesson. Step 1 reads the header to find the coding table and the encoding bit length B. Step 2 confirms the number of bits actually received, N, is greater than or equal to B, and stops if it is not. Only then does step 3 truncate surplus least-significant bits down to B — a step the standard explains removes trailing zero padding read back through word-oriented data transfer.

Step 2 would have caught our truncated tag, and it is the step an integration skips whenever it treats the EPC as an opaque hex string to be stored and compared. The cost of skipping it is not a crash. It is a silently wrong identifier in a database.

The decode validity test that catches a bad prefix

Clause 14.4.3 specifies the Partition Table decoding method, and it carries an explicit validity test that is cheap to wire into production code and pays for itself on the first corrupted read. For a segment encoded as a 3-bit partition value followed by two variable-length integers:

The three most significant bits must match a partition value in the table. That row becomes the matching row.
Take the next M bits as an unsigned integer C, M being the Company Prefix Bits of the matching row. C must be less than 10^L, where L is the company prefix digit count.
Take the remaining N_other bits as an unsigned integer D. D must be less than 10^K, K being the other field’s digit count. If K = 0, D must be zero.

One naming note before the table: the standard writes that second width as N, the same letter clause 14.4 uses for the total number of bits read back from 20h, so this page calls the partition-row figure N_other throughout and keeps N for the total — useful to know if you are cross-checking the routine below against 14.4.3 line by line.

The output pads C on the left with zeros to L digits, a dot, then D padded to K digits. The test has teeth because a decimal field stored in binary leaves gaps: the legal fraction of each field is 10^digits ÷ 2^bits. From Table 14-16, the SGTIN partition table:

Partition	Prefix bits (M)	Prefix digits (L)	Legal prefix patterns	Other bits (N_other)	Other digits (K)	Legal other patterns
0	40	12	90.95%	4	1	62.50%
1	37	11	72.76%	7	2	78.13%
2	34	10	58.21%	10	3	97.66%
3	30	9	93.13%	14	4	61.04%
4	27	8	74.51%	17	5	76.29%
5	24	7	59.60%	20	6	95.37%
6	20	6	95.37%	24	7	59.60%

Read the partition 2 row. Only 58.21 per cent of the 34-bit company prefix space is legal — 10^10 values out of 2^34 = 17,179,869,184 patterns, leaving 7,179,869,184 illegal. So 41.79 per cent of the bit patterns a corrupted read could produce in that field are detectably invalid, for free, with two comparisons.

An arithmetic identity worth knowing

Multiply the two columns and something tidy falls out. Across every SGTIN partition, L + K = 13 and M + N_other = 44. The joint legal fraction of the 44-bit payload is therefore 10^13 ÷ 2^44 = 10,000,000,000,000 ÷ 17,592,186,044,416 = 56.84 per cent, identical at every partition value.

Whichever partition your prefix length puts you in, the test rejects 43.16 per cent of random 44-bit payloads, and the unassigned partition value 7 rejects another eighth before you reach the integers. That is a real second line of defence behind the CRC — and unlike the CRC, it still works when the CRC was computed over the wrong number of words.

A validation routine for the decode path

The routine is short enough to inline. For a bit string of length N read from 20h:

Read the header. Most significant 8 bits. Map to a coding scheme and its bit length B. No mapping, no decode.
Check the length. If N < B, stop. This is the truncated-PC-word case.
Trim the padding. If N > B, retain the most significant B bits.
Read the partition. Three bits. If absent from the scheme’s partition table, stop.
Look up M, L, N_other and K from the matching row.
Test C. Next M bits as an unsigned integer. If C ≥ 10^L, stop.
Test D. Next N_other bits as an unsigned integer. If D ≥ 10^K, stop. If K = 0 and D ≠ 0, stop.
Format. C zero-padded to L digits, a dot, D zero-padded to K digits, then the remaining segments per the coding table.

N and N_other are deliberately distinct symbols here: N is the length of the bit string you read, N_other the width of the partition row’s second field.

Where to run it, and what to do with a failure

Run it at the read point. Once an identifier has crossed a message bus and reached an event store, the antenna, the timestamp and the raw hex that would let you diagnose it have usually been dropped. Validating on the reader keeps the diagnosis next to the evidence — one reason we put decode and filtering logic into our on-reader middleware and device management layer rather than leaving it to the host.

Log the raw hex, the PC word, the antenna port and the timestamp. Those four identify the tag, the fault class and the location in one line.
Hold a malformed identifier at the reader. A rejected read is a known unknown; an emitted bad SGTIN is a false record someone reconciles three weeks later.
Count failures per antenna. Clustered on one port points at RF or a cable; clustered on one product points at the encoding job.

The payoff is downstream data quality rather than read performance. The read itself was fine. What the test protects is every inventory count and asset record that would otherwise inherit an identifier nobody can trace to a real object.

Serial limits that decide the scheme before you write

The scheme is chosen by the serial, before a single bit reaches the tag. The Tag Data Standard is plain: SGTIN-96 allows numeric-only serials, without leading zeros, whose value is less than 2^38 — from 0 through 274,877,906,943 inclusive. SGTIN-198 allows up to 20 alphanumeric characters.

That 20 is itself arithmetic. The String encoding method carries each character as a 7-bit code from the standard’s 82-character table, and requires the character count to be no greater than b ÷ 7, where b is the coding segment bit count. For SGTIN-198 the serial segment is 140 bits, so 140 ÷ 7 = 20 characters. Anything shorter is padded right with zeros to fill all 140.

Three checks before the job runs

Is every character a digit? One letter, one hyphen, one space — and the answer is SGTIN-198.
Does the serial have a leading zero? “0123” cannot be carried by SGTIN-96, because leading zeros are not preserved. Only a serial that is the single digit “0” survives.
Is the value 274,877,906,943 or less? That is the inclusive ceiling, 2^38 − 1, so a 12-digit serial may fit and a 13-digit one never will.

Moving from SGTIN-96 to SGTIN-198 takes the written EPC from 96 bits to 208 — six words to thirteen, an increase of 116.7 per cent in the EPC memory the tag must provide, and 87.5 per cent in each inventory reply once the PC word and PacketCRC are counted (128 bits to 240). The second figure is the one that shows up as air time at a portal. Two consequences follow. Tag selection stops being a commodity decision, because the chip must have the EPC memory to hold it. And write time per tag rises, which matters where work-in-progress tagging is paced to a conveyor rather than an operator.

Commissioning checks that catch this on day one

Five checks that cost a few minutes at setup and remove an entire class of defect from a deployment.

Read back on a different reader and antenna. Not the encoder that wrote the tag. An encoder holding a cached view of what it just wrote will confirm its own mistake, and a print-and-apply unit reading at 20 mm is not a portal reading at 2 m.
Compare the decoded URI with the source element string, not the hex you sent. Round-tripping hex against hex tests your transmission. Round-tripping the decoded GTIN and serial against the record the job was built from tests the encoding.
Check the PC Length against the EPC length for every scheme in the job. Not just the first tag. The fault appears precisely when the scheme changes mid-run, so a single-sample test is blind to it by construction.
Keep a known-good reference tag per scheme. One SGTIN-96 and one SGTIN-198, labelled, in the toolbox. They separate a reader problem from an encoding problem in under a minute.
Log the PC word alongside the EPC. Most SDKs surface it and most integrations discard it. It costs two bytes per read and it is the one field that distinguishes this fault from every other cause of a short EPC.

For each distinct EPC scheme in a commissioning job, assert that the PC Length field equals the ceiling of the scheme’s bit length divided by 16 — six for the 96-bit schemes, thirteen for SGTIN-198, fourteen for ITIP-212. With that assertion in your acceptance test, this class of defect stops reaching your line.

We build both the reader hardware and the software that runs on it, so when a field report says “the tags read short,” the PC word, the antenna and the encoding job get looked at in one session. If you are specifying a scheme and want the word counts checked before the job reaches a line, send us the serial format.

Frequently asked questions

What is the PC word in a Gen2 RFID tag?

The Protocol Control word occupies bits 10h–1Fh of the EPC memory bank, immediately after the 16-bit CRC and immediately before the EPC itself at 20h. It carries the five-bit EPC Length field, the user memory indicator, the XPC indicator, the numbering system toggle, and eight bits used as Attribute bits, reserved bits or an Application Family Identifier depending on the tag generation and the toggle value. Its job is to tell the reader how to interpret what follows before the EPC arrives.

Why does my RFID tag read only part of the EPC?

Almost always because the PC Length field was not updated when the EPC was rewritten at a different length. Gen2 clause 6.3.2.1.2.2 states that the L bits specify the length of the EPC a tag backscatters in response to an ACK, and that an interrogator changing the EPC length must write new L bits for the new length to be sent. Everything you wrote is still in tag memory; the tag is simply being told to send fewer words of it. The tell is a header byte declaring more bits than the number of hex characters you received.

How many words is a 198-bit EPC in the PC length field?

Thirteen. Table 15-1 of the Tag Data Standard gives the rule as N divided by 16, rounded up to the next higher integer when N is not a multiple of 16. 198 ÷ 16 = 12.375, which rounds up to 13, so the Length field holds 01101 and the EPC occupies 13 × 16 = 208 bits of memory with 10 trailing zero padding bits. By contrast a 96-bit EPC divides exactly into 6 words and the field holds 00110.

How is the EPC memory bank laid out?

Bits 00h–0Fh hold the StoredCRC, 10h–1Fh the StoredPC, and the EPC runs from 20h for as many words as the Length field declares. Optional extended PC words sit at 210h–21Fh and 220h–22Fh. Bit 00h is the most significant bit of the bank, and every field is stored MSB first, so the EPC’s most significant bit is the one at address 20h.

How do I validate a decoded SGTIN before storing it?

Run the validity test in clause 14.4.3. Read the three partition bits and find the matching row in the SGTIN partition table. Take the next M bits as an unsigned integer C and confirm C is less than 10^L; take the remaining N_other bits as D and confirm D is less than 10^K, with D required to be zero when K is zero. N_other is this page’s name for the partition row’s second field width, which the standard also writes as N in a separate clause from the one using N for the total bits read. Because decimal values stored in binary fields leave unused patterns, this rejects 43.16 per cent of random 44-bit payloads at every partition value, and it costs two integer comparisons.

Does the reader calculate the CRC on an EPC write?

The tag does. Gen2 clause 6.3.2.1.2.1 requires the tag to compute and store the StoredCRC either when an interrogator writes bits in the EPC bank, including the StoredPC, or at every power-up, at the manufacturer’s choice. A tag refuses an attempt to write addresses 00h–0Fh and treats the command’s parameters as unsupported. The Tag Data Standard reaches the same practical conclusion from the software side, though its wording differs: Gen2 3.0.1 clause 6.3.2.1.2.1 normatively assigns the computation to the tag, while TDS Table 15-1 speaks more loosely of the CRC being calculated automatically. Either way, software implementing the encoding procedure need not compute it.

What happens to the extra bits when an EPC is not a multiple of 16?

They are zeros. Table 15-1 specifies that EPC memory from 20h holds the N encoded bits followed by enough zero bits to bring the total to a multiple of 16, which is between 0 and 15 extra zeros. The Length field counts those padded words, not the meaningful ones. On decode, step 3 of clause 14.4 discards the surplus least-significant bits precisely because word-oriented data transfer reads that padding back.