2025-02-05 11:00 PM
Hi,
About rfalST25xVPollerFastReadMultipleBlocks and rfalNfcvPollerReadMultipleBlocks。
I use st25r3916 to read NFCV tag.The farthest reading distance of my reader can reach 70mm.When I use the command RFALNFCVPoller Read Multipleblocks, I can successfully read data between 0-70mm, but when I use RFAL ST25XVPoller FastTreadmill Blocks, when the amount is between 55 mm and 70 mm, I will fail to read, and the returned error codes are mainly 04, 09 and 21. There is no problem with tag. I can read it with other competing products in this position.
How can I determine what the problem is, the software configuration problem? Or is there not enough energy after the RF field is far away?Do you need any other configuration to use fast reading?
I hope you can help me answer it. Thank you.
2025-02-06 12:10 AM
Hi,
do you use an ST board such as X-NUCLEO-NFC06A1, X-NUCLEO-NFC08A1, ST25R3916-DISCO or STEVAL-25R3916B or your own custom board?
Do you use the ST25R3916 or the ST25R3916B?
Rgds
BT
2025-02-06 01:42 AM
Hi.
I use my own custom board.The IC is ST25R3916.The matching circuit is vertically close to the antenna. When I keep the antenna away from the matching circuit, there will be fewer errors.The circled part is the matching circuit.
2025-02-06 02:28 AM
Hi,
on our demos I don't experience reduced read range of the fast commands.
It sounds like you have a noise floor which affects the sensitivity. When using normal speed (26kbps) one reporting period is twice as long as for fast commands and I suspect that the longer duration will filter most of your noise floor.
I would start looking at receiver signals on CSI/CSO or TAD1/2 using tana modes to assess the amount of noise there and see which changes on your board help to reduce it.
BR, Ulysses
2025-02-10 12:07 AM
Hi.
If there is a noise floor, it should have nothing to do with the reading distance, but the actual situation is that every reading is successful at 0-50mm, and reading failures frequently occur between 50-70 mm.
This should not be related to the reading distance, right?Do you have a tool to parse spi data? How to parse the captured SPI?
When the normal speed (26kbps) is used, there is no reading failure in all readable distances.What is tana mode and what is the normal signal range?
Is there any information or same case list in this regard for your reference?The software is based on NFC061, but the detection logic in it has been changed. Will it have anything to do with this?
2025-02-10 01:30 AM
Hi,
it could also be that the card runs into the power limit during the response. Which card are you looking at?
At this point I would not yet rule out also a noise issue. For SPI: Please use a logic analyzer and trace SPI+IRQ pin. You will need to inspect the various commands as per datasheet. In the DS you will find the various commands. A quick top-level analysis for you as you are currently more on RF: Look for INT pin going high and then low. This is where you see the reason for the interrupt and can find the frames being exchanged. For NFC-V you will typically look for:
Compare good received and bad received frames.
For analyzing power limited vs sensitivity limited, please see this thread here:
how-to-use-st25r3911b-for-long-reading-distance-40cm
The tana you will find a description in the DS. You would need to compare again good cases with bad cases. E.g. compare to X-NUCLEO-NFC06A1 signals.
There is one possible caveat for fast mode: It requires slightly smaller MRT time than 26kbps mode. Our RFAL is using a setting which is good for both. Are you using the same value as RFAL?
BR, Ulysses
2025-02-10 10:33 PM
Hi.
The card I use is MB89R118C of NXP. Regarding SPI, I have captured the situation of right and wrong (see the attachment). As you said, when it is right, it is 5A-> 40 when it is wrong. Because I have changed my logic, I can see it from "spidectedtag. xlsx". I'm not sure if there is any problem with my change. Can you help me check it?
I'm still checking the mute problem. I haven't changed the MRT time, which is consistent with the source code.
2025-02-11 05:39 AM - edited 2025-02-11 06:29 AM
Hi,
The 40 just indicates I_nre (no response timer) has triggered.
BR, Ulysses
2025-02-11 05:18 PM
2025-02-12 02:50 AM
Hi,
not too much to be seen from the trace: 3916 just does not see a response. With such I would suppose that the tag is power-limited and does not respond anymore. Best to be confirmed by looking at the field and a field probe as described in below mentioned ticket.
BR, Ulysses