9
\$\begingroup\$

My current project involves using 74HC595 shift registers to control an LED display, however the display could be up to 5 or so metres away from the Arduino board. The plan is to use some DB9/RS232 cables between a box with the Arduino, and an enclosure with the display. Would the length be too long for the digital signal to travel from the digital out pins to the shift register without degradation?

\$\endgroup\$
2
  • \$\begingroup\$ What's the bit rate/speed of the transmission? Have you tried it and looked at the waves on a scope? \$\endgroup\$
    – endolith
    Commented May 15, 2010 at 12:50
  • \$\begingroup\$ Thank you to everyone for your responses, especially Mark and justjeff. I don't have a real oscilloscope to do some measurements, so I will buy some wire tomorrow and just see what happens. \$\endgroup\$
    – user1307
    Commented May 17, 2010 at 5:55

4 Answers 4

7
\$\begingroup\$

The 74HC595 is CMOS technology so it should take almost nothing in the way of current to drive it, so IR drop wouldn't be a concern.

As long as you keep the frequency of the signals down below say 100kHz, you shouldn't have to worry about transmission line effects. Assuming your intended observer for the LEDs to be the human eye, you shouldn't have to worry about high speeds anyway. For example, 8 digits at 7 segments and a decimal point each is 64 LED elements, and at a mere 9600 bps, you could update the display in just under 7 msec.

The only thing I would worry about is whether the digital high output level from the Arduino will register as a high input at your shift register. As long as the shift register is running from a 5V supply (and not something odd like 6) you should be fine there, too. (and if this was going to be a problem, it would manifest itself over a mere 10cm of wire so that's easy to check)

Short answer: very high probability you can go from arduino to cable to 74HC595s no problem.

\$\endgroup\$
5
\$\begingroup\$

My feeling is you should be fine at this length. Your best bet might be to try it and see if it works.

If it does not work, there are a few things you can do to help: - use shielded, twisted pair cables, or twist cables together. - Put a small cap (0.01 uF or thereabouts) at the end. This should help cancel some of the noise (using too large a capacitor will not work, so bigger is not better in this case). - Use slightly lower valued resistors than you would normally for your pulldowns. - Use low impedance cable.

As a datapoint, an Arduino can run 9600 serial over unshielded cable for 50' (maybe more?).

\$\endgroup\$
5
\$\begingroup\$

You should scope it anyway to ensure its performing correctly but here is the thought process/math you need to take into account to determine transmission line effects.

  • Edge rise and fall time, in opposition what some have posted here, the frequency of the signal does not matter at all when determining when you need to take transmission line effects into account. It is generally true that high frequency signals have faster rise/fall times but low frequency signals can also have very fast rise and fall times if they are being driven at low frequency by a transceiver with a high slew rate. As always use the slowest rise/fall times possible to stay within spec for the parts you are using, you can reduce the rise and fall times with an RC filter at the source. In general you need to consider transmission line effects if the length of the wire is greater than Tr/(2*Td) with Tr = to the signal rise time at the source and Td = to the propagation delay per unit length of the cable you are using. You may also need to properly terminate the signal lines on shorter cables if the load is highly capacitive, this is kind of difficult to calculate upfront as there are many items with capacitive effects in such a system. If you have this problem you will notice ringing (under and over shoot on edges) in the signal.

  • Current in the cable, this will be defined in the spec sheet of the receiving IC as the input current. This combined with the resistance of the cable will tell you if the voltage drop is acceptable given the specs of the receiving IC. This only an average current value. The actual peak current can depend on the type of termination used and needs to be considered when deciding if the driving IC can handle the load or if you need a line driver. The peak current should only last as long as the round trip propagation delay of the circuit.

If you need to take the transmission line effects into account you also need to know the characteristic impedance of the cable and the output impedance of the driving IC.

If you do need to handle the transmission line effects there are a few options for termination style. The only two i would consider are source termination and AC biased end termination.

In source termination you need to place a resistor as close as possible to the driving IC with value equal to the characteristic impedance of the cable minus the output impedance of the driving IC, you may have to tune this a bit to hit spec dead on as the impedance of the cable connectors will also impact the system and as always place the driving and receiving IC's as close to the connectors as possible to reduce reflections. This is probably the easiest method and probably the best method in this case. Peak current will be (Vhigh - Vlow)/(2*Z0) with Z0 = to the characteristic impedance of the cable.

In AC biased end termination you connect to the signal line as close to the receiving IC as possible a resistor in series with a capacitor with the capacitor tied to ground. The value of the resistor should be the characteristic impedance of the cable, the value of the capacitor is determined by the frequency of the signal (the R and C form a low pass filter). The peak drive current is the same as for source termination. The average drive current is dependent on the duty cycle of the signal, if its very close to 50% then it will be roughly equal to to the input current of the receiving IC, if it is over 50% the average drive current will be higher. As the R and C form a low pass filter this termination style will filter out some high frequency noise.

Couple other things to keep in mind:

  • Using twisted pairs for a single ended signals does not reduce noise pick up at all. It does result in a more consistent characteristic impedance for the transmission line. This may make the output look better if you really should have properly terminated the signal but didn't. It does nothing to reduce outside EM noise on the line.

  • Use of shielded cable on a single ended system is iffy at best. You can often create a situation where outside noise capacitively couples to the shield resulting in current flow on the shield which then couples to the signal wire. I wouldn't bother using a shielded cable unless your using differential signaling. Also the usefulness of a shield on high frequency noise is dependent on the inductance to ground, low inductance paths usually require special connectors.

You can use very much the same thought processing on any line be it a cable or a 2 inch PCB trace.

\$\endgroup\$
2
  • \$\begingroup\$ I have quite a few comments, but only one I have time to type right now. When I say frequency of the signal I am referring to the frequency components of my signal. This is determined completely by the rise/fall time of a digital signal. \$\endgroup\$
    – Kortuk
    Commented May 17, 2010 at 0:10
  • \$\begingroup\$ I assume a digital signal for my entire post and when i say the "frequency" of a digital signal i'm referring to the max switching frequency of the signal. whiles its common to discuss the content of analog signals in the frequency domain its generally not as useful to discuss digital signals in that domain. \$\endgroup\$
    – Mark
    Commented May 17, 2010 at 21:50
4
\$\begingroup\$

You will probably need buffers to drive that length of cable - something like the 74HC244 buffer/line driver should be suitable.

\$\endgroup\$

Your Answer

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