Setting up to investigate the failure to communicate by cardread.exe to interfaces

 SERIAL PROTOCOLS AND CONTROL LINES

Serial communications protocols like RS-232 were developed over time and included a number of signals that are erratically implemented. These include signals with labels such as RTS, DTR, CTS, DSR, RI, RTR and DCD in addition to the TX and RX lines that carry the outbound and inbound data. Even the voltage levels are subject to some variation, with the original standard involving positive and negative voltages of up to 15V but often with computers today TTL levels of 0 and +5V are used. 

The meanings of the signals were originally defined around connections between a modem and a device, the DCE and DTE respectively in the jargon of the standard. Thus, DCD meant that the carrier signal on the phone line was detected and RI meant that a ring was incoming on the line. With fixed wiring between the two sides of a serial link and no modems involved, these have much less meaning.

Flow control can be implemented using the lines, but again the way this occurs varies. One can imagine the use of RTS (Ready to Send) and CTS (Clear to Send) but even that has evolved so that RTS is relabeled RTR (Ready to Receive) and thus each signal indicates that data can be sent on its associated RX or TX line. Other flow control schemes include using characters like XON/XOFF sent inband rather than using the control signals.

Control lines such as DTR and DSR indicate that the two sides of the link are ready. In some implementations, the link won't operate unless it sees these positively asserted. Many other implementations ignore these lines. 

Thus, making a serial link work is more involved than just hooking up TX and RX, then setting the baud rate, bits, parity and stop bit configurations. One has to know whether lines like DTR, DSR, CTS and RTS are required and how they must operate. 

CODE IN THE CARDREAD.EXE APP USES DTR AND RTS

Investigating the source code for the application written by Brian Knittel to control the Documation card reader shows that he opens the serial link at 115200 baud, 8-N-1 settings but also that he is specifying that DTR and RTS are to be used for link enable and flow control. 

The big question to resolve is how this is handled by Windows in its com ports, in the USB driver, and again on the remote end inside the Arduino as it is converted back to RS232 signaling. It is possible that some settings are causing the application to block or to not receive the responses from the interface. 

SERIAL COMMS MONITORING TOOL INSTALLED

In order to see exactly what the application is seeing in its requests to Windows for communication with my interface module, I downloaded a tool that installs a filter in front of each COM port on Windows, allowing it to capture every request and data transfer. 

It will let me see whether the windows to CARDREAD.EXE traffic shows the transmission of the character 'r' to the interface and the receipt of the response '@' which indicates that our interface has successfully reset. That will guide me further in diagnosing the failure to communicate which is blocking my use of the existing application to control my card readers.