serial-bench / instruments / msg #1
This is the entry that made me start writing things down, and it is not a success story. I spent four hours convinced that a board had a failing clock buffer. The clock was fine. My capture was three samples wide and I had been reading its artefacts as physics.
The setup was ordinary: an 8 MHz SPI clock, chip select, and two data lines, captured on an eight-channel analyser running at 24 MS/s. That is a sample every 41.7 ns against a clock period of 125 ns, so three samples per period - and three is a number that produces a very convincing lie.
Two things, both wrong.
The clock looked unstable. Cycle after cycle it alternated between appearing high for two samples and low for one, then high for one and low for two. On screen that reads as a clock whose duty cycle is wandering between 33 % and 67 %, which is alarming and is exactly what you would expect a dying buffer to do. What it actually is: the sample grid and the clock are not phase-locked, so the position of each edge relative to the grid walks, and the reconstruction rounds each edge to the nearest 41.7 ns. The clock never moved; my ruler did.
Then there were glitches on chip select - narrow pulses that showed up in some captures and not in others, never in the same place twice. Intermittent faults are the ones you chase hardest. These were not intermittent at all.
A sampler can only see a pulse if a sample instant falls inside it. For a pulse of width
w arriving at a time uncorrelated with the sample grid of interval
Ts, the probability of catching it is w / Ts when w is
smaller than Ts, and one when it is larger.
My chip-select line had a genuine 30 ns settling artefact from a series resistor I had
fitted. With Ts = 41.7 ns that is a 72 % chance of being recorded per occurrence -
so it appeared in roughly three captures out of four, in a different sample slot each time. The
analyser was not malfunctioning and the board was not intermittent. A coin was being flipped,
and I was reading the sequence of flips as a fault pattern.
The scope settled it in two minutes once I bothered: 1 GS/s on the same clock pin showed a 50.2 % duty cycle, rise time 4 ns, and the chip-select artefact present on every single edge at a consistent 31 ns.
| Samples per period | Example at 24 MS/s | Use it for |
|---|---|---|
| 3 | 8 MHz clock | nothing but «a clock is present» |
| 8 | 3 MHz clock | decoding bit values, bus state, protocol order |
| 20 | 1.2 MHz clock | duty cycle and skew to roughly ±5 % |
| 50+ | 480 kHz clock | quoting an edge position as a number |
Expressed as rules rather than a table: eight samples per bit to read data, twenty before I put a percentage in a report, and a sample interval of at most half the narrowest pulse I am not willing to miss. If the signal is faster than that, the analyser is the wrong instrument and the scope comes out.
There is a trap that more samples will not fix. An analyser input is a comparator with a fixed threshold - 1.5 V on mine - so it converts a slow edge into a single time, and that time depends on the slope. A rising edge that takes 400 ns to get where it is going crosses 1.5 V at some point in the middle, and the capture shows a clean transition there with no hint that the line spent most of the bit cell in between. That is why the whole I²C rise-time investigation had to happen on the scope: the analyser cannot represent the quantity in question.
Two years on, this remains the most useful thing on the bench: before trusting a capture, work out the samples per bit and the smallest pulse the setting can detect. If the capture is inadmissible, you have saved yourself an afternoon of inventing explanations for your own instrument.