SPI reliability over ~120 cm total (100 cm PCB trace + 2 board-to-board connectors + 20 cm cable) at 100 kHz — real-world experience?

[ustunn]

Hi all,

I'm designing the control electronics for an automatic egg-candling machine (150 positions). An STM32F411 drives everything over a single shared SPI bus:

• A 74HC595 daisy-chain (shift registers → ULN2803A → solenoid valves)
• MCP3208 ADCs (reading LDR light sensors) on the same SPI bus, CS-selected

The process is strictly sequential (read all sensors first, then actuate valves — never at the same time), so valve-switching noise never coincides with an ADC read, and SPI speed is not time-critical. That's why I want to keep the clock slow.

Physical signal path (my concern):

• ~100 cm total PCB trace
• 2 board-to-board connectors (PCB-to-PCB)
• then a 20 cm cable that enters the target IC (74HC595 / MCP3208)
• Planned SPI clock: 100 kHz, SPI mode 0, 3.3 V logic

Mitigations planned: series termination on SCLK/MOSI/LATCH at the source, ground interleaving in the cable, star grounding (valve PGND separated from SPI/logic GND), local 3.3 V regulation at the far end.

My own bench test: I ran an SPI loopback (MOSI→MISO) over a 2 m unshielded cable hanging in free air, no termination, sweeping the clock. Result: zero errors from 100 kHz up to 8 MHz; errors only appeared from 12 MHz upward, and those look like the round-trip propagation delay of the loopback (MISO arriving late vs. the sample edge), not signal degradation. So the fundamental margin looks large.

Questions:

1. Has anyone run SPI reliably over a similar path (~120 cm total: PCB + connectors + cable) at low clock (100 kHz–1 MHz)? "Just works" or horror stories?
2. With a real 74HC595 chain + MCP3208 as the load (not a loopback), any gotchas over this distance — SCLK integrity, edge rates, reflections at the connectors?
3. Is series termination + slow clock enough, or would you add a buffer/re-driver (e.g. a 74HC buffer at the cable entry) for SCLK/LATCH?
4. Any recommendation on cable type / grounding scheme?

[David Littell]

I’ve run 8 MHz over 8-12 inches on both a PCB and via fly leads (for demo) with SCK reflection being one of the most troublesome problems.

For an Actual Real World application requiring a cable I’d look at using CAT5E with ADI’s LTC6820’s.

[Andrew Neil]

For an Actual Real World application requiring a cable I’d look at using CAT5E with ADI’s LTC6820’s.

For low-ish speed like this (OP said 100kHz), would RS422 do?

Or even RS232?

Modern RS232 transceivers can do ~1Mbps; eg,  MAX3237E - also from TI.

 

[David Littell]

Sure, but OP sounded like he was committed to SPI.

[Andrew Neil]

​@ustunn you didn’t say much about the environment this has to operate in?

Specifically, is it electrically noisy?

Is isolation required?

[AScha.3]

Hi,

i use SPI always to connect to TFT displays, so some examples, the line, speed:

• free air wires, ca. 50mm ; stm32F303 , no problem at 18 MHz ok. (36M , next possible step, too much for the TFT )
• standard 10pin flat cable, stm32H743, about 100mm, + 80mm onboard; 34 M ok. (faster TFT chip , ST7789 )
• standard 20pin flat cable + header, stm32H743, about 60cm test : 16M  ok. (TFT with EVE controller )
• standard 20pin flat cable + header, stm32H743, about 2m test : 16M problem, 8M ok.
• with proto board and about 200mm 0,2mm wires, STC15 cpu @1MHz + 4x HC595, 500kHz ok.

Important :

• set pin speed of stm32 not too high, to avoid reflections/ringing (these cpus have really fast drivers ! ).
• if use simple unscreened flat cable, have many pins, -> :  gnd, clk, gnd, sda, gnd, latch, gnd, vcc, vcc .
• so get about 50% screen “for free “ , maybe add serial damping 51 ohm. (but for 100kHz….come on. :) )

[ustunn]

Thanks everyone — really helpful, especially the real-world data. AScha's 2m/8MHz and the 500kHz + 4× HC595 example are almost exactly my case, that's reassuring.

To answer Andrew's questions about the environment — here's the full system:

Application: an automatic egg-candling (ovoscopy) machine. An STM32F411 is the master on a single shared SPI bus doing two jobs:

• Reading: 150 LDR light sensors spread over a ~500 × 720 mm area, read via MCP3208 ADCs (CS-selected).
• Actuating: 150 solenoid valves via a 74HC595 daisy-chain → ULN2803A. An egg that reads infertile gets blown off by its valve.

The sequence is strictly sequential: COB LED light on (via a 220 V contactor) → ~1 s settle → read all 150 sensors → decide → then drive the valves. Reads and valve switching never overlap in time. The 150-bit result is also sent to a Delta PLC over a separate, galvanically isolated RS-485/Modbus link (ADM2582E) — the PLC runs the HMI (one lamp per position) and lets the operator set the detection threshold.

