RS232/DB9 cable for 'remote control'

Fo my project (time lapse photography) I would like to separate the control part from the 'sled' that runs over a track. On the sled I would like to have two steppers, two drivers, a nano, and 3 buttons. On the 'remote' I need to have a rotary encoder, an LCD module and 2 buttons.

I was thinking of using a RS323/DB9 connectors and cables to connect the remote to the arduino nano and power supply and I found that most commercial made cables have a length of about 1.4 meters.

Will this length, or anything else in this setup, cause any problems? The power supply will be connected to the sled.

How long should your cable be?

Using RS-232 cables for other purposes may not be a good solution. The DB9 connector is okay (rugged...), but the high frequency signals from your devices suggest some twisted-pair lines to me, at least for SCL and SDA. Also the power lines should be thick enough to power the devices, e.g. multiple thin wires can be used together for Gnd and Vcc.

If you use RS-232 cables, at least the SCL and SDA signals should go to the RX and TX pins.

From your drawing I2C is probably the most sensitive to cable length/cross talk. You can get LCD modules that use serial to receive data and this would allow for a longer cable or more robust data transfer.
What type of encoder are you using that needs power and ground.

This is the encoder I'm currently using: Encoder/

I only need about 0.5 - 1 meter of length between the nano and the remote. If there were only 8 wires I'd probably be better off with a cat 5.

DrDiettrich:
How long should your cable be?

Using RS-232 cables for other purposes may not be a good solution. The DB9 connector is okay (rugged...), but the high frequency signals from your devices suggest some twisted-pair lines to me, at least for SCL and SDA. Also the power lines should be thick enough to power the devices, e.g. multiple thin wires can be used together for Gnd and Vcc.

If you use RS-232 cables, at least the SCL and SDA signals should go to the RX and TX pins.

I always assumed that I would need to use the A4 and A5 for the I2C connection but I was looking at some 'instructables' and they connect the same LCD module to RX/TX. Does that mean I can just move the wires from A4/A5 to RX/TX without any problems? The example uses the same library.

You should be able to get away with just 4 wires for the encoder if you use the internal pullup resistors on the arduino pins. Then you won't need the power for the encoder (though this will not reduce your conductor count). If you used a UART backpack (something like this) on your LCD display then you would only need 3 conductors for that (V+, GND, RX)

I currently have this one : LCD Module.

The UART is a different one I see.

I thought I needed the power on the encoder for the button. I'll try and see what happens if I remove the power. It will not solve my wiring problem but would like to know if that would work anyway :slight_smile:

If I can get rid of one more wire, by using a separate power supply not the remote, would a cat5 cable be OK for the connection to the nano? It would still only be about 1 meter or so.

thanks for helping.

snewpers:
I currently have this one : LCD Module.
I thought I needed the power on the encoder for the button. I'll try and see what happens if I remove the power. It will not solve my wiring problem but would like to know if that would work anyway :slight_smile:

If you turn on the internal pullup resistors for the A, B & switch inputs and then connect C & other side of the switch to GND it should work.
Cat 5 cable should be fine if you get down to 8 conductors.

I think that if the cable length gets to 1m or more then you should prepare to have external pull-ups on your encoder. It is too easy to pick up glitches with only the weak internal pull-ups.

I2C will likely be a problem when longer than 20cm, although I have seen reports of "no problems" for longer than 1m. You should put pull-ups on the far end and do the calculations for the maximum pull-up effort (lowest resistance). Twisted-pair does not help I2C.

Thank you! I have to read about external pullups a little more. Many topics about it are quite confusing for me. I have separated the power supply so it will be a cat5 cable. Not sure ifi understand something I read correcly, but it seems I can comment out the internal pullup in the wire.h lib and use my own external pullups. They mention lowering the resistors to 1k-4k7, instead of the internal 30k. Would that be of any benefit for my situation? I'm a graphic designer for a living and not an electronics guru so it's all a bit vague for me to be honest. I appreciate the input

4k7 is a good value for most any I2C bus. It is a "stronger" pullup than the internal pullups.

