5 Replies Latest reply: Mar 5, 2013 6:13 AM by fgrieu

hi,
I have an ATR which is Negotiable mode:
TA1 ===> 96 h
TA1 ===> Fi = 9
TA1 ===> F = 512
TA1 ===> Di = 6
TA1 ===> D = 32
TA1 ===> F / D = 16 cycles/ETU
TA1 ===> Fmax = 5 MHz

f = 3.5712

How can I calculate the speed of reader?
• ###### 1. Re: reader's speed
3Bh => direct convention
7Dh => TA1 TB1 TC1 follow, no TD1, 13 historical bytes, card proposes T=0 protocol only, no TCK
96h => TA1=96h, coding Fi = 512, Di = 32 cycles, fmax = 5 MHz
00h => TB1=00, No Vpp
00h => TC1=00, No Extra guard time, thus 12 ETU per byte (under T=0)
80 31 80 65 B0 83 11 48 C8 83 00 90 00h: historical bytes, decoding left as an exercise.

Thus the communication speed between a conformant reader and the card, if the reader perfoms no reset after this ATR (which could change the ATR), and performs a successful PPS exchange with PPS0 indicating T=0 and PPS1 set per this TA1 at 96h (which would be usual), is going to be at most 5000000*32/512 = 312500 bit/s (within a tolerance of about +/-1%) and about 5000000*32/512/12 = 26042 byte/s peak.

In fact, most USB PC/SC readers will use a clock less than 5 MHz, derived from a 12 or 48 MHz master clock. Usual frequencies for USB readers are 4.8 MHz, 4.0 MHz, and 3.692 MHz, correspondingly lowering the peak speed. Some readers can be programmed for over-clocking, or/and requiring faster speeds (lower F/D) than the card asks in the ATR, which the card may accept of not.

Update: The question says f=3.5712 MHz, witch is unusual for an USB reader. Assuming that f=3.5712 MHz, speed is going to be 9600 bit/s nominal (800 byte/s peak) during ATR, or without PPS; and 3571200*32/512 = 223200 bit/s (18600 byte/s peak) after PPS per TA1. Note: f=3.5712 MHz looks suspiciously like 9600*372, or/and close to the more traditional 3.579545 MHz which was customary on early readers using an NTSC color burst crystal. f=3.5712 MHz could be obtained using a 14.2848 MHz crystal divided by 4 to obtain f=3.5712 MHz, and an UART operating at 14284800/93/16 = 9600 bit/s during ATR, 14284800/4/16 = 223200 bit/s after PPS.

Actual speed of operation depends on a lot of other considerations. There's the duration of execution of the command by the card (which can be several seconds for some commands, e.g. generation of an RSA key). PPS negotiation may or may not be attempted by the reader (most USB PC/SC readers will with the suggested ATR, but that might not apply to a POST), that might be with the parameters suggested by the card (common), or others (rare), and may succeed or not (rare except for parameters other than those suggested by the card). There's the reader/drivers/USB overhead (often milliseconds per command; plus some overhead per byte, which can be very high with RS-232 or other asynchronous serial readers, typically less with full-speed USB readers). Some cards and readers have inter-character delays of significantly more than 12 ETU, especially at high bit rates. Under T=0, there is overhead for protocol bytes and turnaround (typically, that adds a minimum of 20 ETU per TPDU) and the overhead for Get Response in Case 4 APDUs.
• ###### 2. Re: reader's speed
I can calculate the card's speed, as the value of F and D are certain in specific mode, the speed can be easily calculated (using the following formula: speed = f*D/F bit/s), but my problem is calculating the card's speed in negotiable mode.
As far as I know the F and D values (which are readable from the ATR TA1 byte), are the max values in negotiable mode. So I can calculate the speed with the max values of F & D. Is there any way to find out the exact values of F and D (which should be less or equal to values got form The ATR)?
I need them in order to calculate the exact speed.
• ###### 3. Re: reader's speed
I can calculate the card's speed, as the value of F and D are certain in specific mode, the speed can be easily calculated (using the following formula: speed = f*D/F bit/s), but my problem is calculating the card's speed in negotiable mode.
As far as I know the F and D values (which are readable from the ATR TA1 byte), are the max values in negotiable mode. So I can calculate the speed with the max values of F & D. Is there any way to find out the exact values of F and D (which should be less or equal to values got form The ATR)?
I need them in order to calculate the exact speed.
• ###### 4. Re: reader's speed
I can calculate the card's speed, as the value of F and D are certain in specific mode, the speed can be easily calculated (using the following formula: speed = f*D/F bit/s), but my problem is calculating the card's speed in negotiable mode.
As far as I know the F and D values (which are readable from the ATR TA1 byte), are the max values in negotiable mode. So I can calculate the speed with the max values of F & D. Is there any way to find out the exact values of F and D (which should be less or equal to values got form The ATR)?
I need them in order to calculate the exact speed.
• ###### 5. Re: reader's speed
There is no TA2 in the ATR, thus I see no reason to think Specific Mode gets involved. Most likely the card is used in Negociable Mode (unless there is another reset).

That is, the card proposes a negotiation to the reader. It is up to the reader to make it, or not. One can't tell for certain from the ATR what the reader will do; from that information, one can only attempt to guess what the reader and card will do. With that ATR, a typical modern PC/SC USB reader will see that it supports the Fi/Di = 512/32 ratio in the TA1 proposed by the card, perform PPS with PPS1 according to that, it will be successful, and communication will work according to that. But you are not using a typical PC/SC USB reader (the unusual frequency f = 3.5712 MHz is a sign of that). It could be that the reader does not support F/D=16 (TA1=96h), and does not even attempt PPS, remaning at F/D=372/1 as used in the ATR. Another possibility is that the reader attempts PPS with other parameters (e.g. F/D=372/4, corresponding to TA1/PPS1 of 13h, which is common in an EMV context). Most modern cards will accept that.

Note: it is frequent that TA1 in the ATR does not reflect the fastest speed (the lowest F/D) actually supported and accepted by the card; but it is rare that a faster speed gets negotiated automatically, because most readers will not try a PPS negotiation with a PPS1 proposing an F/D lower than the Fi/Di in the TA1 in the ATR.

To determine the actual bit rate, f, F/D, operating voltage, and debug the PPS negotiation (and more generally see what's the culprit when things are too slow), I use an oscilloscope or/and logical analyzer hooked on I/O, CLK, VCC, and RST. I often see lots of differences from one reader to the other, and the OS/driver on the host. I also have special cards with a command to get the F/D ratio (and an approximation of f) as currently used, but there is no standard in Java Card for that, AFAIK.

For an application-software-only solution, I would recommend to time the execution speed of a Get Response command with a large data size and small (but positive) size. If there is little overhead on the reader side (which is not unlikely if the CPU of the reader carries the application), the actual bit rate is likely close to 12*(s1-s0)/(t1-t0) where s1 and s0 are the large and small sizes in byte, and t1 and t0 are the execution time (in microsecond for a result in MHz). Of course this is only as meaningful as the determination of t1-t0 is precise, and accounts for various overhead (the actual bit rate likely is more).

Note: some readers have a command or utility to report their current speed. E.g., for several OMNIKEY readers, their Diagnostic Tool
http://www.hidglobal.com/drivers?field_brand_tid=24&product_id=7911