0

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
crossmax
  • 346
  • 3
  • 20
  • I guess it should read milliseconds instead of microseconds. It seems somewhat optimistic to expect the communication baudrate as constant data capacity ignoring all protocol overhead. Also I consider 92 ms as fast enough if the scenario involves a human presenting the tag. – guidot Jun 01 '18 at 07:57
  • What is your measurement setup for the two devices? What time interval do you measure to estimate the transfer speed? What commands do you exchange? – Michael Roland Jun 04 '18 at 08:37
  • @guidot You're right, are miliseconds, my fault. I've paste this exchange frames to can compare with other users, but in my app I've read about 11 Desfire files and it takes 1 seconds aprox. When I read a one file (144bytes with 0xBD Desfire command) it take 102 miliseconds (about 11kbps) and the full validation process becames in slow for human too. These times were much reduced when I used an MFRC531 reader – crossmax Jun 04 '18 at 09:18
  • @MichaelRoland I measure the times with the linux function `gettimeofday` (`/sys/time.h`). I'm calculating transfer speed when read 144bytes (one dedfire file) with `0xBD` Desfire command. Internally PCD and PICC exchange more than 1 frame (packet) because the file is divided into several parts (sending `0xAF` command), but I think it's a pretty real estimate of the speed. – crossmax Jun 04 '18 at 09:29

2 Answers2

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.

Papyrus
  • 232
  • 3
  • 10
-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.

Mahmoud Hosseinipour
  • 293
  • 3
  • 20