Topic: card removal detection

Hi,

I am doing an application for which one I need to be able to detect removes of cards. I actually deactivate the field and do a new select iteration to check cards that are staying on the reader, by comparing this list with the previous I am obtaining card removed list.
Here is a part of my current code :

        if (dll_nfc_configure(mDevice, NDO_ACTIVATE_FIELD, false))
            if (dll_nfc_configure(mDevice, NDO_ACTIVATE_FIELD, true))
                TeSleep(100); // In ms

        while (dll_nfc_initiator_select_tag(mDevice, NM_ISO14443A_106, NULL, 0, &cardInfo))
        {
                }

It works well but I have few questions on validity of this solution :
1) deactivating field is it really instantaneous? Or I also need add a little sleep?
2) is there a way to know real delay of field activation? Maybe by using a function that test it?

My goal is to reduce the delay between card events.

I think their is an other way to explore. It may be possible to test write on a specific sector often and wait an error synonymous of card removal but I fear to alter fast card memory. It certainly very limited in write cycles, and after risk to obtaining write corruptions will increase hugely.

Re: card removal detection

Hello,

Xavier Bigand wrote:

1) deactivating field is it really instantaneous? Or I also need add a little sleep?

Give it a try! I think you could add some miliseconds delay, in order to be sure that targets disable itself (i.e. active ones have to detect the "unavailable" external field to switch off itself)

Xavier Bigand wrote:

2) is there a way to know real delay of field activation? Maybe by using a function that test it?

maybe you could write a loop that enable/disable the field and use a tool the detect the 13.56Mhz generated wave.

Xavier Bigand wrote:

I think their is an other way to explore. It may be possible to test write on a specific sector often and wait an error synonymous of card removal but I fear to alter fast card memory. It certainly very limited in write cycles, and after risk to obtaining write corruptions will increase hugely.

I don't understand the process you want to test.

Romuald Conty

Re: card removal detection

rconty wrote:

Hello,

Xavier Bigand wrote:

I think their is an other way to explore. It may be possible to test write on a specific sector often and wait an error synonymous of card removal but I fear to alter fast card memory. It certainly very limited in write cycles, and after risk to obtaining write corruptions will increase hugely.

I don't understand the process you want to test.

The test consist on doing the same as for network, to know if we are always connected to a machine we just have to ping (sending a packet) frequently and analyze the return to know if it success or failed. With libnfc this method match with a write operation on a card and wait the error or not.

Re: card removal detection

Xavier Bigand wrote:

With libnfc this method match with a write operation on a card and wait the error or not.

IMHO, a read command could also be used.

Romuald Conty

Re: card removal detection

Does the function nfc_initiator_select_tag will re-detect a removed card? If not is it possible to add a function in the lib to clear cards buffer to be able to scan card for each nfc_initiator_select_tag calls, or it's a physical/protocol limitation?

Re: card removal detection

Xavier Bigand wrote:

Does the function nfc_initiator_select_tag will re-detect a removed card?

nfc_initiator_select_passive_target() is a simple function that retrieve all availables tags in field (except for Jewel and FeliCa).
So, if the tag is in field, it's detected, if a tag leave the field and come back, the function will detect it.

Xavier Bigand wrote:

If not is it possible to add a function in the lib to clear cards buffer to be able to scan card for each nfc_initiator_select_tag calls, or it's a physical/protocol limitation?

I don't understand at all.

Romuald Conty