On Tue, Jun 22, 2010 at 10:47 AM, Ludovic Rousseau
<[email protected]> wrote:

>> Parsing ATR: 3B 9D 94 80 1F C7 80 31 E0 65 D0 00 2B E6 08 73 FE 21 13 CF
>>
>> TS = 0x3B        Direct Convention
>> T0 = 0x9D        Y(1): b1001, K: 13 (historical bytes)
>> TA(1) = 0x94        Fi=512, Di=8, 64 cycles/ETU (62500 bits/s at 4.00
>> MHz, 78125 bits/s for fMax=5 MHz)
>> TD(1) = 0x80        Y(i+1) = b1000, Protocol T=0
>> ----
>> TD(2) = 0x1F        Y(i+1) = b0001, Protocol T=15
>> ----
>> TA(3) = 0xC7        Clock stop: no preference - Class accepted by the
>> card: (3G) A 5V B 3V C 1.8V
>> ----
>> Historical bytes        80 31 E0 65 D0 00 2B E6 08 73 FE 21 13
>> Category indicator byte: 0x80
>>  (compact TLV data object)
>>    Tag: 3, Len: 1 (card service data byte)
>>      Card service data byte: 224
>>        - Application selection: by full DF name
>>        - Application selection: by partial DF name
>>        - BER-TLV data objects available in EF.DIR
>>        - EF.DIR and EF.ATR access services: by GET RECORD(s) command
>>        - Card with MF
>>    Tag: 6, Len: 5 (pre-issuing data)
>>      Data: D0 00 2B E6 08
>>    Tag: 7, Len: 3 (card capabilities)
>>      Selection methods: 254
>>        - Record number supported
>>        - Short EF identifier supported
>>        - Implicit DF selection
>>        - DF selection by file identifier
>>        - DF selection by path
>>        - DF selection by partial DF name
>>        - DF selection by full DF name
>>      Data coding byte: 33
>>        - Behaviour of write functions: proprietary
>>        - Value 'FF' for the first byte of BER-TLV tag fields: valid
>>        - Data unit in quartets: 1
>>      Command chaining, length fields and logical channels: 19
>>        - Logical channel number assignment: by the card
>>        - Maximum number of logical channels: 3
>> TCK = 0xCF        (correct checksum)
>> Possibly identified card: UNKNOWN
>>
>>
>> Correct checksum in the end gives me a little bit confidence that this
>> ATR is possibly the real one and well received.
>>
>> However, T=15 protocol is something that confuses me. Do you have any
>> idea why it is used, as I have seen so far that only T=0 and T=1 are
>> used, and the rest is reserved for future uses.
>> Could this rather be an error in ATR reception ?
>
> T=15 is not a communication protocol. Just ignore this part of the ATR.

Hi Ludovic,
I would like to kindly ask you for a few clarifications on this :
1) Which protocol is used then for communication with this card
(looking at presented ATR) ? T=0 ?
2) If I got it well, you suggest ignoring bit TD(2), and processing
all other (i.e. taking configuration parameters from them, configuring
controller, and acting like we use T=0 protocol) ?
3) For my curiosity, do you have any idea why is this T=15 appearing ?
4) Should we always quietly ignore any other TDi character apart from
one that gives us T=0 or T=1 ?
5) Having all this in mind, can I conclude at this moment that this
ATR is correct ?

Best regards,
Drasko

_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle

Reply via email to