Re: MUSCLE Work Waiting Time question
On 7 June 2001 Carlos Prados wrote > Re: MUSCLE Work Waiting Time question > > Hi, > > > It seems, therefore, that changing the value of Di > > in the ATR does not > > change the value of the wwt, but changing the value > > of Fi does. Is this what > > the writers of 7816-3:1997 meant? I don't think so, > > because the wwt required > > is related to the values of clock sent to the card, > > the internal structure > > of the card's CPU and clock processing circuits, and > > the application > > algorithm programmed into the card. Changing Fi and > > Di doesn't change the > > way that the card runs its application code, and so > > should not change the > > wwt - but changing Fi does change the wwt. > > > > FI from the card, besides influencing I/O bit rate, > > also indicates the max > > clock frequency that the card can be run at. So: > > > > FI = 0 (means Fi = 372), Di = 1 gives a bit rate of > > 9600 in our example, a > > wwt of 1 sec, and indicates (Table 7) a max clock > > frequency of 4 MHz > > (typical for a card run at 3 Volts Vcc) > > > > FI = 1 (also means Fi = 372), Di = 1 gives a bit > > rate of 9600 in our > > example, a wwt of 1 sec, and indicates (Table 7) a > > max clock frequency of 5 > > MHz (typical for a low cost card run at 5 Volts Vcc) > > > > FI = 3 (means Fi = 744), Di = 2 also gives a bit > > rate of 9600 in our > > example, but changes the wwt to 2 sec, and indicates > > (Table 7) a max clock > > frequency of 8 MHz (e.g. for a Hitachi 3109 card as > > used by "rollout spec" > > Mondex in a single application environment) > > > > But the reader that I'm ussing provides 3.5712 MHz > constant clock rate to the smartcard regardless of the > ATR in the card. The clock frequency figures given in the above explanation are the maximum that the card is rated to use. The card can be run at any frequency from 1 MHz up to the maximum indicated by the value of FI indicated in the ATR. It is very rare to find a card reader that can switch frequencies (and in other places I have argued that the combined requirements of 7816-3, EMC regulations, and the desire to protect the reader's interface circuitry from static discharges, make it very difficult to design a reliable and compliant card reader that drives the card at more than 4 MHz). Cards have to be started with a clock frequency (at 5V Vcc) in the range 1 Mhz to 5Mhz, and they start with a clock to I/O bit rate ratio of 372, so 3.5712 Mhz (gives 9600 bps on I/O) or something close to that is typical. What I was showing is that a card that can only be run at up to 5 MHz will, at 3.5712 MHz clock, expect the terminal to grant it a default wwt of 1 sec. But a card that can be run at up to 8 MHz (and whose developer wishes to announce that to the terminal, in case the terminal can switch up to a higher speed) is very likely to issue an ATR that results in the terminal giving it, at 3.5712 MHz, an I/O bit rate of 9600 but a wwt of 2 seconds. If we assume that that card is identical to the other one in all respects except for being rated to run at up to 8 MHz instead of up to 5 MHz, then both cards will execute applications at exactly the same rate when run at the same clock frequency, and therefore both will need the same wwt. This points out an absurdity in 7816-3, but also shows that, when calculating the value of WI to send from the card if you want to change the wwt, you must be careful to use the correct parameters in the equation (if the card sends a value for FI in the ATR, you must use that value in the calculation). > > So, must I assume that if the clock rate doesn't > change I must not change the wwt from the standard 1s > value ? No, you choose the wwt value (choose a WI value to send from the card) to give you a long enough wwt to be sure that the card has time to execute the longest path through the code between responses from the card (remember that you can send a procedure byte from the card to reset the wwt timer in the terminal, and sometimes that is a practical solution (e.g. send a NULL), but at other times you may find you have a card whose ROM code will not let you do that). > > Does this apply to T=1 timeout values, BWT and CWT? > BWT and CWT have their own formulae in section 9.5.3 of 7816-3:1997, and their own parameters in the ATR. BWT's formula is very odd: BWT = 11 etu + 2**BWI * 960 * (372/f) sec but CWT depends directly on F/D as well as f: CWT = (11 + 2**CWI) * (F/D) * (1/f) BWI and CWI are upper and lower nibbles from the TB interface byte after the first occurrence of a T=1 value in a TD(2) or later TD byte. wwt extension in T=1 is handled by an S-block request from the card. Who dreamt this up? Mainly the French for T=0 and the Germans for T=1. Vive le Common Market! Peter T Bristol UK *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Work Waiting Time question
Hi, Thanks Peter for your great explanation. > 7816-3:1997 section 8.2 on work waiting time: > > wwt = 960 * WI * (Fi / f) > This is exactly what I get doning variable substitution and symplification in the formula that comes in ISO 7816-3: 1992. [snip] > It seems, therefore, that changing the value of Di > in the ATR does not > change the value of the wwt, but changing the value > of Fi does. Is this what > the writers of 7816-3:1997 meant? I don't think so, > because the wwt required > is related to the values of clock sent to the card, > the internal structure > of the card's CPU and clock processing circuits, and > the application > algorithm programmed into the card. Changing Fi and > Di doesn't change the > way that the card runs its application code, and so > should not change the > wwt - but changing Fi does change the wwt. > > FI from the card, besides influencing I/O bit rate, > also indicates the max > clock frequency that the card can be run at. So: > > FI = 0 (means Fi = 372), Di = 1 gives a bit rate of > 9600 in our example, a > wwt of 1 sec, and indicates (Table 7) a max clock > frequency of 4 MHz > (typical for a card run at 3 Volts Vcc) > > FI = 1 (also means Fi = 372), Di = 1 gives a bit > rate of 9600 in our > example, a wwt of 1 sec, and indicates (Table 7) a > max clock frequency of 5 > MHz (typical for a low cost card run at 5 Volts Vcc) > > FI = 3 (means Fi = 744), Di = 2 also gives a bit > rate of 9600 in our > example, but changes the wwt to 2 sec, and indicates > (Table 7) a max clock > frequency of 8 MHz (e.g. for a Hitachi 3109 card as > used by "rollout spec" > Mondex in a single application environment) > But the reader that I'm ussing provides 3.5712 MHz constant clock rate to the smartcard regardless of the ATR in the card. So, must I assume that if the clock rate doesn't change I must not change the wwt from the standard 1s value ? Does this apply to T=1 timeout values, BWT and CWT? Thanks, Carlos. __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Work Waiting Time question
Carlos, Use the current (1997) edition of 7816-3, not the obsolete (1989) edition. Its still not easy to do the calculations, so readers of this note should check it over carefully. 7816-3:1997 section 8.2 on work waiting time: wwt = 960 * WI * (Fi / f) f = card clock frequency - let us assume 3571200 Hz (3.5712 MHz) Fi is the clock rate conversion factor. It is coded as FI in the top 4 bits of ATR interface byte TA(1), and Table 7 is used to find the value of Fi. If TA(1) is not present, the default value of Fi is 372 (see below about this muddle). WI is coded in ATR specific interface byte TC(2); the default value if TC(2) is not sent by the card is 10 Using default values and the assumed card clock frequency of 3571200, we have: wwt = 960 * 10 * (372 / 3571200) = 1 second For the calculation of the etu (elementary time unit, or bit period on the I/O line), another factor comes in. 7816-3:1997 section 6.5.2: 1 etu = (F / D) * (1 / f) First, one of 7816-3's muddles must be cleared out of the way: if interface byte TA(1) is present, F = Fi as found via Table 7 (see above); if TA(1) is not present, F = Fd = 372; but if a successful PPS exchange in which the interface device sends PPS1 to request the card to accept values of F and D takes place, F = Fn as sent back by the card. (PPS is the new name for PTS) D is the extra factor: the I/O line bit rate adjustment factor (e.g. changing D from the default 1 to the value 2 halves the length of the etu, or doubles the bit rate). The same muddle as for F applies: first, it is coded as DI in the bottom 4 bits of ATR interface byte TA(1), and Table 8 is used to find the value of Di; if TA(1) is not present, the default value of Di is Dd = 1; and a PPS exchange can change D just as it can change F. So, using default values and a clock rate of 3.5712 MHz: 1 etu = (372 / 1) * (1 / 3571200) = 1.04167 sec (104.167 microsec or, of course, 1/9600 sec) It seems, therefore, that changing the value of Di in the ATR does not change the value of the wwt, but changing the value of Fi does. Is this what the writers of 7816-3:1997 meant? I don't think so, because the wwt required is related to the values of clock sent to the card, the internal structure of the card's CPU and clock processing circuits, and the application algorithm programmed into the card. Changing Fi and Di doesn't change the way that the card runs its application code, and so should not change the wwt - but changing Fi does change the wwt. FI from the card, besides influencing I/O bit rate, also indicates the max clock frequency that the card can be run at. So: FI = 0 (means Fi = 372), Di = 1 gives a bit rate of 9600 in our example, a wwt of 1 sec, and indicates (Table 7) a max clock frequency of 4 MHz (typical for a card run at 3 Volts Vcc) FI = 1 (also means Fi = 372), Di = 1 gives a bit rate of 9600 in our example, a wwt of 1 sec, and indicates (Table 7) a max clock frequency of 5 MHz (typical for a low cost card run at 5 Volts Vcc) FI = 3 (means Fi = 744), Di = 2 also gives a bit rate of 9600 in our example, but changes the wwt to 2 sec, and indicates (Table 7) a max clock frequency of 8 MHz (e.g. for a Hitachi 3109 card as used by "rollout spec" Mondex in a single application environment) Regards, Peter Tomlinson 34 Strathmore Road, Horfield, Bristol BS7 9QJ, UK phone & fax +44 (0)117 951 4755, mobile +44 (0)7968 947021 email [EMAIL PROTECTED] , web www.iosis.co.uk - Original Message - From: "Carlos Prados" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, June 02, 2001 6:39 PM Subject: MUSCLE Work Waiting Time question > Hi, > > I need some advice to interpretate the ISO 7816-3 > normative: ISO 7816-3 states that the Work Waiting > Time for T=0 is calculated as follows: > > wwt = 960 * D * WI * work etu. > > I use this value as timeout for receiving chars from > the card. > > I'm not sure how to calculate this value when etu = > 1/9600 s (default value when there is no PTS): > > a) work etu = (1/D) * (F/fs) where fs=3571200 > > So wwt is equals to: > > wwt = 960 * WI * F / 3571200 > > For a cyberflex this gives 1376 ms and for cryptoflex > 3200 ms. > > b) Use the actual work etu (1/9600 seconds): > > wwt = 960 * D * WI * (1/9600) > > For cyberflex this gives 8000 ms and for cryptoflex > 3200 ms. > > Any advice is welcomed. > > Thanks, > Carlos. > > > __ > Do You Yahoo!? > Get personalized email addresses from Yahoo! Mail - only $35 > a year! http://personal.mail.yahoo.com/ > *** > Linux Smart Card Developers - M.U.S.C.L.E. > (Movement for the Use of Smart Cards in a Linux Environment) > http://www.linuxnet.com/smartcard/index.html > *** > *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Env
Re: MUSCLE Work Waiting Time question
I'm not sure how to calculate this value when etu = 1/9600 s (default value when there is no PTS): My interpretation of 7816-3 is that it should be a) wwt = 960 * WI * F / 3571200 But I could be wrong. In particular, Cyberflex almost always requires a longer wwt, and I usually set my own atr to increase it to about 5 seconds. So maybe it should be b) ? I will go re-read 7816-3 and see if I can make better sense of it. *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
