I want to run a handful of RS232 bit synchronous signals between two places (So data and clock lines). Is it okay to run a load of these in a single multicore cable or do I need to run them in individual cables?

Not much guidance out there on this. But space at a premium

 

I want to run a handful of RS232 bit synchronous signals between two places (So data and clock lines). Is it okay to run a load of these in a single multicore cable or do I need to run them in individual cables?

Not much guidance out there on this. But space at a premium

Can you explain the application a little more? How far apart are the devices?

 

When you say "RS-232" do you really mean RS-232 signal levels? What sort of bit rate? What do you intend to use for drivers and receivers?

 

When you say "RS-232" do you really mean RS-232 signal levels? What sort of bit rate? What do you intend to use for drivers and receivers?

Around +/- 10V over the lines, running around 19.2kbps. Driving and receiving with some COTS equipment that can accept these levels

 

Can you explain the application a little more? How far apart are the devices?

The cable length will be about 10m - I've got around 15 channels to transmit between the two points (so around 30 data + clock lines and 15 signal grounds)

 

RS-232 defines the voltage levels, rise and fall times, impedance, etc.
You are likely to suffer from cross-talk between data and clock signals.

You can reduce cross-talk and signal degradation by:

1) using lower voltage such as RS-422 or RS-485
2) use differential signalling on twisted pair cable
3) eliminate the clock signal
4) terminate the cables properly

 

I want to run a handful of RS232 bit synchronous signals between two places (So data and clock lines). Is it okay to run a load of these in a single multicore cable or do I need to run them in individual cables?

Not much guidance out there on this. But space at a premium

I don't know what you mean by "synchronous" since the RS232 serial protocol standard is asynchronous. But you say you want to transmit data at 19.2 kps over ten meters, one data and one clock line.

In my experience, I'd say yes, it can be done. But on more recent years I've decided that on distances larger than 6 meters, it's much better to use a differential signal (like RS485, or RS422) instead, since it's far more robust and reliable than the single-line ±12VDC RS232, especially at high speeds.

When I have to do that, I build a simple circuit that converts RS232 to RS485 on one end, and another one converting RS485 back to RS232 on the other end.

 

Given the relatively low slew rate of RS-232, which reduces capacitively coupled crosstalk, the large swing beyond the threshold voltages you are expecting, the large "deadband" between logic levels if proper receivers are used and the comparatively short run, I think, but cannot say with certainty, that it will work OK. Clock timing jitter that might result from some crosstalk shouldn't be a problem with such a low bit rate, assuming the active edge of the clock is somewhere around the middle of the bit position. As long as you don't get spurious transitions on the clocks, it should be OK (which you obviously already know).

In my opinion there is little point in trying to terminate the lines. For one thing, if they are just individual conductors, the notion of constant impedance is just not applicable. Even with RS-422 and 485, termination often isn't needed for short runs.

If your cable has unused conductors and you can do it, I would recommend connecting them all to ground. It will raise the capacitance, which shouldn't be an issue at such a low rate, but it will also provide a small measure of shielding. If the conductor lay is consistent from one end of the cable to the other (which is usually the case), I'd also recommend trying to put a ground conductor adjacent to each clock conductor. If I were testing, I'd do the opposite - try to arrange a situation where multiple clock lines were in close proximity and drive all of them synchronously except one which would be 'scoped.

I've never actually seen RS-232 used for sync serial, though of course it is provided for in the ancient spec.

422 is certainly theoretically superior for this sort of thing, but I'm guessing you already know that and don't have the option without adding conversion boxes.

 

I don't know what you mean by "synchronous" since the RS232 serial protocol standard is asynchronous. But you say you want to transmit data at 19.2 kps over ten meters, one data and one clock line.

In my experience, I'd say yes, it can be done. But on more recent years I've decided that on distances larger than 6 meters, it's much better to use a differential signal (like RS485, or RS422) instead, since it's far more robust and reliable than the single-line ±12VDC RS232, especially at high speeds.

When I have to do that, I build a simple circuit that converts RS232 to RS485 on one end, and another one converting RS485 back to RS232 on the other end.

I am pretty certain I have taken RS232 to 10 meters or more but as I recall it was only 1200 baud. at most it was 9600 baud. Just going to a printer so there was no reason for a high transfer rate. Give you an idea of how many years ago that was so my memory is a little fuzzy.

 

We once did crazy things like run X.25 networks with EIA/TIA-232 at the physical layer interface. You can push the signal at 19.2kbps for some distance with quality shielded cables and ground loop isolated hardware.

https://www.farsite.com/X.25/X.25_info/X.25_Physical_Layer.htm

 

For one thing, if they are just individual conductors, the notion of constant impedance is just not applicable.

I'm not sure I understand what you've just said. But termination resistors in differential transmission lines are there to absorb reflections in the lines, and not to provide a constant impedance.

Even with RS-422 and 485, termination often isn't needed for short runs.

Yes, that is true. 10 meters is not a long distance (relative to a 485 standard) and the use of those resistors would most likely be pointless.

 

I'm not sure I understand what you've just said. But termination resistors in differential transmission lines are there to absorb reflections in the lines, and not to provide a constant impedance..

My point is that wires simply bundled together in a cable, as opposed to coaxial cables for single-ended signals or twisted pairs for differential signals, will not have constant, well-defined impedance, and therefore there is little point in attempting to terminate them as you would for a transmission line that does have well-defined impedance. Signals in individual conductors like that are going to be "smeared' and full of reflections according to how they happen to lie next to other conductors with similarly unknown events going on. RS-232 has desirable properties for transmission on such cables. RS-422 would suffer much worse relative degradation.

