I'm planning a serial port that can either work as RS485 (half duplex mode) or as RS232 (configurable by the user).

There are several UART to RS232/485 chips around (like LTC2873), where a GPIO enables to select the protocol and set the correct termination resistors.

Now the question is : should I use twisted pair or not for the cables :

  • RS232 is usually non twisted
  • RS485 is usually twisted

Cable length will be <3m, with DC power supply (3A max) running next to it.

I do not have any precise requirements for maximum baud rate, the higher being the better (with a small preference for increased baud rate for RS232 vs RS485).

So what is the better solution : twisted or untwisted cable?

Any idea what baud rate I can hope to achieve reliably for the "loosing" protocol (ie the one for which the cable type is sub-optimal)?

PS : using different cables for the 2 protocols is not an option (no pins left on connectors, connectors with more pins being to big). The only alternative would be that each connector supports only a single protocol, but I think I should be able to provide at least a very low baud rate on the wrong cable type, which is better than only one protocol.


the end of the cable with the LTC2873 is a subsea robot. On the other side can be connected various tools and sensors (some we provide and test, some owned by the clients and over which we have no control).

Subsea connectors are expensive, and quite big, theirefore the limited choice. No connector has been chosen yet (this question is part of defining the requirements for the connectors).

We don't have specific EMI requirements so far. Once underwater, I expect the water itself should make a decent shield arround the cable (not so in air).

As for adding isolation, what would you suggest to isolate? On the robot side, I'm free to put anything I want on the PCB (cost of most electronics components is negligible compared to the cost of the connectors, PCB space is more critical)

  • 3
    \$\begingroup\$ At 3m I doubt twisted pair matters much, unless you have reason to believe that the DC supply is exceptionally noisy. I don't see why you couldn't do twisted pair in RS232 though, just use Tx + Rx instead. The real question is why anyone would ever want to use RS232 when RS485 is available. \$\endgroup\$
    – Lundin
    Commented Jan 30 at 13:49
  • \$\begingroup\$ Far more importantly: what about shielding? What EMC standards/levels are applicable? e.g. conducted immunity 3V, 10V, etc.; radiated xx V/m; transients, common mode voltage, is isolation an option, etc. If environment not known, then describe the connected equipment, surroundings, and application. \$\endgroup\$ Commented Jan 30 at 13:59
  • \$\begingroup\$ @TimWilliams : I added precisions at the end of my question \$\endgroup\$
    – Sandro
    Commented Jan 30 at 14:43
  • \$\begingroup\$ Ah, thank you. What about the "environment" of the DC supply (3A and what voltage? how fast can loads switch on/off?)? \$\endgroup\$ Commented Jan 30 at 14:45
  • \$\begingroup\$ voltage will be either 24 or 48V. When switching voltage off, I don't care about the RSxxx signal anymore (the sensor/tool using it will no longer be supplied). The tool itself however might have inconsistent power consumption (for example because it contains a motor with PWM control (and insufficient capacitor), or because it works in bursts like a sonar. I didn't measured the current variations on the tools we currently have (and they would be only a small fraction of all possible tools anyway). \$\endgroup\$
    – Sandro
    Commented Jan 30 at 14:50

2 Answers 2


If any baud rate is potentially acceptable (assuming some means of programming it in, or autodetection), then simply putting enough filtering on both ends of the line, will do. Cable type is irrelevant: multi, twisted or shielded.

More particularly, for a 3m coupling length, for noise frequencies up to c0 / 10l, or 7MHz or so (note the speed of light c0 is slower in the dielectric insulating the cables), coupling predominantly manifests as lumped equivalent capacitive and inductive coupling, between the power and data lines, with the coupling factor increasing ~proportionally with frequency, up to this point (above, see the following paragraph). For a 3 or 10V signal level (typical outputs from these interfaces using modern ICs), even if the load is very badly misbehaved (10s of V of ripple/noise), if that noise is dominant at frequencies a fraction of this (say, below a MHz), the interface will likely still read correctly, even if the baud rate is comparable to the noise frequency. If the noise is dominant at higher frequencies (10s of V at >1MHz), filtering will be required, and maximum bitrate will be limited some as a result.

For noise frequencies higher than 7MHz, transmission line effects become increasingly dominant, until eventually the coupling factors turn over and the energy from a whole line can couple into another (directional coupling effects), plus resonant effects, CM/DM mode conversion, etc.. Shielding would be mandatory up here.

Old serial protocols aren't generally practical at such rates anyway (RS-232 itself is lucky to go into the 100s kbaud), so the transmission line regime likely isn't important. Frequencies that high should simply be filtered out, to avoid potential analog interface effects (such as input clamp/ESD diode or input stage rectification).

For noise amplitudes less than a fraction of the signal level (maybe 1V or so, max), both interfaces are fine, against noise of any frequency.

These are with respect to voltages measured at the cable and transceivers, in whatever suitable method could do so without disturbing the values. (Not the most trivial thing, as surrounding water will indeed disturb the measurement too, so ideally this would be measured while immersed.) There could always be resonances or transformation effects in a pathologically designed system, but assuming the source end is well-behaved (dampened supply impedance, filtered comms), measurements should not differ very much with respect to position (at transceiver(s), or anywhere along the cable/connectors).

