RS232 Bridge cable stopping after some time

Question

Im trying to reverse engineer a very old DOS program that connects with a machine using RS232, for this i setup a typical in the middle connection like this:

From Computer A to PC A connection im using a standard RS232 crossover cable with this configuration:

And feeding both lines to my PC using Serial to USB converters, for monitoring the software i'm using Device Monitoring Studio and setting it to bridge all communications between PCA and PCB

It apparently works fine but after some time the communication breaks, I have double checked the connections, the transfer options (It seems to be 9600 8N1) and redo the cable, if i try other transfer options like changing the speed or the handshake or the start / stop bits the communication wont even start

Any ideas on why the communication is suddenly stopping? what else can you suggest to monitor the communication on a Windows 7 x64 machine (or maybe linux)?

Regards...

Answer 1

I would probably have a direct connection between A and B, rather than depending on the PC to pass data between the two devices.

The two serial ports on the PC could then simply monitor the traffic - one port watching A->B, the other watching B->A. This way you could be fairly certain that the PC is not causing the communications failure.

Answer 2

Any ideas on why the communication is suddenly stopping?

There's a couple of possibilities that come to mind:

1. As mentioned by Maple in a comment on the question, one or both of the devices might be communicating at a slightly higher baud rate than your RS232/USB converters. A slight difference -- say, 9601 baud -- wouldn't prevent your computer from receiving the content, but would cause input to arrive slightly faster than the USB adapter was able to transmit it back out. Given a continuous transmission and enough time, the USB device's transmit buffer will overflow, causing synchronization to be lost.

2. The devices may be making use of RS232 control lines (RTS/CTS, DSR/DCD/DTR, etc) in a way that your computer is not correctly mirroring to the other device.

   For that matter, they might even be using the control lines in a completely nonstandard fashion. (They could be using one of the control lines as a digital I/O, for example.)

3. The devices may be switching communication modes (e.g, baud rate, parity, or bit count). This would be difficult to handle without knowledge of the protocol.

   As before, they might even be switching to a non-RS232 protocol partway through. This would be surprising, but not impossible.

As suggested by Peter Bennett, you will probably have better luck passively sniffing communications, rather than trying to act as a "man in the middle".