Quickly reading NFC V tag from ST25R3920 with STSW-ST25RFAL002

[powersnake]

Hello,

I am designing a system that uses the ST25R3920. I am using the STSW-ST25RFAL002 software library to interface to the NFC reader.

For performance & power saving reasons, I am attempting to complete NFC transactions as quickly as possible, and turn off the RF field between transactions. The typical use case of the system is that once a tag is detected, an initial transaction will take place. After that, the likely case is that the same tag will be present, and no other tags will be present. But there will be cases where that tag will disappear, and then the same tag or a different tag may appear at some time in the future.

I am wondering what sort of optimizations I can make by assuming that the same tag will be there, and there should not be any collisions with other tags in the area.

 

So far, I found that after performing discovery to find a tag, and then completing the first transaction with the tag, I can call

rfalFieldOff()

And then later resume transactions by calling

rfalFieldOnAndStartGT()

This seems to allow me to skip the discovery part of the rfalNfcWorker state machine and resume communications with the tag.

Once a failed communication has occurred, I can call

rfalNfcDeactivate()

and then go back to initiating a new discovery with

rfalNfcDiscover() 

My questions are:

1. Are there any pitfalls to the above approach? Things I'm not considering and cases that may not be covered?

2. Are there any other calls that I should be making in addition to the rfalFieldOff & rfalFieldOnAndStartGT calls, in order to leave the library state machine in a good condition?

3. Are there any other optimizations that the RFAL/ST25R3920 would offer to help even further improve the performance?

[Ulysses HERNIOSUS]

Hi powersnake,

if you really need to optimize for speed then I would recommend not using rfal_nfc layer at all but to go down to rfal rf layer. Send single frames and expect answer. Rfal_nfc layer is doing procedures according to NFC forum having a technology detection and a collision resolution phase, creating some overheads.

For NFC-V you have multiple options: You could even just send an un-addressed read block command. To which all tags in the field would answer simultaneously. The reader will only get a valid answer if the response from one is sufficiently stronger or if there is only one tag. But if your usecase is anyhow just one tag, it would work.

BR, Ulysses

[powersnake]

Hi Ulysses,

 

Thanks for the tips. I was able to see a significant improvement in performance by sending un-addressed commands. This will work great for my use case.

Can you please clarify, though, when you mentioned using only RFAL_RF layer - did you mean to suggest that I stick to simply turning on/off the RF field, and then issue commands via calls to functions such as

rfalNfcvPollerReadMultipleBlocks

Or is there some other lower-level function call that I should be making to achieve this?

Thanks again.

[Ulysses HERNIOSUS]

Hi powersnake,

 

yes, that is what I basically meant (you had mentioned rfalNfcDiscover() and I would use that one for your use case where your prio is being fast and having minimal overhead).

 

BR, Ulysses