STEVAL-25R3916B: Reader/Writer demo fails multi-tag detection (2cm & 10cm), but works correctly in USB mode

[Likhitha]

Hi Team,

I am working with the STEVAL-D25R16B kit and have encountered a critical discrepancy in detection range between the embedded "Reader/Writer" demonstration and the PC-based USB mode.

Here are the test results using ISO15693 tags:

The Setup:

• Tag A: Placed at 2 cm (Near)

• Tag B: Placed at 10 cm (Far)

1. Testing in USB Mode (PC GUI):

• Result: SUCCESS.

• The reader successfully detects both Tag A (2cm) and Tag B (10cm).

2. Testing in Standalone "Reader/Writer" Demo:

• Result: FAILURE.

• The reader detects Tag A, but fails to detect Tag B at 10cm.

• Tag B is only detected if moved closer to 5 cm.

Question: Could you please clarify which specific settings (Receiver Gain, Auto-Antenna Tuning, or Device Limits) differ between the USB GUI and the Example Firmware? We need to replicate the superior performance of the USB mode in the Reader/Writer.

Thanks,

Likhitha

[Ulysses HERNIOSUS]

Hi Likhitha,

this is typically not an effect of gains, etc. but an effect of a stronger (closer) tag masking a weaker (far away) tag.

The embedded demo strictly follows NFC Forum procedures which perform NFC-V Inventory with one slot at the beginning. If no errors are encountered then it does never perform Inventory with 16 slots.

The GUI on the other hand tries to discover as many tags as possible and goes straight to 16 slots. If the two tags don't fall into the same slot (first/last 4 bits of UID) then they are immediately recognized.

Best way to exercise this functionality from the GUI's "ISO 15693" tab.

In case you want to go more deep in guaranteeing to recognize multiple tags then you may want to have a look at rfalNfcvPollerSleepCollisionResolution().

BR, Ulysses

[Likhitha]

Hi,

Thanks for the help!

I'm unsure where to place rfalNfcvPollerSleepCollisionResolution() within the exampleRfalPoller.c flow.

Currently, exampleRfalPollerRun() loops through rfalNfcWorker(), rfalNfcGetDevicesFound(), and calls rfalNfcDiscover() on the state machine.

Does the sleep collision resolution API need to be called specifically after rfalNfcDiscover() returns?

Additional Observation: I also noticed a significant improvement in rfalNfcvPollerCollisionResolution() when I changed the compliance mode from RFAL_COMPLIANCE_MODE_NFC to RFAL_COMPLIANCE_MODE_ISO.

Thanks,

Likhitha

[Ulysses HERNIOSUS · Accepted solution]

Hi Likhitha,

yes, ISO compliance mode uses 16 slots from the start:

ReturnCode rfalNfcvPollerCollisionResolution( rfalComplianceMode compMode, ...
.....
    if( compMode == RFAL_COMPLIANCE_MODE_NFC )
    {
        /* Send INVENTORY_REQ with one slot   Activity 2.1  9.3.7.1  (Symbol 0)  */
.....
    }
    else
    {
        /* Advance to 16 slots below without mask. Will give a good chance to identify multiple cards */
        colPending = true;
        colCnt        = 1;
    }

About usage of rfalNfcvPollerSleepCollisionResolution(): Up to you how you want to use it. You could 

1. Implement your own small variant of  the polling loop (instead of rfal_nfc layer).
2. Patch existing rfal_nfc layer to call rfalNfcvPollerSleepCollisionResolution() instead of rfalNfcvPollerCollisionResolution()

Decision should depend on how many features of rfal_nfc layer you actually want to use and how strictly you want to stick with an NFC Forum or ISO compliant NFC handling.

BR, Ulysses

[Likhitha]

Thanks  a lot.