What is the actual reading speed of a nfc reader (PN532)?

Question

I have spent a lot of time trying to improve reading speed for a Desfire EV1 with a PN532 SPI reader and the times I get are too high compared with a MFRC531. I'm using libnfc for PN532 and I used NXP native commands for MFRC531.

Could someone tell me how long it takes to do the following commands over a Desfire EV1?

I can't reduce more than 92.76 milisecons. I've 144 bytes files inside the desfire and for read it takes 102.63 miliseconds what is a speed of 11 kbps. If Desfire's protocol baud rate is 424kbps, what is happening me? Is it possible that it is due to the internal microprocessor that mounts the pn532 and the rc531 lacks it?

*** mifare_desfire_select_application ***
===> 0000   90 5a 00 00 03 00 00 00 00
<=== 0000   91 00
PICC replied OPERATION_OK
*** mifare_desfire_get_version ***
===> 0000   90 60 00 00 00
<=== 0000   04 01 01 01 00 18 05 91 af
*** mifare_desfire_get_version ***
===> 0000   90 af 00 00 00
<=== 0000   04 01 01 01 04 18 05 91 af
*** mifare_desfire_get_version ***
===> 0000   90 af 00 00 00
<=== 0000   04 60 75 1a 5f 28 80 ba 25 51 9e 10 51 11 91 00  
PICC replied OPERATION_OK
*** mifare_desfire_select_application ***
===> 0000   90 5a 00 00 03 00 00 01 00
<=== 0000   91 00
PICC replied OPERATION_OK

Time elapsed: 0.092768s

Answer 1

The 424 kbps of the DESFire refers to the contactless (wireless) interface between the reader and the DESFire itself and is often a limiting factor as mentioned by @Mahmoud.

Yes, @Mahmoud is correct that the default contactless baud rate is 25% the full speed, 106kbps.

Assuming the DESFire tag has a reasonably matched antenna coil, and the reader has a decently tuned / matched antenna coil there's no reason you could not achieve the higher 424 kbps baud rate. A perfectly tuned/matched coil isn't necessarily required.

However, the reader must negotiate this with the DESFire to enable the higher baud rate. On the PN532 this is done using the InPSL command, on page 125 of the PN532 user manual. If you perform this command after the initial DESFire detection (anticollision using the InListPass or InAutoPoll of the PN532 for example) you will see that higher baud rate take effect.

Another tip to reduce the time it takes to perform your operation would be to skip the get version commands and go straight to the select application. Unless there's a reason you need to confirm a specific version and memory size of the DESFire, I recommend skipping that because it takes three additional transceives to get the version information (the 0xAF commands that follow the initial get version command). DESFire chips have full backwards compatibility with previous versions. So for example, if you needed features of the original D40 chip model but the chip presented is the EV1 version, the EV1 will still have complete backwards compatibility with all D40 features. The same would apply for EV2 and EV3 models. In the case where you're using a feature that is only available on the more modern version (EV2 for example), a DESFire chip of the previous model would just reject that command so you'd know then that there's an older model DESFire being presented. In my experience working with DESFire chips I've never verified the versions because of these backwards compatibilities. I use EV2 or later, and the incompatible (older) chip models such as D40 and EV1 aren't even available in the market anymore so you don't have to worry about it for the most part.

Answer 2

data transfer speed is depended on PCD-MCU transmission baud rate and PCD-PICC transmission baud rate and is mostly limited by the second one (also known as contact-less uart). PCD chips operate in low baud rate in default(e.g. 106 K). Accessing higher baud rates need much better Antenna and transmission line network design as I know.