> By the way, I am clocking at about 30KHz - speed is not really an
> issue - if necessary I could use a slower speed (although 30KHz is
> already quite slow!).

|  I agree.  Speed is not really an issue.  It's not speed, it's called
|"propagation".  I think good design would allow operation at maximum
|rated speed anyway.  Further:

|Dave Vanhorn wrote:

> Talk slow, add series resistors at the drivers, say 120 ohms, and
> scope the ground pin on the farthest board relative to system.  Scope
> VCC on the farthest board, relative to it's own ground.  You may need
> to beef up the ground. Just guessing..

|  I disagree.  Make the thing work, and it'll work at any speed.

I would suggest that it's probably best to drive the clock wire
with sharp edges, but add a little bit of RC delay to the data
wires going between the '165's [same with '595's or '597's].
This will ensure that the clock's arrival at one '165 will not
affect the data at the next '165 immediatly, but only after a
short delay (by which time the next '165 should have latched the
old data).

Note that, in response to the question elsewhere about whether
non-simultaneous clocking would cause data loss, the answer is
that in one direction it will; in the other it won't.  As for
adding the RC delays, what you're really doing in effect is
adding one bit of short-term storage after each shift register.
Since the RC will 'automatically' change state after a short
delay, it should be transparent to the software provided the
data shift rate isn't too high.