RFAL notification when card no longer available

[anotherstevest]

Greetings,

I've got a simple application wherein I'm exchanging ISO-DEP data using RFAL on a ST25R3916.  I'm only interested in handling the data read from the card once (of course) and then only process read-data again from either a new card OR the same card again *if* the card has been removed and re-presented (i.e. the card re-appears with a new UID).  I fully expected that the rfal state machine would have a "disconnected" (or equivalent) state, or, at least, would auto-deactivate which would be observable via a notification (i.e. within the discParam.notifyCb).  This does not appear to be the case.

My working (and feels dirty) solution is, once read, throw in a vTaskDelay (freeRTOS) so lower priority tasks can run while waiting on the card presenter to leave, and keep reading the tag (but ignore the data) till I get a read error.  Once I get a read error, I know the next tag is a "new" one, so I can deactivate and re-enter discovery.

Given my desires to stay at the rfal_nfc API level and use the rfal code as-is, what is the *right* way to obtain this behavior?

And, for completeness, note that my reader never sleeps.

Thanks,

Steve Stearns

[Brian TIDAL · Accepted solution]

Hi Steve,

a tag has to be considered as removed from the operating field once a reader is no longer able to communicate with it. When the tag is removed from the operating field, a communication error is returned (typically a RFAL_ERR_TIMEOUT) during the data exchange.

If I have well understood, your use case has to implement a tag removal detection procedure. This can be implemented as you described (i.e. send an I-Frame to just check the presence of the current tag). Due to ISO-DEP retries mechanism, the removal procedure may take an extended duration. An exemple of another removal detection procedure is available in the ndef_demo.c of the X-CUBE-NFC6 package:

• deselect the tag (rfalIsoDepDeselect(); after demoNdef())
• periodically poll and select the tag until an error occurs (search for /* Loop until tag is removed from the field */)

Rgds

BT

[anotherstevest]

BT,

Huh...  Ok... So if I'm  understanding the gist, the required approach really is one form or another of use the card, when done, switch to occasionally pinging it to see if you have lost communication, and when you have, move on.

Which is what I did and what it sounds like what the ndef_demo does.  Please confirm my understanding here and I'll "Accept as solution"

Now, just to feed my curiosity, is my expectation that, down at the RF a disconnect is already detected and could interrupt, correct?  Or does the RF really not have a clue unless a serial transaction requests that it  check?

Thanks for your assistance,

Best,

Steve.

[Brian TIDAL]

Hi Steve,

your understanding is correct.

During reader to tag communication, the reader generates the RF field, and the other device (the tag) uses load modulation to communicate. The tag is a passive device. The passive device does not generate its own RF field and relies on the field generated by the active device for power and communication. From theoretical point of view,  monitoring the signal strength can be used on reader side to detect the removal of the passive device. I believe this is not commonly used. 

Rgds

BT