Hi, Eric ...

UICC (ETSI TS 102.221) supports PPS after any warm reset. It's useful
to be able to change communication profiles as you change applications.

Cheers, Scott

-----Original Message-----
From: Eric Perlin [mailto:ericperlMICROSOFT.COM]
Sent: Thursday, August 02, 2001 6:34 PM
To: SmartCardSDKDISCUSS.MICROSOFT.COM
Subject: Re: Baud Rate Negotiation in PC/SC

One more thing. I believe PPS will only occur before the first command.

-----Original Message-----
From: Au, Arthur [mailto:Arthur.AuSCIATL.COM]
Sent: Thursday, August 02, 2001 1:36 PM
To: SmartCardSDKDISCUSS.MICROSOFT.COM
Subject: Re: Baud Rate Negotiation in PC/SC

We still have problems having the resource manager, driver, reader and card
doing the PPS negotiation.

We have done captures (using a Micropross Star 1150 Analyzer) on both
Gemplus GemPC430 USB Reader and Schlumberger ReflexUSB Reader with our
inhouse-built smartcard, on a Windows 2000 Professional system. The action
that was done during the capture was just inserting our smartcard into the
reader. Please refer to the attached file "Gemplus.doc" and
"Schlumberger.doc"

The first line on the diagram is power, 2nd line is clock, 3rd line is reset
and 4th line is data.

1. Why would there be a drop of power after the reader receive the ATR from
the card ?
        ATR="3B 99 95 91 01 F1 FA 44 00 0E 00 54 00 00 00 FF 82 90 00 64"
2. Is it trying to do a "cold reset" to the card ?
3. Is it trying to push the card into "negotiable mode" ?
4. Our card come up with the 2nd ATR after the cold reset in "specific mode"
:
        ATR="3B 99 95 91 01 F1 FA 44 00 0E 00 54 00 00 00 FF 82 90 00 64"
5. It seems no PPS negotiation has ever occurred, will the reader stay at
9600 baud ?

Thanks in advance for replying.

Arthur Au

-----Original Message-----
From: Eric Perlin [ mailto:ericperlMICROSOFT.COM
<mailto:ericperlMICROSOFT.COM> ]
Sent: Wednesday, July 18, 2001 9:44 PM
To: SmartCardSDKDISCUSS.MICROSOFT.COM
Subject: Re: Baud Rate Negotiation in PC/SC

1. You don't need to do all this.
This is done automatically on the first conmmand after the card is reset
The reset occurs the first time the card is inserted and each time a
RESET is requested by an application.
2. Reattach is Reconnect. You can't specify anything. You lose control
with this COM layer.
As a result PPS will be triggered by default.
3. see above
4. You can't do that. You can force it to not do it as explained below.
5. As I said, it instructs the lower layers to not perform PPS.

-----Original Message-----
From: Au, Arthur [ mailto:Arthur.AuSCIATL.COM <mailto:Arthur.AuSCIATL.COM>
]
Sent: Wednesday, July 18, 2001 2:05 PM
To: SmartCardSDKDISCUSS.MICROSOFT.COM
Subject: Re: Baud Rate Negotiation in PC/SC

Thank you, Eric, for replying promptly. This clears up a lot about the
responsibilities.

We've been using the ISCard interface to talk to the smartcard. First,
when we use ISCard::AttachByReader() to connect to the card, and then
use
ISCard::get_Atr() to get the ATR. The smartcard come up with an ATR in
specific mode at a rate of 223.1K (Fi=9, Di=6, Clock is at 3.57MHz).

Noticed that the reader can only work at a maximum of 115K, so we use a
ISCard::ReAttach() with InitState=RESET to warm reset the card to force
it into negotiable mode. Using the ISCard::get_Atr() afterward, we
confirmed that the card is in negotiable mode.

After that, we tried to send APDU command to the card, but it returns
with error. It seems that the PPS negotiation did not occur.

Questions are:
1. Is this programming sequence correct ?
2. Will the ISCard::ReAttach() command call the
SCardConnect()/SCardReconnect()?
   How will it set the dwPreferredProtocol parameter then ?
3. Should I use the SCardReConnect() directly for this purpose ? 4. How
can we force the Resource Manager to do PPS negotiation ? 5. For the
reader, is there any way that we can know what speed does it exposes
   to the Resource Manager ?
6. Actually, we couldn't find the SCARD_PROTOCOL_DEFAULT in the possible
value
   of dwPrefferredProtocol in SCardConnect() documentation in MSDN.
What does
   it actually do ?

Thanks again.

Arthur Au

-----Original Message-----
From: Eric Perlin [ mailto:ericperlMICROSOFT.COM
<mailto:ericperlMICROSOFT.COM> ]
Sent: Wednesday, July 18, 2001 4:00 PM
To: SmartCardSDKDISCUSS.MICROSOFT.COM
Subject: Re: Baud Rate Negotiation in PC/SC

The resource manager does it.
It tries the best baud rate that both the card and the reader can
handle. The capabilities of the card are extracted from the ATR. The
reader exposes its supported speeds too. If that PPS negotiation fails,
it falls back to 9600 bauds.

The only thing an application can do is specify SCARD_PROTOCOL_DEFAULT
in the dwPreferredProtocols parameter of SCardConnect to prevent PPS
negotiation.

-----Original Message-----
From: Arthur Au [ mailto:arthur.auSCIATL.COM <mailto:arthur.auSCIATL.COM>
]
Sent: Wednesday, July 18, 2001 11:37 AM
To: SmartCardSDKDISCUSS.MICROSOFT.COM
Subject: Baud Rate Negotiation in PC/SC

Hi,

I am new to PC/SC programming. Just wondering whether anyone could tell
me how baud rate negotiation is done in PC/SC framework.

After the smartcard come up with an ATR in negotiable mode, who will
send PPS request to the card ? Is it the responsibility of the Smart
Card Reader Driver, or is it the Resource Manager ? Service Provider ?
Or the application itself has to handle that ?

Thanks in advance.

Cheers,
Arthur

<html>
<body>
<font size="3" face="Times New Roman"><span
style="mso-fareast-font-family: Times New Roman; mso-ansi-language:
EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">
- - - - - - - Appended by Scientific-Atlanta, Inc. - - - - - - - <span
style="font-size:10.0pt;font-family:Times New Roman;
mso-fareast-font-family:&quot;Times New
Roman&quot;;mso-ansi-language:EN-US;mso-fareast-language:
EN-US;mso-bidi-language:AR-SA"></span><font face="Times New Roman"
size="3"><span style="mso-fareast-font-family:Times New Roman;
mso-ansi-language: EN-US; mso-fareast-language: EN-US;
mso-bidi-language: AR-SA">This e-mail and any attachments may contain
information which is confidential, proprietary, privileged or otherwise
protected by law. The information is solely intended for the named
addressee (or a person responsible for delivering it to the addressee).
If you are not the intended recipient of this message, you are not
authorized to read, print, retain, copy or disseminate this message or
any part of it. If you have received this e-mail in error, please notify
the sender immediately by return e-mail and delete it from your
computer.</span></font></p> </body> </html>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]