Frequently Asked Questions / Why does Normal Connected Mode (or using GetTagID command) on IDBLUE.UHF return EPC and not TID bank information?

NOTE: This also applies to the Keyboard Sender for Windows, Keyboard Wedge for Android and the HID version of our IDBLUE.UHF as they all use the GetTagID command in order to return tag information.

There are potential issues using TID bank data over EPC bank data… It is not a requirement in the EPC Gen2 specification to have a serial number programmed in the TID bank by the manufacturer. Therefore, certain EPC Gen2 tags that are not serialized had the same data in the TID bank. This is different over HF as the Tag UID in ISO15693/HF TID bank where they were uniquely serialized and locked when manufactured.

If you want to make sure the EPC bank doesn’t get modified, you can (set the EPC memory and)  lock the tag to make it unalterable but always readable.

If you are still interested in reading TID memory, we recommend setting the device to Reactive Connected Mode and doing an epcRead command to return the desired information you need.

According to the EPC Gen2 V2 specification: (NOTE: bolded for emphasis) Tag memory

EPC memory shall contain a StoredCRC at memory addresses 00h to 0Fh, a StoredPC at addresses 10h to 1Fh, a code (such as an EPC, and hereafter referred to as an EPC) that identifies the object to which the Tag is or will be attached beginning at address 20h, and if the Tag implements Extended Protocol Control (XPC) then either one or two XPC word(s) beginning at address 210h. See

TID memory shall contain an 8-bit ISO/IEC 15963 allocation class identifier at memory locations 00h to 07h. TID memory shall contain sufficient identifying information above 07h for an Interrogator to uniquely identify the custom commands and/or optional features that a Tag supports. See TID Memory

TID memory locations 00h to 07h shall contain either an E0h or E2h ISO/IEC 15963 class-identifier value. The Tag manufacturer assigns the class identifier (E0h or E2h), for which ISO/IEC 15963 defines the registration authority. The class-identifier does not specify the Application. TID memory locations above 07h shall be defined according to the registration authority defined by this class-identifier value and shall contain, at a minimum, sufficient information for an Interrogator to uniquely identify the custom commands and/or optional features that a Tag supports. TID memory may also contain Tag- and manufacturer-specific data (for example, a Tag serial number).

To further elaborate, there are more details described in the RFID Journal article “Identifying RFID’s Biggest Threats” (NOTE: bolded for emphasis):

What Changed With Gen 2

Part of the genius of EPC Gen 2 is that, upon being initially interrogated by a reader, the tag transmits an Electronic Product Code—a UII that identifies the product the tag to which it is attached—instead of transmitting a TID number assigned by the chip manufacturer (which just identified the tag). The “genius” is that it achieves two benefits over past designs: First, it assures that the initial read provides actual item identification, and second, it enables the UII to provide the key to a long list of business and consumer benefits, accessed via the Internet or some other network. The creation of EPC Gen 2 was the first time in RFID history that the TID was not read as the initial action between the reader and the chip. What’s more, the first supply of Gen 2 chips did not even contain a TID. This has been corrected, and the standards now support that a unique serial number can be written—and locked—to the TID in Gen 2 chips, thereby providing assurance that the tag’s data has not been duplicated into another tag (unique data = UII + TID).

Posted in: Software and Development