CR95HF SendRecv Response for ISO-15693

[DWalk.3]

I'm using a CR95HF NFC reader (a Mickroe RFID Click) using the UART port. I'm using ISO 15693 to communicate with my tag. I'm issuing the following commands (I know it looks like I'm using the eval board, but I'm actually using my own Python program:

REM Check for communications
>>> Idn 0
<<< 00 0F 4E 46 43 20 46 53 32 4A 41 53 54 34 00 2A CE

REM Set for ISO 15693, high-speed (26 kbps), single sideband, and 100% modulation
>>> ProtocolSelect 01 09
<<< 00 00

REM Set the eval board gain to 32 dB
>>> WriteRegister 68 00 01
<<< 00 00
>>> WriteRegister 68 01 01 D0
<<< 00 00

REM Read it back
>>> WriteRegister 68 00 01
<<< 00 00
>>> ReadRegister 69 01 00
<<< 00 01 D0

REM Send an Identify command
>>> SendRecv 26 01 00
<<< 80 0D 00 00 02 28 E0 6D 58 01 04 E0 D0 60 00

I'm having difficulty figuring out the response. The 0x80 means there was no error, and there are 13 bytes in the response. The bytes can be interpreted as the ISO 15693 Inventory command response (from ISO/IEC 15693-3:2019):

• 00 - No flags set
• 00 - DSFID = 0
• 02 28 E0 6D 58 01 04 E0 - The device UID E004_0158_6DE0_2802

The remaining three bytes are not part of the ISO standard, as far as I can tell. My questions:

1. Does the CR95HF add these extra bytes for some other purpose?
2. Are these actually described in the ISO standard (which I missed)?
3. What do they mean?

I could just ignore them, but I like to know what is going on.

[Brian TIDAL · Accepted solution]

Hi,

see §5.6 in the ST25R95 datasheet and table 17. The extra bytes are the 2-bytes CRC followed by a 1-byte flag containing CRC error indication and collision indication.

Rgds

BT

[DWalk.3]

What I didn't know was that the CR95HF became the ST25R95. That helped a great deal!

Thank you!

[Brian TIDAL]

Hi,

this is as well in the datasheet of the CR95HF (§5.5 and table 15). I would recommend to use the ST25R95 datasheet as it is up to date.

Rgds

BT

[DWalk.3]

Yes, I see it now. Maybe I'm having vision problems!

[DWalk.3]

The last byte seems important. When I run the inventory many times, I get the following results:

11/2/2023 16:53:19.772 [RX] - 80 0D 00 00 02 28 E0 6D 58 01 04 E0 D0 60 01 
11/2/2023 16:53:20.793 [RX] - 80 0D 00 00 02 28 E0 6D 58 01 04 E0 D0 60 01 
11/2/2023 16:53:21.799 [RX] - 80 0D 00 00 02 28 E0 6D 58 01 04 E0 D0 60 01 
11/2/2023 16:53:22.821 [RX] - 8E 0E 00 00 02 28 E0 6D 58 01 04 E0 D0 60 0A 01 
11/2/2023 16:53:23.811 [RX] - 80 0D 00 00 02 28 E0 6D 58 01 04 E0 D0 60 01 
11/2/2023 16:53:26.828 [RX] - 80 0D 00 00 02 28 E0 6D 58 01 04 E0 F0 60 03 
11/2/2023 16:53:27.850 [RX] - 80 0D 90 00 22 28 E2 6D 58 01 44 E0 D0 60 03 
11/2/2023 16:53:28.840 [RX] - 80 0D 00 00 02 28 E0 6D 58 11 44 E0 D0 60 03 
11/2/2023 16:53:29.861 [RX] - 80 0D 00 00 02 68 E0 6D 58 01 04 F0 D0 60 03 
11/2/2023 16:53:31.873 [RX] - 8E 0E 00 00 02 28 E0 6D D8 01 04 E0 D0 60 26 01 
11/2/2023 16:53:33.885 [RX] - 80 0D 08 00 02 28 E0 6D 5A 01 14 E0 D0 60 03 
11/2/2023 16:53:35.913 [RX] - 80 0D 42 00 02 28 E8 6D 58 01 84 E0 D0 60 03 
11/2/2023 16:53:37.940 [RX] - 80 0D 01 80 82 28 E2 6F 5A 81 CC E0 D0 60 03 
11/2/2023 16:53:38.946 [RX] - 8E 0E 00 00 02 28 E0 ED 5A 01 0C E2 D0 60 02 01 
11/2/2023 16:53:39.951 [RX] - 80 0D 02 20 82 28 E9 6D 58 01 0C E2 D2 60 03 
11/2/2023 16:53:40.941 [RX] - 8E 0E 04 00 02 28 E0 6D 58 01 04 E0 D0 60 83 01 
11/2/2023 16:53:41.947 [RX] - 80 0D 00 85 02 6A E4 6D 58 01 04 E8 DC 64 03 
11/2/2023 16:53:42.968 [RX] - 80 0D 00 18 02 38 E0 6D 58 01 84 E4 D0 60 03 
11/2/2023 16:53:43.974 [RX] - 80 0D 40 00 22 A8 E0 6D 58 01 04 F0 D0 60 03 
11/2/2023 16:53:44.996 [RX] - 80 0D 00 00 02 28 E0 6D 58 01 04 E0 D0 60 01 
11/2/2023 16:53:46.002 [RX] - 80 0D 00 00 02 28 E0 6D 58 01 04 E0 D0 60 01 
11/2/2023 16:53:47.023 [RX] - 80 0D 00 00 02 28 E0 6D 58 01 04 E0 D0 60 00 
11/2/2023 16:53:48.029 [RX] - 80 0D 00 00 02 28 E0 6D 58 01 04 E0 D0 60 00 
11/2/2023 16:53:49.051 [RX] - 80 0D 00 00 02 28 E0 6D 58 01 04 E0 D0 60 01 
11/2/2023 16:53:50.057 [RX] - 80 0D 00 00 02 28 E0 6D 58 01 04 E0 D0 60 00 
11/2/2023 16:53:51.062 [RX] - 80 0D 00 00 02 28 E0 6D 58 01 04 E0 D0 60 01 

There are some entries returning 0x8E that are errors (reception lost without EOF received). The others have a final byte with values of 0x00, 0x01, and 0x03. The UID and DSFID look correct whenever the final byte is 0x00 or 0x01. It is (almost) always wrong when EOF wasn't received. My understanding of the last byte:

0x00 - No CRC error or collision

0x01 - No CRC error but a collision was detected

0x02 - Not observed. This would be a CRC error but no collision.

0x03 - Both CRC error and collision.

My question here is when should the packet be discarded? Certainly, if a CRC error is detected it should, but it seems like it's okay if the collision detection is set, but the CRC is clear. Is this, in fact, the case?

[Brian TIDAL]

Hi,

if you plan to support collision resolution of type 5 tags, I would recommend to follow the ISO 15693 anticollision or the NFC Forum collision resolution activity.

If your application is supposed to support only 1 tag in the operating field, there should be no collision. If anyway a collision is detected but CRC is correct, then collision error can be ignored assuming the next commands are sent in addressed mode or selected mode. If your tag supports the SELECT  command, I would suggest to enter in selected mode. Your application should return to inventory as soon as a tag is not replying to further commands.

Rgds

BT