Its not a hex command, but an RS232 line state change
Set the line states to a know point
- Clr RTS
- Clr DTR
If its a pheonix reader
- Set RTS
- Clr RTS
if smart mouse
- Clr RTS
- Set RTS
Hi guys,
Very noob question but here it goes :
In every program out there, theres a button to get a cards ATR.
Question is , what is this command in HEX ? Or does something else need to be done to trigger a card reset.
Thanks.
Look Here -> |
Its not a hex command, but an RS232 line state change
Set the line states to a know point
- Clr RTS
- Clr DTR
If its a pheonix reader
- Set RTS
- Clr RTS
if smart mouse
- Clr RTS
- Set RTS
thanks crypto...
would you know how to create a function to do this in a language such as java or c#
thanks.
You need to refer to the documentation for the serial port library or API you're using.
Most card tools are written in Delphi, VB6 or C++Builder. To communicate with the serial port they use either for serial port or a wrapper component (VCL or ActiveX). The serial components just make Win32 API calls under the hood. There's a bit to learn but as APIs go it's old and stable with plenty of documentation available. The Win32 API functions in turn call the serial port driver which manipulates the UART register bits that control the handshaking lines.
Here are a few brief pointers.
- Hosting your card in a phoenix, you reset the card using RTS (as crypto7 indicated above). In SmartMouse mode you still use RTS but the polarity is other way around. Card presence is found by reading RS232 CD aka 'carrier detect' line (Microsoft sometimes call it RLSD for 'receive line signal detect').
- Talking to a receiver via season, you request notification of CAM's reset signal via the RS232 CD (aka RLSD) line. You won't necessarily receive notification of this event automatically; depending on what library you're using you'll probably need to ask for the notification.
- You don't want to be notified of all events on the serial port, just the one or two of relevance. Enabling too many events can cause instability on slower systems because of overhead of servicing spurious interrupts.
- In all cases the communication is asynchronous, so it's your responsibility to ensure bit rate matches the CAM or Phoenix clock. If incorrect you'll get framing errors.
- Be prepared to play with stop and parity bits; some receivers have different requirements.
- As described in the ISO7816 specification, responses are time sensitive. If your messages are too late timeout may occur.
- Serial port modes exist which switch RTS and DTR automatically for flow control. You should programmatically disable those modes otherwise you may not be able to control them manually.
thanks alot gw1
will take it from there - cheers
Bookmarks