[EDIT] - had to look up the original words - and then mangle them.
And what rough bit, its hour come round at last, Slouches towards receiver to be heard
There will be no Second Coming.
With many apologies to William Butler Yeats.

In the case described, I think crosstalk that might impair the clocks is more likely to be an issue than reflections.

 

My point is that wires simply bundled together in a cable, as opposed to coaxial cables for single-ended signals or twisted pairs for differential signals, will not have constant, well-defined impedance, and therefore there is little point in attempting to terminate them as you would for a transmission line that does have well-defined impedance. Signals in individual conductors like that are going to be "smeared' and full of reflections according to how they happen to lie next to other conductors with similarly unknown events going on. RS-232 has desirable properties for transmission on such cables. RS-422 would suffer much worse relative degradation.

[EDIT] - had to look up the original words - and then mangle them.
And what rough bit, its hour come round at last, Slouches towards receiver to be heard
There will be no Second Coming.
With many apologies to William Butler Yeats.

In the case described, I think crosstalk that might impair the clocks is more likely to be an issue than reflections.

Very interesting... I'm surprised that @MaxHeadRoom hasn't chimed in... this sort of thing is right up his alley

 

RS-232 defines the voltage levels, rise and fall times, impedance, etc.
You are likely to suffer from cross-talk between data and clock signals.

You can reduce cross-talk and signal degradation by:

1) using lower voltage such as RS-422 or RS-485
2) use differential signalling on twisted pair cable
3) eliminate the clock signal
4) terminate the cables properly

I'd like to use 422/485 but in this application, I don't have a choice. And it is the synchronous form, so I have to have a clock signal

 

Given the relatively low slew rate of RS-232, which reduces capacitively coupled crosstalk, the large swing beyond the threshold voltages you are expecting, the large "deadband" between logic levels if proper receivers are used and the comparatively short run, I think, but cannot say with certainty, that it will work OK. Clock timing jitter that might result from some crosstalk shouldn't be a problem with such a low bit rate, assuming the active edge of the clock is somewhere around the middle of the bit position. As long as you don't get spurious transitions on the clocks, it should be OK (which you obviously already know).

In my opinion there is little point in trying to terminate the lines. For one thing, if they are just individual conductors, the notion of constant impedance is just not applicable. Even with RS-422 and 485, termination often isn't needed for short runs.

If your cable has unused conductors and you can do it, I would recommend connecting them all to ground. It will raise the capacitance, which shouldn't be an issue at such a low rate, but it will also provide a small measure of shielding. If the conductor lay is consistent from one end of the cable to the other (which is usually the case), I'd also recommend trying to put a ground conductor adjacent to each clock conductor. If I were testing, I'd do the opposite - try to arrange a situation where multiple clock lines were in close proximity and drive all of them synchronously except one which would be 'scoped.

I've never actually seen RS-232 used for sync serial, though of course it is provided for in the ancient spec.

422 is certainly theoretically superior for this sort of thing, but I'm guessing you already know that and don't have the option without adding conversion boxes.

Indeed, I would like 422 but it isn't an option for me. Looking at all the responses, I'm not sure I've made myself too clear - I just wondered if in the physical cabling I could run all 15 channels in a single multicore cable or if I'd need to run 15 individual cables or somewhere in between (no-one likes running loads of cables!)

 

Indeed, I would like 422 but it isn't an option for me. Looking at all the responses, I'm not sure I've made myself too clear - I just wondered if in the physical cabling I could run all 15 channels in a single multicore cable or if I'd need to run 15 individual cables or somewhere in between (no-one likes running loads of cables!)

A single shield multicore cable should be more than enough to do what you want.

 

A single shield multicore cable should be more than enough to do what you want.

Ok - I just need to convince two other guys who say they would be really worried about crosstalk between the signals. At least this makes me a little more confident

How would I go about calculating crosstalk or other disruptive effects to try to quantify the problem or lack of it? Or is this not possible?

 

I don't know what you mean by "synchronous" since the RS232 serial protocol standard is asynchronous. But you say you want to transmit data at 19.2 kps over ten meters, one data and one clock line.

In my experience, I'd say yes, it can be done. But on more recent years I've decided that on distances larger than 6 meters, it's much better to use a differential signal (like RS485, or RS422) instead, since it's far more robust and reliable than the single-line ±12VDC RS232, especially at high speeds.

When I have to do that, I build a simple circuit that converts RS232 to RS485 on one end, and another one converting RS485 back to RS232 on the other end.

The rs232 is defining the electrical standard including the control signals and does not say anything about the type of transport async or sysc nor speed but it does define the signal functions types like dtr, rts, ring indicator and so on.
An other standard is used to describe the pin-out.

Picbuster

 

The rs232 is defining the electrical standard including the control signals and does not say anything about the type of transport async or sysc nor speed but it does define the signal functions types like dtr, rts, ring indicator and so on.
An other standard is used to describe the pin-out.

Picbuster

You're right, RS232 is an electronic standard. It's just that it's been traditionally associated with the UART protocol, and very seldom one hears it being used with anything else.

As for crosstalk, it's practically impossible for it to happen between a bunch of cables working at +/- 12V a few meters long. That sort of behavior is more common when trying to transmit TTL signals for more than 2m, which is not this case.

 

Belden has several products for data transmission, for e.g. they have 25 & 37 conductor low capacitance computer cable intended for RS232 RS485 etc ' low dielectric high speed low distortion data handling'.
The 9925/9938 series.
Also Individual shielded pairs 36 conductors.
Max.