For slow digital circuits, do I need ground between each wire?

I'm designing a pass-through circuit for a project at work, and I'm running in to space issues. I have a block of thirteen digital signals and I'm wondering if I need a ground wire between each. The ribbon from my circuit to the next board is maybe 6 inches, and the signals are 0-5V logic that change states maybe once per minute. Seriously slow.

Do I really need to ground every other conductor in this case?

No.

Well ... maybe if it's installed next to some nuclear submarine engines or something.

Best are a ground between every signal
Next best are 1/3 are ground and so on until you have one ground
With one ground let it be in the middle.

With a good construction and layout it can work well with reduced nb of ground leads.

The only way to know is to measure (EMC or the FCC regulations)

Pelle

Are you referring to shielded signal cabling? Unless they passing next to a high current motor, transformer, power conduits, next door to radio tower, hydro plant, or a Tesla coil the need to ground often will be minimal.

the signals are 0-5V logic that change states maybe once per minute. Seriously slow.

I would say no as well.

There's little danger of crosstalk, either.

Think about all those ribbon cables that are used in computers carrying fairly high signal rates. They certainly do not have inter-core grounds

They certainly do not have inter-core grounds

True but sometimes on a ribbon cable every other wire is a ground. This provides a limited amount of shielding and can help prevent radiation from a rapid switching signal.

Verdris:
I'm designing a pass-through circuit for a project at work, and I'm running in to space issues. I have a block of thirteen digital signals and I'm wondering if I need a ground wire between each. The ribbon from my circuit to the next board is maybe 6 inches, and the signals are 0-5V logic that change states maybe once per minute. Seriously slow.

Do I really need to ground every other conductor in this case?

You could also consider twisted pair if you're getting EMI noise. But my guess is that the cable distance isn't long enough to cause a problem.

Tim

jackrae:
Think about all those ribbon cables that are used in computers carrying fairly high signal rates. They certainly do not have inter-core grounds.

What about the 80 core ribbon cable used on 40 pin IDE hard drives? I also suspect that SATA data leads are shielded, but I've never taken one apart to confirm it.

Henry_Best:
What about the 80 core ribbon cable used on 40 pin IDE hard drives?

Yes, they have 50% ground wires.

Your point is...?

jackrae:
Think about all those ribbon cables that are used in computers carrying fairly high signal rates. They certainly do not have inter-core grounds

Which ribbon cables? The only ones I can think of are the 34-pin interface for the floppy drive and the 40-pin interface for the (parallel) hard disk drives and they absolutely have every second conductor grounded.

Henry_Best:
What about the 80 core ribbon cable used on 40 pin IDE hard drives? I also suspect that SATA data leads are shielded, but I've never taken one apart to confirm it.

The 80-core cable on PATA drives has (approximately; see the link) three out of four wires as ground shields. Some such cables are in fact shielded.

And yes, SATA cables are shielded as well as having alternate grounds.

Damn, wrong again :~

Basically you need to consider two problems

a) Cross-talk pick-up which can be minimised by inter-core grounding or low impedance loading of the cores
b) degradation of the high frequency components on the leading and trailing edge of the pulse due to cable capacitance

It really is irrelevant whether you are transmitting 1 pulse per day or 10,000 per second; the above problems still exist (or not, if you aren't too bothered about cross-talk or pulse shape)

In an application where it's 5v and switches every few minutes, that sounds like simple controller I/O. You would need some massive amount of induction to mess up that logic. Leading edge does not matter for most micro controller I/O thus one has to wonder why you or someone else picked that cabling.

That said I would almost never use this form when doing a proffestional project, 90% of the people have no clue what they are saying and the rest can only make educated guesses do to lack of information a lot of the time.

fungus:

Henry_Best:
What about the 80 core ribbon cable used on 40 pin IDE hard drives?

Yes, they have 50% ground wires.

Your point is...?

They have inter-core grounds, which jackrae denied.

Whilst I admit I was wrong, I didn't actually state which type or size of ribbon cable I was referring to. :smiley:

jackrae:
a) Cross-talk pick-up which can be minimised by inter-core grounding or low impedance loading of the cores
b) degradation of the high frequency components on the leading and trailing edge of the pulse due to cable capacitance

It really is irrelevant whether you are transmitting 1 pulse per day or 10,000 per second; the above problems still exist (or not, if you aren't too bothered about cross-talk or pulse shape)

Um, not it isn't.

Crosstalk is caused by changes in the magnetic field of neighboring wires. How efficient do you think a transformer would be if the input was 0.00001Hz (compared to, eg. 10,000Hz).

If you're only transmitting one pulse per day, do you really think it matters if the leading edge is perfectly square or not?

And ... if you were worried by crosstalk (which you're not), the simplest solution would be to separate the wires of the ribbon cable.

jackrae:
It really is irrelevant whether you are transmitting 1 pulse per day or 10,000 per second; the above problems still exist (or not, if you aren't too bothered about cross-talk or pulse shape)

100 million?

And the answer to the original question - noting that the asker never came back to elucidate his real problem - is that it depends entirely on the response characteristics of the device receiving the infrequently changing signal. If it can respond to glitches caused by crosstalk, then the transitions may be a problem, in which case it will need to be conditioned to implement "debouncing".