That web page show a very crude monitoring device, and does not tell you the
whole story.

In most cases, there is no problem using a card extender: PCB the same
thickness as a card, card shape at one end, with gold contacts just like a
real card, but extended at the other end (end furthest away from the "stamp"
or contacts) to incorporate a card coupler into which the real card is
inserted, plus any other circuitry required (the one that I have here at the
moment, being used to check out some card test equipment, merely has a
monitoring connector and some test points on it, but no RS232 level
converter).

The information that doesn't seem to be there on the web site is that the
card's I/O bit rate is related to the clock applied to the card. The card
reader provides the clock frequency, and you have to work out whether it
corresponds to a standard bit rate on the terminal equipment used for
monitoring. Many reader manufacturers use a 3.5712 MHz clock (or something
very close), which gives 9600 bps on the I/O line at card startup and most
of the time continuing during card operation (and the reason why they use
3.5712 MHz is often because that allows them to use a standard terminal or
PC to monitor activity on the I/O line during development of the reader...).
If you don't have a card clock that gives a standard bit rate, you need
bit-banging software in the monitoring equipment in order to read the
data...

A good monitoring circuit will monitor the card reset signal as well as the
I/O - again, level convert, and then wire across to RS232 CTS or DSR
(depends on the monitoring equipment). Then you avoid reading a continuous
Break when the card is off (no Vcc), or spurious signals while the card is
being turned on or off.

Of course, you cannot tell in which direction the information is flowing
along the I/O line, except by decoding the commands and responses... But I
decode ATRs by hand, sometimes off a storage scope monitoring the I/O line
(and don't always get them right).

And you need software to pick up the ATR, decode it, and then make a
decision on what to do to understand the data (e.g. normal/inverted data).
But most of the time you can pick up the data on a UART (e.g. COM port).

I haven't got any extenders left (we closed the business down because there
was no longer any demand for the various things like this that we made). I
do have some dummy card PCBs - they bring the card contacts out to a
connector, so it would not be difficult to wire to a card coupler (use short
wires) and also take the signals off to the level shifter (but it does get
to look a bit crude again).

Peter T
pwtiosis.co.uk

----- Original Message -----
From: "Alexandre Dulaunoy" <adulau-scconostix.com>
To: <sclinuxlinuxnet.com>
Sent: Monday, August 20, 2001 9:47 PM
Subject: MUSCLE Perl API for pcsc-lite

> Dear all,
>
> Is there any Perl API (via XS) to access pcsc-lite ? Or is it an ongoing
> project ?
>
> Another question : (maybe out of topic) We have seen the snooping tools
> for debugging communication over the wire.
> http://www.citi.umich.edu/projects/smartcard/smartcard-testbed.html
> Is there any PCB available for that and software for that ?
>
>
> Thanks
>
> alx
>
>
> --
> ---
> Alexandre Dulaunoy
> Work : http://www.conostix.com/ adulauconostix.com
> Private : http://www.thinkingsecure.com/ adulauthinkingsecure.com
>
> "Liberty is the great parent of science and of virtue; and a nation will
> be great in both in proportion as it is free. " T. Jefferson
>
>
>
> ***************************************************************
> Unix Smart Card Developers - M.U.S.C.L.E.
> (Movement for the Use of Smart Cards in a Linux Environment)
> http://www.linuxnet.com/
> To unsubscribe send an email to majordomolinuxnet.com with
> unsubscribe sclinux
> ***************************************************************
>

***************************************************************
Unix Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/
To unsubscribe send an email to majordomolinuxnet.com with
unsubscribe sclinux
***************************************************************

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