MC75A HF reading performance compared to competitor product

M Michal Drabek 3 years 5 months ago
1 0 0

Date: 8/9/2012 Product: MC75A HF WM6.5 Clarify: 2651474 A partner Sigmax is claiming about slow reading of the MC75A HF compared to unspecified competitor product.  

Mifare UltraLight: read all 16 blocks of 4 bytes

Motorola: 51 ms
Other device: 37 ms

Mifare 4K: read 153 blocks of 16 bytes that are used by our application. This includes getting the keys from the SAM, which is done all at once (we use Key B).

Motorola: 3558 ms
Other device: 1485 ms

 Details are outlined below. They are using own application, not our sample. Is that something you may help or do you know a contact for this?

 

Their questions are:

1)      Is this normal timing?

2)      I have not seen any speed settings that I think I can tinker with. Are there any and can you tell me how to set them? I used the default baudrate (115200) and also 230400, but the times were the same.

3)      I used SCARD_POLL_A just once. Does that matter?

4)      Also the communication with the SAM is much slower. Is this a reader speed setting?

--------- The test program I am using is a C# program that P/Invokes the WCE_StelHost.dll functions. In particular, I’m using the following functions (the test is reading blocks 88-255 (168 blocks in 18 sectors) of a Mifare Classic 4K card):

-      SH_Init_Library(): just once

-      SH_MFCRYPTO_Init(): just once

-      SH_MFCRYPTO_LoadKey(): For every sector

-      SH_MFCRYPTO_Authenticate(): For every sector

-      SH_MFCRYPTO_Read(): For every block

The total time is between 2900 and 3050 ms in total, including some C# handling of data and other overhead. I also measured the time spent in each of the above functions:

-      Total time this run: 2914 ms

-      SH_MFCRYPTO_Init(): 0 ms

-      SH_MFCRYPTO_LoadKey(): 787 ms (~44 ms per sector)

-      SH_MFCRYPTO_Authenticate(): 225 ms (~12 ms per sector)

-      SH_MFCRYPTO_Read(): 1896 ms (~11 ms per block)

-      C# overhead: 2914 – (0+787+225+1896) = 6 ms

 

Depending on the actual reader we have, we can store the keys once and then switch sectors more cheaply (authenticate (12 ms) is about the same as a block read (11 ms)). But nevertheless, all necessary keys need to be loaded once, taking 44 ms per key.

 

NB: The 3558 ms reported before was in our real application which has some more overhead and also gets the keys from the SAM (see below). On the other hand, the 1485 ms reported for the other device was for the same application with the same overhead and also a 806 MHz CPU.

 

In an additional test, I tested the SAM’s speed too, in particular the command to calculate the key to login. The results are (both measured in our real application, so it may include some overhead, but that is the same for both devices):

-      Motorola: 460 ms per card (set of 18 keys)

-      Other device: 86 ms per card (set of 18 keys)

 

I use the following SH_SCARD_Discover() schedule (maybe it matters):

byte[] schedule = new byte[]

            {

                50,  // startup (100 us units) (iso 14443 says card should be ready within 5ms

                10,  // between each type (100 us units)

                0,   // Slew rate (10 us units, deprecated)

                1,  //SCARD_POLL_A,          // 1st type A poll

                0  //SCARD_POLL_END         // End of polling schedule

            };
--------- is this something we can handle?  Many thanks Michal

CONTACT
Can’t find what you’re looking for?