cancel
Showing results for 
Search instead for 
Did you mean: 

How do I read multiple NFC tags at the same time

BMcKe.1
Associate

Issue:

When I attempt to read multiple NFC tags at the same time, the inventory command returns UIDs that don't exist and it returns with no error.

Details:

I am writing an NFC tag reader application in C++, using the CR95HF demonstration board from the M24LR-Discovery kit as my transceiver, and ISO15693 communications protocol.

Hardware Rev: MB1054x

Firmware Rev: 3.6.0

CR95HF Driver Rev: 0.9

For NFC tags, I am using a number of different products, all of which have the M24LR04E-R EEPROM on it:

M24LR-Discovery

ANT7-T-M24LR04E

X-Nucleo-NFC02A1

When there is only a single NFC tag within range of the transceiver, all functionality works flawlessly (ie. inventory, stay quiet, read, write, read-multiple, reset to ready). Now I am attempting to read multiple NFC tags at the same time.

In the initial scanning phase, I simply call the inventory command, get the returned UID, tell that UID to "stay quiet", and then repeat until there is no response from the inventory command. Then I read and write using the UIDs and finally reset them all to ready once I'm done.

Again, this works great when there is only one NFC tag within range, but once there is more than one, the inventory command returns UIDs that don't exist. As an example, I placed 2 NFC tags within range of the transceiver

The actual UIDs were

E00259C186C95D5F

E00259C186C95830

The UID returned by the inventory command was

E00259C186C95D7F

No other NFC devices are near the transceiver. I verified that it is not a rogue NFC device because when I change the combination of actual NFC tags, the non-existent UID changes as well.

My application will send a maximum of 20 inventory commands when scanning for devices. In the example above, it would sometimes eventually get the correct UIDs, but usually it would return the same non-existent UID over and over until 20 inventory commands were sent and my application gave up.

Question:

How do I read multiple NFC tags at the same time? Is my thought process for scanning incorrect? (Inventory -> stay quiet -> repeat).

Do I just need to loop it over and over until it finally finds the right UIDs? That seems like a somewhat weak solution and I suspect the problem will get exponentially worse as I add more tags

1 ACCEPTED SOLUTION

Accepted Solutions
Brian TIDAL
ST Employee

Hi,

make sure to use an MB1054B board with FW 3.7.1.

I guess you use the CR95HFDll_SendReceive API from the CR95HF.DLL. This API implements the SendRecv command from the CR95HF. This command returns a status byte (last byte of the response) with a CRC error flag bit and collision detection flag bit. See table 15 in the CR95HF Datasheet. When a collision is detected, the collision bit is set to 1 and only part of the data are valid. In that case the anti-collision has to be run.

See ISO/IEC 15693-3 for the anti-collision.

Rgds

BT

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

View solution in original post

2 REPLIES 2

Hello

this is bellow some information that will help :

1) ISO15693 RF PROTOCOL

When sending a command on the RF Field in Not addressed / Not selected way, all the tags in the field will response to the command.

If several tags are in the field, all the tags will response at the same time and the CR95HF will catch the response : In the rf field, the cr95hf see all responses "superimposed" (1 + 0 = 1) :

In your example : 5D5F (0101 1101 0101 1111) + 5830 (0101 1000 0011 0000) --> 5D7F (0101 1101 0111 1111)

The CR95HF send back the response to indicate that some tags respond.

In addition, in the iso15693 RF protocol, the answer contains a CRC that allow to validate the response.

Due to this superimposed, the CRC is wrong and the CR95HF is able to detect it even if it send aback the answer : this is the reason why the last byte of the CR95HF response is not 00 but 03 = CRC error.

Suggestion : scan the last byte of the response : 00=OK 03=CRC error, several tags responses at the same time

2) INVENTORY/ANTICOLLISION on ISO15693 RF protocol

Inventory command is a very complex command. Depending on the flag value, this command can be used to detect one tag (1 slot) or several tags (16 slot + Mask management).

In your example, you send Inventory command with One Slot : all tags in the field response and you should receive 03 as last byte indicating CRC ERROR.

At this step, you cannot use Addressed mode because you don't know the UID of the tags.

This is the reason why that INVENTORY command can be send using 16-slot and mask management : you will be able to detect all tags in the field, separating the tags responses. This process is complex and described in ISO15693 spec.

Anyway, this complex process has been implemented in the M24LR-DISCOVERY firmware.

Please, uses the command < CR95HFDLL_STCMD, 02A00126 > : this command will send back the UID of all the tags in the field.

With this UIDs you will be able to send read/write commands in addressed mode (or selected mode).

Best regards

NFC / RFID customer support

Brian TIDAL
ST Employee

Hi,

make sure to use an MB1054B board with FW 3.7.1.

I guess you use the CR95HFDll_SendReceive API from the CR95HF.DLL. This API implements the SendRecv command from the CR95HF. This command returns a status byte (last byte of the response) with a CRC error flag bit and collision detection flag bit. See table 15 in the CR95HF Datasheet. When a collision is detected, the collision bit is set to 1 and only part of the data are valid. In that case the anti-collision has to be run.

See ISO/IEC 15693-3 for the anti-collision.

Rgds

BT

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.