Hey there!
I had a question to the flexDF. As I understood the flexDF has a UID, which is linked to me as a person, and sends out that UID when is “asked” by a sensor. By that every door, lock etc. will open, that allows my UID (->person) to enter right?
My question is, how the flexDF decides when it has to answer by sending out the UID and when it´ll send out the stuff which I added to the flexDF. I for example want to add my “profile” to it, so when a smartphone scans it by NFC, it´ll create a contact on that phone which includes my name, my phone number and my e-mail-adress. So to beginn with, is it possible to have the flexDF doing those things? And if yes how does the flexDF “decides” when to do what (when to send the UID and when to send my profile/contact)?
Good questions. The DESFire EV1 chip in the flexDF works differently than other “NFC” chips like the NTAG216 in the xNT and flexNT. If you want to dive into the nitty gritty, start by reading the ISO14443A standards documents, particularly “part 3” and “part 4” which govern initialization and transmission, respectively. Then read the chip spec doc for details about how the DESFire EV1 operates.
In short, ISO14443 supports anti-collision, which allows multiple tags in the same field to be talked to. Tags placed in the field are initialized, at which point they report a UID… then the tag that the reader wants to talk to is typically “selected”, which is a specific command. Other tags which are not selected are supposed to go to a halt state. The tag that is selected can then be communicated with.
An NTAG216 is a “type 2” NFC tag which has a read-only UID that is reported on initialization and selection, and you can also get this UID by issuing a read command to read the first couple pages of memory (since that’s where the UID is stored). You can also issue read commands to read the rest of the memory pages in succession, thereby constructing the NDEF record page by page until it has been fully transmitted to the reader, at which point an application typically does something with it… opens a URL, whatever.
The DESFire EV1 chip is a “type 4” NFC tag, which means it has some more interesting features. It goes through basically the same init and selection process, but afterward things are a bit different. Because the DESFire EV1 is set up like a tiny little 8k file system, you can have multiple files created on the chip. Each file has a specific AID or Application IDentifier. For NFC applications (storing of NDEF data), there is a specific AID used. There can be other AIDs on the chip as well, or you can allocate the entire 8k to be used for storing NDEF data. Definitely read the chip spec doc linked above to find out how all this works… it’s really quite interesting. At the end of the day though, the DESFire EV1 can only store and report data. How that data is stored, manipulated, and reported back will depend on the file type defined for your AID… but it’s all just storage in one form or another. For true processing power in an implantable form factor, keep an eye on VivoKey.
Oh, another thing to note about the DESFire EV1 is that you can set an option for the chip to return a randomized UID every time it is “selected”. If this mode is turned on, the only way you can get the real UID is by authenticating.