Using the ST25R3911B Disco GUI, we are seeing the message "ext field detected, not polling" in the status window. What does this mean?

[CFerr.1]

We are trying to increase the read distance by adding an RF amplifier, routing the "Rx" chain through an external divider to RFI1&2. We cannot find any reference to this message in any of the docs or source code we have. Has anybody experienced this?

[Ulysses HERNIOSUS]

Hi,

our ST25R3911B rfal software does not just turns the field on but performs a so-called RF collision avoidance (ISO 18092). It senses the field level on the RFIs and triggers potentially I_cac which gets translated into the message you have seen.

I don't know why this happens or how you can avoid this. From software you have an option to set different threshold levels in the External Field Detector Threshold Register.

Regards, Ulysses

[CFerr.1]

Thanks for the reply. I see two types in reg 0x30, Peer & Collision. I suspect this has something to do with how we are trying to handle Rx when using the amplifier for increased read distance. We have limited the RFI through the divider but something is still wrong. With the GUI, we can get reads but within a few seconds, the GUI crashes. We restart and all is good until we attempt to read again. If we disconnect the RFIs, the GUI runs continuously. Using a differential probe on the RFI, I do not see any overdriving. the A/D values never approach saturation that I can see. Any ideas as to what might be causing the app to stop? We are running version 1.2.8.0.

[Ulysses HERNIOSUS]

Hi,

it may happen that if in ISO15693/NFC-V the receiver gets completely flooded then the anticollision takes several seconds. The GUI times out after max 1 second so it may be this timeout. This shouldn't happen when disabling NFC-V in e.g. Polling Tab.

If this doesn't help then please do logic analyzer traces (SPI + IRQ). In a further step you may also want to look into some internal receiver signals to potentially identify noise from your amplifier/changed hardware. (please refer to tana bits in the DS).

Regards, Ulysses

[CFerr.1]

I am using polling as shown in the attached. The crash happens pretty quickly and on this last attempt, I had FF in reg 0x27 just to see if no Tx power would allow the GUI to keep running. But the flooding hypothesis is what I was considering. I do have a differential probe on the RFI signals and do not see anything significant there. I will look at the SPI & IRQ sigs next.

[CFerr.1]

I did take a look at SPI comms & the IRQ line. With those signals instrumented, the app ran without a hitch - several thousand reads. Now I'm really confused. I took a look at the tana bits and it looks like those would be helpful. As these appear to be outside the scope of the GUI project code, is there any example code available to jump-start us? Or can strings be implemented in the debug window? Again, we are primarily working with 15693 and I saw a note about string construction not being allowed for that protocol as it is handled internally. Is source code available for the GUI project?

[Ulysses HERNIOSUS · Accepted solution]

tana bits are more of a static setting: You have multiple options: Just go to the register map T 01 and change them or enter them as appropriate into the analog config in CHIP_INIT as user_defined (e.g. 0x81, 0x0f, 0x0b) or use the settings in Debug tab (these will dynamically switch the settings - better for logic analyzer). And of course observe on CSI/CSO.

No idea why attaching probes helps - unless you have introduced a problem with power supply.

Regards, Ulysses