I have been searching for information about using long cables (6-8 meter) between a controller and a set of 595 shift registers, but have not found any info.
I'm currently testing a 6 meter cable (4 x 2 twisted pairs) and it it work most of the time. Each time I update the 595's I start with clearing the them (^SRCLR).
What I want to know if I need pull-ups and/or pull-down resistors on the input pins on the 595? And if yes, what is the guidelines for choosing the proper resistor value?
I don't think pull-up/down resistors would help at all. They might make things worse.
Please post a schematic showing how everything is wired, including how each of the 4 twisted wire pairs are used, details of all power supplies etc.
Also your code so that we can see how the data is being sent. The data frequency being used will be an important factor.
I don't think using the SRCLR pin will help reduce errors in any way, I would connect them to Vcc.
I would consider a (Schmitt trigger) buffer on the 595 side. With an optional RC input filter.
A quick way is to use CAN drivers, these chips were never meant to be on the end of a long wire. This will give you the capability of very long cables in a noisy environment. Remember the 120 Ohm terminators. On the transmitter side set it to transmit (always on) and the receive side always enables. You will need 1 pair for each signal. There are a lot of other drivers that will also work, depending on what you have access to.
Smajdalf:
I would consider a (Schmitt trigger) buffer on the 595 side. With an optional RC input filter.
Ah... did not thought about that. Good idea - thanks.
Smajdalf:
I would consider a (Schmitt trigger) buffer on the 595 side. With an optional RC input filter.
Which cut-off frequency should I choose?
At least double the data frequency you are using.
PaulRB:
At least double the data frequency you are using.
I'm using shiftOut but have no idea what the data frequency is. The documentation does not say anything about it and I have not found any info on internet.
The shiftOut() function is pretty slow, and you have no control over its speed. Maybe think about using the SPI pins and library. At least then you can specify the frequency.
I see. But there must be a theoretical upper limit for the speed when using shiftOut?
With SPI.transfer() and 328P type Arduino, you can use 8 MHz clock. Way faster than shiftOut().
Or 4 MHz, the default speed.
Then 2 MHz, 1 MHz, 512K, 256K, 128K, and I think 64K the slowest.
thehardwareman:
But there must be a theoretical upper limit for the speed when using shiftOut?
No. It is a software function, code. So it's speed depends on the speed of the MCU running it, its architecture and so on. Uno and Nano will produce the same frequency but Mega may be different, possibly slower, even though that also runs at 16MHz CPU clock. Due, Zero, ESP8266, ESP32, other boards based on chips with faster clock speeds will run shiftOut() at different frequencies, probably much higher than Uno.
My guess would be that on Uno and similar 16MHz boards, shiftOut() frequency will be in the region of the slowest SPI frequencies, perhaps 64-128KHz.
If you have access to a 'scope, please measure the frequency and post it here, along with the specs of the Arduino used to produce it.
Why the h**l can't I start thinking instead of asking early in the morning 
The scope say 143 kHz. It's a Mega2560.
Thanks, but are you sure you are measuring that correctly? What bit pattern is being sent? (I would suggest 0b10101010.) Might be better to measure from rising edge to rising edge, over several cycles.
PaulRB:
Thanks, but are you sure you are measuring that correctly? What bit pattern is being sent? (I would suggest 0b10101010.) Might be better to measure from rising edge to rising edge, over several cycles.
The yellow signal is the clock. So I think I have measured correctly, but correct me if I'm wrong.
Then I think you should measure rising-edge to rising-edge. That's 1 complete clock cycle, 1 bit sent. You seem to be measuring rising-edge to falling-edge, which in theory is half a cycle, but looks less than that to my eye.
Since the duty is not 50% OP needs to measure the shortest interval when designing a low pass filter. The clock speed is not interesting here. The low pass filter must not remove the HIGH pulse.
Sounds like good advice Smajdalf. But also it would be interesting to know the clock frequency and data rate, although that will only apply to Mega, even Uno will be a little different.
At last I had some time to look at this again. Did a new measuring with a scope.
Based on this it seems like the clock frequency is about 45 kHz. So a low pass filter should be designed for 90 kHz?
It's interesting to know that the clock is less than 50KHz, that's slower than the slowest SPI speed. Thanks for that, +1 karma.
But as pointed out, you should design your filter based on that higher frequency of ~150KHz you measured from those high pulses, so make it ~300KHz.
