Samples per bit
24 MS/s is not a quality rating, it is a budget, and one division spends it. Divide the sample rate by the bit rate and you have the only number that decides whether this instrument can see your bus.
The only division that matters
Sample rate divided by bit rate. That is how many samples land inside each bit of the signal you are trying to read, and it is the number to work out before you clip anything on.
Two thresholds are worth carrying around. Below about four samples a bit the decoder is not producing a degraded version of your traffic — it is producing noise with a plausible shape. Above about eight you have more than any decoder needs, and the remaining question is whether the capture will survive the USB bus rather than whether it will decode.
What that means for the buses you actually have
| Bus | Bit period | Samples per bit | |
|---|---|---|---|
| UART, 115200 baud | 8.7 µs | 208 | comfortable |
| I²C, 100 kHz | 10 µs | 240 | comfortable |
| I²C, 400 kHz | 2.5 µs | 60 | comfortable |
| WS2812, 800 kHz | 1.25 µs | 30 | comfortable |
| SPI, 1 MHz | 1 µs | 24 | comfortable |
| SPI, 4 MHz | 250 ns | 6 | marginal |
| SPI, 8 MHz | 125 ns | 3 | do not trust it |
| QSPI flash, 40 MHz | 25 ns | 0.6 | out of reach |
The shape of that table is the honest summary of the instrument: it decodes everything a microcontroller uses to talk to the world, and it stops at the buses a microcontroller uses to talk to its own flash.
Why "twice the frequency" is the wrong rule
Nyquist gets quoted here and it is the wrong tool. Sampling at twice a frequency is enough to recover a sine wave of that frequency — it says nothing useful about locating the edge of a square wave, which is what a decoder needs.
What a decoder needs is to know which side of each clock edge every data transition fell on. With three samples per bit, an edge is placed to within a third of a bit period, and setup and hold times disappear entirely into the uncertainty. With twenty-four, an edge is placed to within four percent of a bit, which is tighter than any protocol cares about.
So the rule of thumb is four times the bit rate as a floor and eight or more to be comfortable — not twice.
The fix nobody wants to hear and everybody should take
If a bus is too fast for the instrument, slow the bus.
This sounds like a compromise and it is not. You are debugging, not
benchmarking; a sensor that works at 8 MHz works at 1 MHz, an SD card works at
400 kHz, and an I²C bus that runs at 400 kHz runs at 100 kHz. One line in
begin() buys you twenty-four times the resolution and costs you throughput you
are not using while you stare at a screen.
// For the length of the debugging session only. Put it back afterwards.
SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE0));The transaction you are trying to see is the same transaction at either speed. The one at 1 MHz is the one you can read.
When you genuinely cannot slow it down
Some buses are not yours to set — a QSPI flash link, an RGB display's pixel clock, a hardware peripheral running at a fixed rate. This instrument will not see those, no setting changes that, and the useful response is to find the part of the system you can slow down and prove the rest from there.
Very often that works: the reason a flash read fails is a chip select from a GPIO or a command written over a bus you control, and those are visible.
When it does not work
That is the signature of being in the four-to-eight samples per bit band. There is enough resolution to see the traffic and not quite enough to place every edge, so whether a frame decodes depends on where the sample grid happened to land relative to the clock. Treat a clean decode there as luck, not as proof, and halve the bus clock.
Almost always too few samples per bit. Above about 6 MHz on this instrument the decoder is sampling roughly three times per clock, so it lands on the same level repeatedly and reports it as a byte. Drop the SPI clock in your sketch for the debugging session — SPI.beginTransaction with a 1 MHz setting is enough to prove the transaction and costs nothing but throughput.
Then you were dropping samples rather than running short of them, which is the other failure and has the opposite fix. See why 24 MHz is not free — the rate you can sustain over USB and the rate you need for the bus are two different constraints, and the useful setting is the lowest rate that satisfies the second.
Then the arithmetic is not the problem and the channel assignment probably is. A decoder told the wrong two channels produces confident, wrong output with no error anywhere — see when the decode is wrong.
There is no capture memory in this thing. Every sample goes up the cable as it is taken, which makes the top of the rate list a demand rather than a setting.
Why 24 MHz is not free →Edit this page — content/books/logic-analyzer/samples-per-bit.mdx
Questions about this product
See what other owners have asked, and read their solutions.
Logic Analyzer Kit, 8-Channel 24 MHz
Loading discussions…
Discuss this article
Ask about this page. The answer stays here, on the page it belongs to, for whoever hits the same wall next.