Overall, some filtering is recommended, and a maximum baud rate of perhaps 50-100kbps is likely feasible.

Noteworthy that RS-232 is more vulnerable to capacitive coupling, due to its high output impedance (single to fractional kΩ); more or less for this reason, it compensates by using a higher signal level (nominally 15V, but most transmitters these days only manage 6-10V). RS-485, with matched-impedance terminations, is about even between inductive and capacitive coupling strengths; its differential connection, with +12/-8V minimum common mode range, affords significant immunity.

If twisted pairs are used (one for data, one for power), the inductive loop area between power and signal is significantly reduced for RS-485. The between-signals twist would worsen crosstalk for RS-232, but again, it's highly unlikely this would be a problem. There will also be a modest reduction in capacitance between power and data pairs, which RS-232 may benefit from.

Both (capacitive and inductive) coupling factors are more-or-less worst-case for plain multiconductor cable; it would seem it should be avoided if possible. The effect of plain multiconductor cable would be to degrade baud rate by requiring additional filtering to ensure signal quality. The effect would only be modest, probably by a factor of less than 2.

If shielding is an option, then individually shielded pairs could be used (at least the data pair), with the data pair's ground being tied to circuit ground, at both ends, as close to the connectors as possible. (Ideally this would be made on a dedicated pin, so that the signals can be received differentially with respect to that ground, at both ends. But I gather this isn't a full-system design scope, so the next best will have to do.) This would allow higher data rates and smaller signal levels; USB might be feasible, for example -- probably not High Speed or above, without the dedicated ground pin, but Full Speed or below would be fine.

Presumably, a badly-behaved device would contain sufficient filtering internally to deal with itself? Maybe it's possible that something could be so bad, not only can it not function by itself, but it knocks out other onboard functions as well; I have no idea.

This also assumes a badly-behaved device can be discarded otherwise-harmlessly, if found to cause malfunction when use is attempted -- malfunction of itself, or of other devices, or the whole system entirely. Presumably including during a mission. I certainly wouldn't want to get stranded at depth; I guess this is an ROV, not piloted, but if it's maneuvered into some inconvenient place, tugging on the umbilical might not be enough to extract it, and I'm guessing that would be a significant capital loss plus scrubbed mission. As an engineer, I would want to see far more consideration of equipment involved here; it should start with a high-level scope, such as risk and cost of failure versus effort required to identify further risk factors (such as this).

  • \$\begingroup\$ So to summarize : 1) twisted pair for everything is probably better than straight for everything. 2) 9600 baud should be easy, I can hope for limits in the 50-100kbps (seems OK to me). 3) I should add some filtering : is it sufficient to do it on the robot end (I don't have access to the other side excepted by messing with the cable)? Any suggestion on how to implement this filtering and at what frequencies to filter? \$\endgroup\$
    – Sandro
    Commented Jan 30 at 17:29
  • \$\begingroup\$ A malfunctioning tool/sensor is likely to be detected during pre-dive checks. If not, it can still be disabled at any point from software (recovery should be possible with any one sensor/actuator missing, even if it can become complicated). \$\endgroup\$
    – Sandro
    Commented Jan 30 at 17:31
  • 1
    \$\begingroup\$ Correct. Any EMI filtering strategy will do; a >= 330R ferrite bead in series, plus 1nF or more to GND, as a damped LC filter, would be fine. Or instead of ferrite bead damping, R+C in parallel with the C. Similarly, an (R || L) in series, or lossy (electrolytic?) capacitor to GND, can help dampen noise/resonance on the power line. \$\endgroup\$ Commented Jan 30 at 17:45

So what is the better solution : twisted or untwisted cable?

Twisted cable is better for noise immunity. It's easier to meet the tranmission line requirements of RS485 cable impedance of 100-130Ω. It would be better to use RS485, because it's more noise immune and tolerates ground potential differences. RS485 also can support much greater cable lengths (thousands of feet vs 50ft (per spec))

Any idea what baud rate I can hope to achieve reliably for the "loosing" protocol (ie the one for which the cable type is sub-optimal)?

No, this is entirely dependent on the trancievers and noise environment typically for 300ft of cable you can achieve up to 1Mbps (theoretical limit), this tapers off to 100kbps at 4000ft.

Source: https://www.ti.com/lit/an/snla049b/snla049b.pdf

As for adding isolation, what would you suggest to isolate? On the robot side, I'm free to put anything I want on the PCB (cost of most electronics components is negligible compared to the cost of the connectors, PCB space is more critical)

If this is intervessel communication, then it's likely that isolation is not needed as I'd imagine the frame and water would keep ground potentials near zero volts and definitely in the range of voltage difference allowed by RS232/RS485

If this is a cable going to the vessel, then isolation would be good just in case you have lightning or some fault with the controlling vessel. Other than that there isn't much EMI in the water.

  • \$\begingroup\$ The RSxxx communication is between the robot and its embeded tools/sensors. So no more than 3m of cable. The question is not choosing RS232 or RS485, but choosing a single type of wires (twisted or not) to accommodate as good as possible both protocols (one at a time) on the same 2 wires. \$\endgroup\$
    – Sandro
    Commented Jan 30 at 17:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.