RS232 smart switch design

I am going to design a smart RS232 switch.
the board should have one RS232 input and two RS232 outputs.
the output port should be switchable manually and also automatically in a way that gives priority to one of the outputs.
whenever the high priority port is connected, the other one should be disconnected.

I would appreciate your comments on the best and most reliable way to design such a board?

Best regards

How would you like to automate control of the connection? DTR/DSR? RTS/CTS? Xon/Xoff? Tx or Rx data activity?

In the old days during the 70's when RS-232 was most common, I would simply use diode OR logic so I could receive from either computer and display both on a monitor. But this may be confusing for your application.

RS-232 logic is bipolar but the threshold is unipolar set around 2 diode drops or +1.2 to +1.4 just like TTL. negative bias can be applied via an unused control signal if avail with a ~5k resistor to improve noise margin.

UART idle or stop bit is a "1" for CMOS/TTL which is inverted to RS-232 interface or idle = -V ( which can be -3 to -15 typ) and a start bit is a "0" or V+ ( +3 to +15V)

1st decide on flow control HW or SW then decide if your device supports it then choose the logic to switch and indicate active connection.

At one time in early 80's I designed the concept for multiplexing 1024x RS-232 terminals via a high speed serial synchronous channel. (Split PACX)

I am not sure which one is preferred and is a more reliable way. I was thinking of controlling the signal level of DTR.

SunnySkyguy said:

In the old days during the 70's when RS-232 was most common, I would simply use diode OR logic so I could receive from either computer and display both on a monitor. But this may be confusing for your application.

Click to expand...

I did a similar trick few decades later :wink: OR'ing the RX pins ( from peripherals ) with diodes, and their TX pins were connected in parallel. Once it was the same application which performed the scheduling of the transmission packs, and reception occurred just upon request, such sharing did not mean a problem at all, however hardware flow control pins were not used. Of course, at receiver side, the frame control of each module took charge of reject commands not belonged to it.