NFC reading distance has a dead spot

[KKjel.1]

Hi

I have a new PCB design using the ST25R3918 chip.

The application is quite simple: An NFC tag (sticker) identifies a consumable in a machine.

The PCB/NFC reads the tag to check simple data.

The distance from the NFC coil to the tag is fixed in the machine, 15mm +/- 5mm.

In free air, I have a reading distance of appr. 50 mm, very stable. Great!

My problem is in the machine:

The NFC tag is mounted on the outside of a bag-in-box system.

The bag is coated with aluminium. Not good, I know...

6 mm cardboard makes a distance to the aluminium bag, so that we have a max reading distance of app 30mm.

This is actually OK.

BUT: There is a "dead spot" somewhere in the middle of the reading distance.

The spot is like 1-2 mm wide. Very little difference can make it work as a charm, or just fail.

See below.

I don't see this dead gap when the tag is not on the bag, so the problem is close related to the aluminium bag under the tag.

Why does this dead spot happen?

My theory is that the PCB/GND and the aluminium bag forms a capacitor. When the distance is "correct", the center frequency of this "filter" eats all the 13,56MHz energy, and reading is impossible.

Is there a way to "tune" the RF in the ST25R3918, to be able to change the tuning if the reading fails, and in that way "move" the dead spot to another distance?

Thanks for any ideas!

[Ulysses HERNIOSUS · Accepted solution]

Hi Kaare,

I think we would be able to use Pulseview. If you could attach traces here, would be interesting for us. Please also include the IRQ because it helps a lot for navigating the traces.

In the trace I can see that ST25R3918 does detect collisions during anti-collision where I presume there shouldn't be any. Things to look/try:

1. Look at RFI voltage level, verify it to be in the correct area.
2. Switch to I/Q demodulator: Inside your analog config table for A106 RX change: 

   ST25R3916_REG_RX_CONF2,   0xFF, 0x2D​

    to

   ST25R3916_REG_RX_CONF2,   0xFF, 0xED​

   This may provide some more noise resistance.

3. Change collision level setting:
   

   ST25R3916_REG_CORR_CONF1, 0xFF, 0x51​

   
   from 28% to 53%
   

   ST25R3916_REG_CORR_CONF1, 0xFF, 0x53​

4. Don't use separate collision setting (corr_s6): Remove "Poll NFC-A Anticolision setting" from analog config.

BR, Ulysses

[KKjel.1]

Hi Ulysses

Thanks, I will try the settings, and see if it does some magic.

Here is the trace dums ("beep" version is the one where comm is OK. The PCB beeps every time a tag is detected OK)

BR Kaare

[KKjel.1]

Hi Ulysses

I have now tried the new settings for I/Q demodulator and Collision level, on three different setups/PCB's.

Result: It works !

- The dead spot is gone

- When coil and tag is extremely close, it is very immune to the position of the tag/coil. Before the changes, they had to quite precise. With the changes, they can be mis-alligned quite a lot, before it can't read the tag.

The max reading distance is still the same as before, and we still need the current distance between tag and aluminium bag. But this is fully accepted, as long as it works within this distance.

Thanks for your help in this case!

Best regards, Kaare

[Ulysses HERNIOSUS]

Hi Kaare,

I think I can recommend the I/Q demodulator without any caveat. With the different collision level setting you may experience two tags not always be recognized. You didn't do experiments with only changing the I/Q setting, did you?

Looking through the traces I also see some potential in the software to better filter such noise conditions as the noise seems to have produced additional bits after the last bit which were treated with error. I think software is not required to do such.

BR, Ulysses

[KKjel.1]

Hi Ulysses

No, we only did the test with both changes.

But then I also saw your number:

"Don't use separate collision setting (corr_s6): Remove "Poll NFC-A Anticolision setting" from analog config."

I will also test with this change.

I am not sure I fully understand what you mean by the "... as the noise seems to have produced additional bits... software is not required to do such".

Is there some kind of settings which can avoid/minimize this type of noise, other than the changes already made?

br, Kaare

[Ulysses HERNIOSUS]

Hi Kaare,

I was giving the three options in a specific order: If 2. suffices, use 2. Only if that is not enough then maybe go additionally to 3. or even 4.

4. essentially disables recognition of tags which are not equally strong.

One more side finding on your trace: Your driver is setting arbitrary don't care bytes on MOSI. We may in future issue a recommendation to rather always send 0x00 when there is an "X"  denoted in the DS.

Instead of playing with registers you could also start looking into the noise in your system (supply, etc.) to identify real analog reason for the noise. But if you have now a working solution, you maybe don't want to spend effort into this.

BR, Ulysses