Android NFC scan time

Question

I am working with Android and ISO14443 type B tags and there is an issue that I am not able to solve. Hopefully someone can give a hint.

When NFC setting of the phone are turned on, it starts sending REQA and REQB commands in order to discover if any tag is present. The issue is that by default this is done with a periodicity of 2 seconds and I would like to modify that time to make it shorter.

I see that most apps maintain this scan period, but there are some apps such as TagInfo from NXP that reduce it to 250 ms.

Among all information available for android NFC, I didn't find anything about tag scan time.

Does someone know about this scan time? How is it possible to modify it?

Thank you in advance. Jon

Genethlialogy

This? – Spohr

Thanks. I guess the key is to use nfcAdapter.enableReaderMode() instead of nfcAdapter.enableForegroundDispatch() and change EXTRA_READER_PRESENCE_CHECK_DELAY option. – Genethlialogy

Did this work? Can you post the specific code you used? – Seminar

Answer 1

With some experimentation using an LG Spirit and the field detector PCB packaged in NXP's NFC dev kit, I found the following, all absent any NFC tag being interrogated:

• No matter what mode and settings I used, NFC polling (assumed to correspond to spikes in detected RF field) occurred with a period of about 205ms
• using nfcAdapter.enableForegroundDispatch(), the regular polling events were only 20us long, but there would be much longer polling events (meaning the NFC field stayed energized) at irregular intervals
• using nfcAdapter.enableReaderMode(), the field on-time varied based on which signaling types were enabled. With all enabled, the field was energized for 125ms - that's right, more than 50% of the time the NFC field was turned on! While with e.g. only NFC-A enabled, it was only energized for 2.2ms
• The NfcAdapter.EXTRA_READER_PRESENCE_CHECK_DELAY setting appeared to have no effect whatsoever on the NFC polling interval. I think this setting only applies when a partial connection sequence has occurred, and why it's used as a protocol bug fix.

Here is what I would conclude and advise: I think that the 'default' of dispatch mode allows the OS to do clever power optimization by minimizing the percentage of time the NFC field is on, responding if something interacts with the NFC field. The power optimization must take high priority, because this mode of NFC scanning enabled anytime the phone's screen is unlocked.

A tradeoff of dispatch mode is likely that energy-harvesting (passive) tags require closer proximity to the phone's antenna before they are able to power up and interact.

In contrast, reader mode allows you to force the NFC field to be on for a minimum percentage of the time, though it appears you can't adjust the polling period. You can also only indirectly adjust the percentage of the time the field is on, which may or may not produce any marginal improvement in time-to-connect for passive tags.

There is probably a whitepaper out there with detailed best practices. My advice would be that if you want faster passive tag reads, use reader mode and enable only the signaling type(s) you need.

Seminar