Overview
In February 2015, Impinj started shipping an updated version of Monza 4 tag chips with a change to the UMI bit function to comply with Gen2V2 specification. Recently, a few end users and partners have informed us about failures when encoding Monza 4 tags due to a compatibility issue with the encoding software or firmware in the readers or printers used for encoding. If you are running into encoding failures, please use following guidelines to check and modify your software or firmware to avoid the encoding failures.
Memory Guidelines
TID memory
If the application is filtering the TID for the tag chip manufacturer and tag model number for encoding recipe, only the first two words of TID memory should be used. The TID Mask Revision field must be ignored when filtering since this can change over time. Note that the value of TID Mask Revision is at memory location 30h to 33h (the start of word 3) in the TID memory bank. This value was 5h before the UMI bit function change and it changed to 7h after the UMI bit function change.
EPC memory
CRC16
The EPC memory contains a 16 bit cyclic-redundancy check word (CRC16) at memory addresses 00h to 0Fh. This value will change depending on the values of the PC word and the EPC data. The PC word has changed after the UMI bit function change, so these 16 bits will be different. If the encoding application must use the CRC16 for verification, it must take into account the current values of the PC word.
Protocol Control Bits or PC Word
This is the portion of memory where the UMI bit function has changed. The UMI bit is found at bit 15h of EPC memory. The 16 bits of the PC word have changed from the default of 0011 0000 0000 0000 (or 3000h) to 0011 0100 0000 0000 (3400h). Note that writing to the UMI bit will not change this value. In other words, a PC word of 3000h may be written to the tag to indicate a 96 bit EPC. This Gen2 write command will succeed, but the UMI bit will not change. If a reader verifies the PC word, it will read 3400h, which this does not match the value of 3000h written and may report a failure. This UMI bit mismatch is the most probable source of errors and must be modified by the reader.
EPC value
The default EPC value pre-programmed at manufacture has not changed. It is still 3008 33B2 DDD9 0140 0000 0000 in hex.
|
Product |
Desciption |
TID Memory |
EPC Memory |
||
|
|
|
|
CRC16 (word 0) |
PC Word (word 1) |
Default Impinj Factory-Programmed EPC Values (words 2+) |
|
Monza 4D |
Before UMI bit function change (old) |
e280 1100 2000 5XXX XXXX XXXX |
39bb |
3000 |
3008 33b2 ddd9 0140 0000 0000 0000 0000 |
|
Monza 4E |
Before UMI bit function change (old) |
e280 110C 2000 5XXX XXXX XXXX |
39bb |
3000 |
3008 33b2 ddd9 0140 0000 0000 0000 0000 |
|
Monza 4QT |
Before UMI bit function change (old) |
e280 1105 2000 5XXX XXXX XXXX |
39bb |
3000 |
3008 33b2 ddd9 0140 0000 0000 0000 0000 |
|
Monza 4D |
After UMI bit function change (new) |
e280 1100 2000 7XXX XXXX XXXX |
c41e |
3400 |
3008 33b2 ddd9 0140 0000 0000 0000 0000 |
|
Monza 4E |
After UMI bit function change (new) |
e280 110C 2000 7XXX XXXX XXXX |
c41e |
3400 |
3008 33b2 ddd9 0140 0000 0000 0000 0000 |
|
Monza 4QT |
After UMI bit function change (new) |
e280 1105 2000 7XXX XXXX XXXX |
c41e |
3400 |
3008 33b2 ddd9 0140 0000 0000 0000 0000 |
Table 1. Monza 4 Factory Default TID and EPC Memory before and after the UMI bit function change
Summary
When an application inventories or reads a tag, only the EPC value is read unless the entire EPC memory bank is specified. If the encoding software is reading the entire EPC bank for verification of encoding, the first 8 hex characters will be different (the CRC16 word and the PC word) for Monza 4 chips before and after the UMI bit function change. Therefore, any encoding system must be flexible if using the CRC16 or PC word for verification.
Verify UMI Bit Change is Source of Issue
In order to verify that the UMI bit change is the cause of the problem, we recommend manually encoding tags from before and after the change. For the following steps, encode a 96 bit EPC such as "1234-1234-1234-0000-0000-0000". These steps should only be implementing a write to EPC memory and should therefore not attempt any additional operations such as locking a memory bank.
- Attempt to encode a factory default tag from before the UMI bit change (ie with a TID matching one from table 1). (Tag 1)
- Attempt to encode a factory default tag from after the UMI bit change. (Tag 2)
- Using a new factory default tag from before the UMI bit change, write "FFFF" to word 0 of user memory. This will set the UMI bit to 1. Now attempt to encode this tag. (Tag 3)
- Inventory all tags above (Tags 1, 2 and 3) to verify the EPCs.
If Tag 1 encodes successfully but Tag 2 and Tag 3 fail for some reason, this is the likely source of the problem: the reader is assuming the UMI bit to always be 0. If the reader that encoded the tags gave a message that Tags 2 and 3 have failed but, after re-inventorying the tags, the EPC has actually been successfully written, this indicates that the reader is giving false negatives due to a mismatch between the expected result (PC word with UMI = 0) and actual result (PC word with UMI = 1).
Solution
The fix for this issue would be to modify/update the way the reader verifies a write, which may be done by updating firmware or the end application, depending on the system. Below is the pseudo-code that should be implemented by the reader during the encoding process. Note that this code is focusing on the write EPC portion of the encoding process as nothing has changed for other tag operations, such as locking the tag.
Preferred method: Write PC Word and EPC then Read EPC to Verify (Independent of UMI bit value)
In order for a reader to change the length of the EPC that the tag backscatters, it should do so by writing to the first 5 bits of the PC word also known as the L bits (EPC length field, bits 10h – 14h). The reader should write the PC word using the L bits to specify the length of the EPC that the tag backscatters. Next, it should write the EPC value. Finally, the tag should be inventoried. If the tag EPC inventoried matches what was expected, the write was successful.
|
Pseudo Code
|
Example
|
|---|---|
|
Write new PC word |
Write the L bits of the PC word followed by zeroes. For a 6 word EPC, this would be 0011 0000 0000 0000b. Write 3000h to EPC memory word 1 (PC word). The tag must respond with an ACK. |
|
Write new EPC value |
Write 1234-5678-9ABC-DEF0-1234-5678h to EPC memory words 2-7 (EPC Value). The tag must respond with an ACK. |
| Read EPC to confirm value was written successfully | Tag is inventoried. If EPC is 1234-5678-9ABC-DEF0-1234-5678h, the write was successful. Else, the verify fails. |
Alternative Method: Write PC Word and EPC then Read PC Word and EPC to Verify (Independent of UMI bit value)
If a reader MUST read the PC word to verify a successful write, it should only verify using the first 5 bits of the PC word also known as the L bits (EPC length field, bits 10h – 14h). The reader should write the PC word using the L bits to specify the length of the EPC that the tag backscatters. Next, it should write the EPC value. It should then read the L bits of the PC word and verify these bits were written successfully. Finally, it should inventory the tag and verify the EPC value.
|
Pseudo Code
|
Example
|
|---|---|
|
Write new PC word |
Write the L bits of the PC word followed by zeroes. For a 6 word EPC, this would be 0011 0000 0000 0000b. Write 3000h to EPC memory word 1 (PC word). The tag must respond with an ACK. |
|
Write new EPC value |
Write 1234-5678-9ABC-DEF0-1234-5678h to EPC memory words 2-7 (EPC Value). The tag must respond with an ACK. |
| Read PC word and confirm L bits match those expected | The PC word should read 0011 0XXX XXXX XXXXb, where the values of X do not matter. If the L bits do not match, the verify fails from L bits mismatch. If 0011 0100 0000 0000b is read, the verify is successful. |
| Read EPC to confirm value was written successfully | Tag is inventoried. If EPC is 1234-5678-9ABC-DEF0-1234-5678h, the write was successful. Else, the verify fails. |
Reader Compatibility
Anyone parties encoding Monza 4 tag chips should verify they are working with compatible RAIN RFID readers as soon as possible. If you would like to verify if a reader is compatible with this Gen2V2 UMI bit functionality, please send an email to m4umi@impinj.com.
Compatible Readers
The list below includes readers that are known to work with the UMI bit change. Example code is provided, if available, demonstrating how to write the EPC properly.
| Manufacturer | Reader | Examples |
|---|---|---|
| Impinj |
Speedway Revolution (R220/R420) |
Octane SDK C# example - "WriteEpc"
|
| Impinj |
Indy (RS500/RS2000) |
Readers with Known Compatibility Issues
Last updated June 15, 2015
|
Reader |
Error Description |
|
Sirit INfinity 510 |
Reader is receiving false negatives when encoding tags with a UMI bit set to 1. |
|
SAMSys module (MP9310/MP9311) |
Reader is receiving false negatives when encoding tags with a UMI bit set to 1. Solution: Contact SAMSys to update firmware to version 2.02.04_008 or newer. Use a write command in the format: }wv,b:000000000000000000000001,p:3400! |
|
Intermec IF30 RFID fixed reader |
Please contact Honeywell/Intermec for support. See the recommended fix from the reader manufacturer. |
|
Intermec PF2i |
Tags not encoding with UMI bit set to 1. |
|
ZEBRA RZx00, R110Xi4, ZD500R, ZE500R and ZT4x0R printers |
|
|
ZEBRA R4Mplus printer |
|
|
Datacard MX6000 with Honeywell (Intermec) IF 30 Reader |
Contact Datacard for resolution. |
Comments
Article is closed for comments.