Noise: yes, some — a 220 V contactor for the lighting and 150× 24 V solenoid valves. But (1) the contactor fires ~1 s before any read and settles, (2) valve switching is time-separated from the sensor reads, and (3) grounding is star-point with the valve power return (PGND) kept separate from the signal/logic GND, joined once near the supply.

The SPI path I'm unsure about: the 595/ULN drivers sit on a valve-side PCB, so the bus runs ~100 cm of PCB trace + 2 board-to-board connectors + a 15–20 cm cable up to that valve PCB. Clock 100 kHz (could go higher). I'll add series damping on SCK/MOSI/LATCH, a GND-interleaved ribbon, and low GPIO slew rate as suggested.

Since the internal SPI never crosses ground domains (everything shares the same 24 V / star ground; the only cross-domain link is the already-isolated RS-485 to the PLC), I don't think galvanic isolation is needed on the SPI itself.

Questions:

1. Given all this, does plain SPI (100 kHz, damping + GND interleave + low slew) sound safe for a 150-valve / 150-ADC bus over ~120 cm, or would you still isolate / go RS422?
2. Any concern with one shared SPI bus serving both the 74HC595 write chain and the MCP3208 reads (CS-selected), given the sequential timing?
3. For the 595 chain over the cable — would you read back the shifted data (loop the last 595's QH' to MISO) to verify each frame, or is that overkill at this speed?

Thanks again!

[Ozone]

> My own bench test: I ran an SPI loopback (MOSI→MISO) over a 2 m unshielded cable hanging in free air, no termination, sweeping the clock. Result: zero errors from 100 kHz up to 8 MHz; errors only appeared from 12 MHz upward,

The result will look different with several tappings and loads.

> Has anyone run SPI reliably over a similar path (~120 cm total: PCB + connectors + cable) at low clock (100 kHz–1 MHz)? 

Yes, one of my former companies did that for similiar distances.
However, the devices were different - and here is were I see the problem :
With a real 74HC595 chain + MCP3208 as the load (not a loopback), any gotchas over this distance — SCLK integrity, edge rates, reflections at the connectors?

This are simple logic devices, you get no error feedback for glitches or missed clock cycles, and no way to correct it without a power cycle. With more “complex” devices (MCUs) you could enable the CRC mechanism or another error check.

> Any recommendation on cable type / grounding scheme?

We used shielded ethernet patch cables (with RJ45 connectors) back them.
They were quite workable, relatively cheap, and reliable.

[ustunn]

Thanks for all the input on my SPI-over-distance question — it got me reconsidering the whole architecture, and I'd like a sanity check.

Current (central) design:

• One STM32F411 master.
• Drives 150 solenoid valves via a long 74HC595 daisy-chain (→ULN2803A) and reads 150 LDRs via MCP3208 ADCs, all on one shared SPI bus.
• The bus runs ~120 cm (PCB + connectors + cable) to reach 6 distributed cards over a ~500×720 mm area.
• Robustness measures: series damping on SCLK/MOSI/LATCH, low GPIO slew, GND-interleaved shielded cable, per-card clock buffers, and 595 QH' read-back verification (shift a known pattern, read it back, re-shift if wrong, latch only when verified).

Proposed (distributed) alternative:

• One small MCU per card (e.g., STM32F103, ~$1–2) handling that card's 25 LDR reads + 25 valve drives locally — short traces, no long SPI.
• The F411 master coordinates over an RS-485/Modbus bus (CRC in the protocol) — or CAN if I move the master to an F407.
• Master also talks to a Delta PLC (already RS-485/Modbus) + USB/DFU.

The distributed version removes the SPI-over-distance problem entirely (all high-speed digital stays local), adds fault isolation, gives protocol-level error checking, and reduces the inter-card wiring to a 2-wire differential bus. Cost is ~$15 more (6 cheap MCUs + transceivers) and it adds an inter-MCU protocol.

Questions:

1. For a machine like this (150 I/O over ~0.5×0.7 m, moderately noisy — 24 V valves + a 220 V contactor), would you go central + long shared SPI, or distributed nodes on RS-485/CAN?
2. Is the multi-MCU complexity worth it here, or is central + read-back robust enough?
3. If distributed: RS-485/Modbus (keeps my F411) or CAN (needs an F407 or external MCP2515)? Any strong reliability preference?

Thanks!

[Ozone]

I suspect RS-485 and Modbus would be cheaper.
And Modbus seems more applicable to such machine control tasks, as this protocol originally comes from the PLC world.
CAN is more trimmed towards automotive needs, tends to be more complex, and more expensive.

I think both RTU or ASCII should work in your case.

 

> I'm designing the control electronics for an automatic egg-candling machine (150 positions).

I suppose there is a typo, and you meant “egg handling”.
The controller requirements depend also on the actuators and their specific speed, but I assume a 10...50ms cycle time would suffice.
I think a F4xx MCU could easily manage that.

[Andrew Neil]

I suppose there is a typo, and you meant “egg handling”.

No, “candling” is an actual thing - it was originally done with a candle behind the egg:

https://en.wikipedia.org/wiki/Candling

 

but it does, indeed, involve handling the eggs!