Ribbon Cable Cross Talk - Is there a fix after the fact?

Question

I'm involved in a project where the customer defined pins in a ribbon cable, without considering possible cross-talk issues. The signals are 1 MHz data signals with no ground wire separating them. I've never had experience with cross-talk and was amazed at the size of the induced glitches (0.5 to 0.65 volts). The receiving side was using 74HCxx line drivers (CMOS switching levels) which resulted in pure garbage on the data stream. The customer is switching to 74HCT drivers in an attempt to move the input "high" switching level below the glitch level, but I have my concerns.

Is the anything that can be done, besides switching to HCT parts or just properly redesigning the board to possibly salvage what we have?

Answer 1

Can you change the ribbon cable, or insert an adapter to a higher pin-count cable? Consider what IDE/ATA did to increase bandwidth -- it was switched from a 40-wire cable to an 80-wire cable, with every other wire inside the cable tied to ground within the connector. A similar solution could apply here.

Alternatively, can you reduce the slew rate? At 1 MHz, your problem is likely to be less about the frequency of the signals themselves and more about their fast edges. A filter network on the transmit side may help.

Answer 2

You can leave the board design as-is, but make a short adapter on both ends of the cable, and make the actual cable either as a non-ribbon cable (micro coax, this will be the best), or use proper grounding between signal wires. Essentially you need to make a different cable to fit the IDC plugs (or whatever they selected as board-to-cable connector). Something like this:

Answer 3

The signals are 1 MHz data signals with no ground wire separating them.

This is pretty slow, so first check if there are source termination resistors on the driving side. If there are resistors, you can increase their value to lower the slew rate.

If there are no source termination resistors, then whatever is driving this cable is going to push surprisingly large current pulses into the cable capacitance on each level transition, which will mess up the power supply of the driving chip if it is not properly decoupled. So, check on the scope whether you get "crosstalk" on BOTH edges, or only ONE edge, or different amount of crosstalk on both edges, check the power supply of the cable driver, also probe its GND pin versus the GND plane. Try flipping one signal while leaving the others alone. If it "crosstalks" from one wire at one side of the cable to all the other wires in a similar amount, then it's not crosstalk, rather it's the driver chip having ground bounce or bad decoupling, so you'll need to fix that.

If the signal is synchronous and you have a clock line, you can play with clock timing. If the data is latched into a register on the receiving end, levels only matter inside the setup/hold window. So if you shift the clock a bit to make it trigger after the signals have settled, it can help. Unless you got crosstalk into the clock signal too, in this case it will double clock and that's not good.

The customer is switching to 74HCT drivers in an attempt to move the input "high" switching level below the glitch level, but I have my concerns.

Yeah, but it will also move the input "low" level down and make it more sensitive to noise, so it may "fix" the crosstalk on one edge, but worsen it on the other edge! I guess this could maybe work if your signal is synchronous, and it uses a high-to-low clock edge but... mehhh... better use a Schmitt trigger gate.

Is the anything that can be done, besides switching to HCT parts or just properly redesigning the board to possibly salvage what we have?

Before redesigning, make sure you confirm whether it's really crosstalk... or ground bounce or bad decoupling in the driving chip.

Also make sure it is not ground bounce between the two boards caused by current flowing in the GND wire and creating a voltage difference between the boards.

If you're out of pins and use synchronous signals (with clock) you can put the GND line between the clock and the data lines, to prevent data edges leaking into the clock.

Answer 4

After the fact, you have a few choices:

1. Use Schmitt trigger input receivers
2. use shielded foil ribbon cable
   • Edit: @Duskwolf has the best solution: I forgot all about the 80 wire cables ( senior's moment )
3. terminate with 470 pF as a starting value
4. terminate with cable impedance 110-120 Ohms to ground
5. terminate with driver impedance ~ 50 Ohms to Vcc/2 ore equiv pull/down

Increasing the source resistance reduces risetime but won't reduce crosstalk , because the impedance ratio of crosstalk capacitance Xc/Rs rises as slew rate of current reduces.

edit

Proof of ideas using 1m ribbon cable estimate ESL and C

Here using 5 different signals near 1MHz square wave but different to get alias crosstalk with different source and load impedances. Normally I recall, ribbon cables are 120 Ohm single ended which translates into a lump inductance and capacitance per meter but depends on AWG and dielectric spacing.

Answer 5

For minimal crosstalk, you need

(1) widely spaced ribbon-cable wirings, thus large diameter plastic jackets; this gives minimal picoFarads/meter and minimizes the cable currents (minimal magnetic fields)

(2) metallic foil shields around the ribbon cable, to capture most of the Efields; ground these foils.

(3) minimal cable currents and slowest edge speeds (slow slewrates), so the dI/dT is slow and the magnetic-field coupling is minimal; thus use WEAK drivers

(4) source terminations, perhaps 100ohms

Notice the mindset: (A) reduce the Electric-field crosstalk, using larger wire-wire spacings, and using a shield to capture most of the Electric flux and in fact reduce the wire-wire capacitance; also reduce the dV/dT. And (B) reduce the Magnetic-field crosstalk, by increasing the wire-wire spacing, by reducing the "loop area" with a return-path (shield, foil) located very close, by slowing the dI/dT because the dV/dT is reduced, and reduce the current by not terminating at the receiving end.

Answer 6

Are you sure the glitches you see are crosstalk (and not, for instance, ringing due to unmatched impedance or power supply noise)? Try to route one line through a separate shielded wire: the crosstalk would disappear in it, while the ringing and power supply noise would remain.

I strongly suspect that you will see it is ringing, and the problem will go away once you match the impedances of the cable and the driver.

If the issue is really due to crosstalk, you could improve the situation a lot by decreasing the impedance of your receiver inputs. Crosstalk voltage may be high enough to disturb the signals levels, but it's certainly not as powerful as actual signals. Which means, if you add pull-up or pull-down resistors on the receiver side of your data lines, they will absorb a significant part of the crosstalk noise, while having minimal effect on the signals.

Power supply noise is usually eliminated by decoupling caps.

Answer 7

You can consider addressing this issue in the control software. You can measure the crosstalk from each source wire to each output wire. This defines a "crosstalk matrix". After you have measured each element of this crosstalk matrix you can calculate the required compensating voltages on the other wires by matrix inversion.

Answer 8

Wrap the ribbon in aluminum tape (the thick conductive one used to seal ducts; NOT duct tape, actual aluminum + glue only), and connect it to ground only on your device's end. It may not remove the crosstalk completely, but it will add capacitance to each line and also provide a shield, which may be enough for your application. This will reduce the cable flexibility though...