1-4.7 k is also a good value for the encoder pullups.

Twisted pair cables have a defined characteristic impedance, so that the terminating resistors can be dimensioned to match that impedance. Failing to match impedances, or use of unspecific cables, will result in problems with reflections on the cables, the more the higher the signal frequency.

Thanks!

I have to figure out what I need to calculate the impedance and the resistor to match that. A cat5 cable has an impedance of ~100ohm, wiki says. I assume using quality cables, so that's what I'll be using.

I'm lost now... I don't know how to calculate the needed resistor. Can you please point me in the right direction? I don;t mind learning/trying but I'm far away from understanding it all.

Thanks!

edit:

http://www.marvintest.com/KnowledgeBase/KBArticle.aspx?ID=196

This page says that terminating a 100ohm line requires a 100 ohm resistor at the end. That not near the 1k = 4k7 figure at all. Is this not what I need to read?

The right termination resistor (here: pullup) equalts the line impedance. Unfortunately 100 Ohm is too low for the I2C bus, so that a cable of higher impedance should be used.

...or a stronger I2C driver. You can get chips that will drive the I2C line harder for longer distances. I've used the 82B715 chip in one design. It never got fully tested, so I can't say if the distance claim is true.

But I2C is the wrong choice if the cable is going longer than a meter or so. You should choose a different technology if you really need this kind of distance.

This is confusing :slight_smile:

I've read about the I2C extender chips from NXP which should allow for (much) longer distances but I also found this one (with the sam chip):

Link to module

The odd thing is their description:

This module is designed to enable long range I2C communications which extends the cable length from several meters to about 50 meters. Operating with any I2C master, slave or bus buffer is the primary advantage of this module. NXP P82B715 I2C bus extender IC is used as the main component on this module. The module has four pull-up resistors on board: two on the unbuffered bus side and another two on the buffered bus side. Additionally, there are two LEDs indicates the SCL and SDA activities on the bus. Both the LEDs are driven by transistors which draw negligibly small current from the SCL and SDA lines.

That would imply that several meters can be done (I need 1).

As a last resort I would move away from I2C but I rather not since I have this thing working now and moving stuff around will cost me another week to fix things :slight_smile: I will look into UART now then.

Thanks

Ok… Change of plans. I don;t want to add more components than needed just to be able to move the ‘remote’ for a meter or so. Or risk bad signals from te rotary encoder. I’ll modify my ‘sled’ to hold everything but the power supply/battery pack. I have to adjust my 3d design so this is neatly integrated but that is probably easier for me :slight_smile:

I’ll still read up on the shortcomings of I2C for future projects. Thanks for helping, greatly appreciated!

Signal transmission is limited by the power of the controller outputs. Fast slopes, for data rates, require some power on long lines, regardless of the transmission protocol. Also unipolar digital signals are more susceptible to interference than differential level transmission. Line drivers are inevitable for reliable and fast connections over long cables, where "long" mostly depends on the transmission frequency - slower data rates allow for longer distances with the same hardware. If such additional circuits are required, then the choice of driver modules also allows the transparent use of e.g. fibre optic cables or wireless transmission.

Thanks

Are encoders, LCD’s and sensor in the ‘fast data speed’ section? And are LED’s and momentary buttons in the slow(er) section?

All manual inputs (switches, encoders) are in the low speed section.

Rotary encoders for the speed measurement of motors can have anything from 1 to many hundred pulses per revolution, to be multiplied by the motor speed, i.e. depend on the actual use.

Sensors often have more powerful digital outputs than a controller has, while analog voltage signals are very susceptible to external interference. Analog current signals instead are very robust, designed for use in hostile environment.

Serial transmission lines and bus systems (I2C, SPI, CAN...) are high speed communication channels by design, but the data rates (baudrate...) usually can be adjusted to the real needs. In a practical test a cable can be used, that is much longer than the really required length. If everything works with that cable, it will work with the shorter cable as well. Another topic is the susceptibility to external disturbance, depending on the environment.