Deciphering EPC Class 1 Generation 2


EPC C1G2 protocol can be a little tricky to understand, even after reading the specification. Here are a few common hangups and some general information:

Note that the figures are taken from the EPC spec, copyright EPC global.

Useful Specification Pages

Pg 97 - High Level Protocol Diagram Example
Pg 54 to 74 - Tag and Reader Bit-Level Packet Descriptions
Pg 30 to 36 - Tag and Reader Physical Layer Modulation Descriptions

How to Read a Tag

RFID communication always occurs in pairs - the reader talks and then the tag talks (if appropriate). In practice, accessing a tag involves several actions:
a. Reader requesting a 16-bit handle from the tag (lets call it H1)
b. Reader requesting ID from H1 tag
c. Reader requesting new handle from H1 tag (called H2)
d. Reader accessing tag with Read, Write, etc. command

What do the Tag and Reader Talk About?

There are several things happening. Most importantly, the reader tries to make sure that two tags don't talk at the same time. It does this by allocating a number of time slots in which tags can talk. The tags then randomly choose a time slot. If the reader allocates too few slots, tag communication collisions are likely; if there are too many slots, the reader wastes time reading slots which have no tag. When it is the tag's turn to talk, it sends a random number which is to be the handle by which the reader refers to that tag (called a handle). Once the reader gets all of the tag handles, it asks for the EPC ID of each tag.

The process by which the tags chose a time slot is based on a parameter Q (specified in the Query command) and the random number chosen by the tag. The tag takes 2^Q-1 bits of its random number to be its slot number. Each time the reader requests the next slot (via a Query, Query Repeat or Query Adjust command), the tag decrements its slot number. If the slot number is 0, the tag responds.

The reader also tells the tag how it is to respond (modulation type and rate). This is described below.

Descriptions of the various reader and tag communication packets can be found in the EPC Spec on or near page 54.

How the Reader Specifies Protocol Settings

The reader prepends some timing information to each packet it sends, which specifies the reader and tag communication rates. The timing information can be in the form of a Preamble or Frame-Sync. A preamble is prepended to Query commands, and a Frame-Sync is prepended to all other commands. The difference is the inclusion of TRcal, which tells the tag the backscatter link frequency.

preamble_framesync.PNG

The Query command also specifies some parameters which affect how the tag should modulate its backscatter. See Transmit Speed.

Receive Speed

Understanding TARI, RTCAL, PIVOT, "0", "1"

Reader to tag communication, or downlink data, is encoded as long or short positive pulses followed by a fixed duration negative pulse. The negative pulse is called PW.

The total time duration for each bit (positive plus negative pulse) is length Tari for a data-0 or between 1.5 Tari and 2 Tari for a data-1.
An examble is shown below; however, it is grossly out of scale - Tari is around 5 to 20 times longer than PW, depending on the modulation settings.

downlink_data_encoding.PNG

The tag decodes bits by measuring the length of the bit and comparing against the half-way mark (called pivot). Pivot is simply the average between a data-0 and a data-1. Mathematically it looks like:

Pivot = 1/2 * (data-0 + data-1) = RTcal / 2

The reader tells the tag what the Pivot is during the preamble and also during the frame-sync. To reduce measurement uncertainty and noise, the reader sends a RTcal which is two times a Pivot. By dividing by two, the tag divides the measurement noise by two. The tag can also compare RTcal against the first data-0 (see Figure 6.4) to ensure that this is really the start of a packet.

Transmit Speed

Understanding TRCAL, DR, M, Fsc, Tbit

First note that the Tag modulation is totally different than the Reader modulation. The reader encodes data in the length of the pulses. The tag encodes data by sending out a square wave and inserting phase inversions to delineate between 1's and 0's.

The specification has detailed examples of the tag modulation. However, the state diagram for creating the modulation is a poor method for understanding the modulation. A better method is to draw a square wave at the same frequency as the modulation subcarrier (which we will call the clock) and compute a third signal which is the square wave XOR with the modulation (which we will call the phase). Conversely, the modulation phase XOR clock. Now, when the tag inverts the waveform (as in between to miller 0's, etc), we see the phase invert. The phase represents the transitions that the tag needs to encode into the output waveform, and represents a convenient way of parsing the Miller modulations which have many redundant clock cycles.
There are several parameters required to specify the tag backscatter modulation. First, lets look at what the modulation should look like for two 0's transmitted in a row.

uplink_data_encoding.PNG

Notice that for Mx (miller x=1,2,4,8 where m1 = fm0), the bit takes x times more square wave periods to transmit. This degenerates to FM0, where each bit takes 1 period to transmit. The reason its not called M1 is that the modulation of 1's and 0's is slightly different than the Miller encoding.

Important: Notice that for each encoding, the square wave period stays the same. This is the subcarrier frequency, or Fsc.

The reader specifies Fsc in the Preamble and Query command (see Figure 6.4). Fsc = DR / TRcal where DR = the divide ratio as specified in the Query command (8 or 64/3).

The back link frequency (BLF), or frequency at which the data is transmitted is simply Fsc / M where M = 1,2,4,8. M is specified in the Query command.

Reader to Tag Delay

When should the WISP respond?

The reader to tag delay, T1, is given as the greater of RTcal and 10/Fsc. Remember that Fsc is just DR/TRcal. In the spec, they call 1/Fsc as "Tpri".

Handle versus Cover Code

The reader specifies which tag it wants to talk to by addressing a tag handle. Tag handles are sent by the tag to the reader in response to a Query, Query Repeat, Query Adjust and sometimes a Request RN (ReqRN). ReqRN requests a new handle from the tag after an Ack. However, during a Write operation, the reader sends a second ReqRN. The tag should respond with a cover code, which the reader XORs with the data to be written to the tag during the Write command. The tag must keep the cover code and handle separate in order to successfully perform the Write command. Note: some Impinj / ThingMagic firmwares also request a cover code for the Read command. Again, the handle and cover code should be kept separate. Also note that this bug only appears when the tag is generating random handles and cover codes. If a fixed handle (in response to Query, ReqRN, etc.) is used, the bug is not visible because the cover code and handle are the same.