Mr. IntegralThe puzzle
The code looks right and the debugger shows the right values, but the sensor still answers with garbage. The disagreement is on the wires: a clock edge too early, a chip-select released a microsecond too soon, a glitch that the receiver sees and you do not. A debugger cannot show that. What do the instruments that watch the wires record, and how can they mislead you?
STEP 1
A logic analyser records samples, not edges
A logic analyser compares each input with a threshold at a fixed sample rate and stores a 1 or a 0. Everything it shows is reconstructed from those samples: an edge is drawn at the first sample after it happened.
↑ This step uses the figure at the top of the page.
Two consequences follow directly:
- Timing resolution is one sample period. Each edge can be misplaced by up to one period, so a measured width or delay can be off by up to one period in either direction, and it changes when the samples happen to fall differently.
- Short pulses can vanish. A pulse shorter than one sample period may fall entirely between two samples. The glitch that resets your chip may simply not be in the capture.
The practical rule is to sample several times faster than the shortest pulse or bit you care about, and faster still if you need to measure its width.
STEP 2
Decoders turn samples into bytes
Protocol decoders read the captured samples and show bytes, addresses and errors. A UART decoder knows the baud rate, finds the start bit’s falling edge and then reads each bit at a chosen point of its bit time, the middle by default. With s samples per bit, that point can land up to one sample away from the ideal, so s must be comfortably large. A clocked protocol such as SPI is easier: the decoder reads the data line on the clock edge, so the capture only has to keep the order of clock and data edges right.
STEP 3
An oscilloscope shows the voltage
A logic analyser reduces every signal to two levels at one threshold. An oscilloscope shows the voltage itself: slow edges, ringing, a high level that only reaches 2.4 V, noise on a supply, a signal stuck in the undefined band (unit 1, lesson 2). Its limit is bandwidth. A scope and its probe behave roughly like a low-pass filter; for a single-pole RC response the 10–90 % rise time is 2.2RC and the bandwidth 1/(2πRC), so
What you see is approximately the root sum of squares of the signal’s and the instrument’s rise times, so an edge never looks faster than the instrument.
A scope and its probe behave roughly like a low-pass filter. For a single-pole response the 10–90 % rise time is 2.2RC and the bandwidth 1/(2πRC), so tr = 0.35/BW. Rise times of cascaded stages add approximately as a root sum of squares, so what you measure is never faster than the instrument. Both are approximations that assume well-behaved responses.
| question | instrument |
|---|---|
| Is the SPI command right? In what order do chip-select, clock and data change? | logic analyser (many channels, long captures, decoders) |
| Is the high level high enough? Is there ringing, overshoot, a slow edge, noise? | oscilloscope |
| Why does the receiver sometimes see an extra edge? | both: the scope for the shape, the analyser to catch when |
STEP 4
Worked example: capturing a UART and a glitch
A 115 200-baud UART is captured at 1 MHz.
The sample point can be up to 1 µs from the bit centre, about 11 % of the 8.68 µs bit: the decoder works, but with little margin for a baud-rate mismatch. At 10 MHz, 87 samples per bit leave that error at about 1 %.
The same capture is useless for a 200 ns glitch on the reset line: at 1 MHz, samples are 1 µs apart, and in most runs no sample lands inside it. At 25 MHz (40 ns period) the glitch spans five samples and is seen every time. On a 100 MHz scope, whose rise time is about 3.5 ns, the glitch’s shape and height are visible too.
MYTHS AND FACTS
Common misconceptions
The logic analyser shows exactly when edges happen
Only to within one sample period.
If the analyser shows no glitch, there was none
A pulse shorter than a sample period can fall between samples.
A 100 MHz scope is fine for 100 MHz signals
Its rise time is about 3.5 ns; it shows a 100 MHz square wave as roughly a sine, and it slows any edge near that speed.
Ringing on the screen is ringing on the board
A long ground lead can create it.
Check yourself
Answer in your head, then open the card.
A 1.9 µs pulse is captured at 4 MHz. What widths can the analyser report?
The sample period is 0.25 µs and the pulse spans 7.6 periods, so 7 or 8 samples land inside it: 1.75 µs or 2.0 µs, depending on where the samples fall. (A pulse of exactly 8 periods always contains exactly 8 samples.)
What sample rate gives at least 10 samples per bit for a 1 Mbaud UART?
At least 10 MHz; 16 MHz or more leaves margin.
An edge with a real rise time of 2 ns is measured on a 200 MHz scope. Roughly what is displayed?
Scope rise time 0.35 / 200 MHz = 1.75 ns; displayed ≈ √(2² + 1.75²) ≈ 2.7 ns, about a third slower than reality.
The analyser shows clean SPI bytes, but the device still misreads them. What do you use next, and what do you look for?
An oscilloscope on the clock and data lines at the device: slow or ringing edges, levels near the thresholds, or a double-counted clock edge that the analyser's single threshold hid.
Sources (3)
- sigrok, libsigrokdecode, decoders/uart/pd.py — bit_width = samplerate / baudrate (samples per bit); get_sample_point places each bit’s sample point at a percentage of the bit width, 50 % by default, counted from the detected start edge
- sigrok, libsigrokdecode, decoders/spi/pd.py — the SPI decoder samples MOSI and MISO on the rising or falling clock edge selected by CPOL and CPHA, so the capture only has to resolve the order of clock and data edges
- sigrok, sigrok-firmware-fx2lafw, README — open firmware for the many low-cost USB logic analysers built around the Cypress EZ-USB FX2(LP) chip, used with the sigrok software suite