RS 232 breakout tap ?

[Boxnut]

Hi people. I have a device using RS-232 and want to tap into the TX and RX lines. I have a direct tap now, but is often problematic with the device in test. I am guessing the device lacks the fanout to properly drive a second RS-232 port.
I am thinking a bus transceiver may work to resolve this. I am so rusty with my digital design I am really lost and can use some help.
>Some specifics: The host computer sends data to the device then the device responds with data to the host.
What I need to do here is read and log the data both ways. Hanshaking is RTS-CTS.
Any help/suggestions would be hot, maybe some diagrams.
What about a bus driver IC instead of tranceiver ??
Thanks in advance.

 

[Pommie]

Sounds like you need an RS232 logger.

Mike.

 

[rjenkinsgb]

You could use a CMOS IC such as a 4093 or 40106, with eg. a 100K series resistor at the input and schottky diode clamps to protect the inputs from excess voltage.

The loading at that should have no effect at all.

However, any device using RS232 compliant interfaces should not really have a problem driving a second receiver - that implies something may not correct elsewhere?
Possibly a ground offset, weak driver or over-long cable? Or a signal conflict with an output connected to something from the monitoring device?

Do you have an oscilloscope to see what the data waveform looks like?

A lot of basic RS232 test devices just drive LEDs from the RS232 signals without any buffering & I've never seen that have any adverse effect on commercial equipment.

 

[Boxnut]

Sounds like you need an RS232 logger.

Mike.

I have that, my issue is in hardware.
Thanks.

 

[Boxnut]

You could use a CMOS IC such as a 4093 or 40106, with eg. a 100K series resistor at the input and schottky diode clamps to protect the inputs from excess voltage.

The loading at that should have no effect at all.

However, any device using RS232 compliant interfaces should not really have a problem driving a second receiver - that implies something may not correct elsewhere?
Possibly a ground offset, weak driver or over-long cable? Or a signal conflict with an output connected to something from the monitoring device?

Do you have an oscilloscope to see what the data waveform looks like?

A lot of basic RS232 test devices just drive LEDs from the RS232 signals without any buffering & I've never seen that have any adverse effect on commercial equipment.

This issue is not consistent, I have several devices, some work with the direct "Y" cable, some don't.
The devices are programmable radios. Ones that fail error with no hanshaking or radio not in program mode. No data is recorded. Because some work, the problem is with the radios, most likely not having enough drive for both RS-232 ports.
This has to work with everything to get my needed results. The data rate is fixed at 9600 bps so I can't slow it down.
Cables are 3 foot on each side of the breakout and quality cables.

 

[rjenkinsgb]

OK, I think the CMOS buffer option is likely best then.

A CD4049 would probably be a good choice, having considered it a bit more - they have input protection so just a 100K series resistor should be fine, and it will also give the inversion back to UART or MCU compatible polarity.

If you want to feed another RS232 level port, then a CD4050 should work the same for the resistor input side and drive most com port inputs as well, as they usually have a slight positive offset & will mostly take 0V as "negative" signal level.

 

[Boxnut]

OK, I think the CMOS buffer option is likely best then.

A CD4049 would probably be a good choice, having considered it a bit more - they have input protection so just a 100K series resistor should be fine, and it will also give the inversion back to UART or MCU compatible polarity.

If you want to feed another RS232 level port, then a CD4050 should work the same for the resistor input side and drive most com port inputs as well, as they usually have a slight positive offset & will mostly take 0V as "negative" signal level.

Let me dig up the spec sheets for these, I think you may be on the right track here. What I am wanting is the host to talk to the radios normally while 'transparently' logging the data to and from.
Thanks.