Why 24 MHz is not free

Where the samples go

Straight out. The device takes a sample of all eight inputs, packs it into one byte, and sends it. There is no buffer to fill and nothing to download at the end — what you see is a stream that started when you pressed the button and stops when you stop it or when something breaks.

That is unusual enough to be worth stating plainly, because it is the opposite of how a bench oscilloscope behaves and it changes what the sample rate means. On an instrument with capture memory, a higher rate costs you capture length. Here it costs you bandwidth, continuously, for as long as the capture runs.

The arithmetic

One byte per tick. At 24 MS/s that is 24 MB/s, sustained, in one direction, for the whole capture.

USB 2.0 high speed is 480 Mbit/s on paper, which sounds like plenty. What a bulk endpoint actually achieves is a good deal less, it is shared with everything on the same host controller, and the things sharing it are not incidental:

• The target board's own USB serial connection, which is usually the thing you are watching while you capture.
• Whatever else is on the hub — a webcam, a keyboard, an external drive.
• On a laptop, quite possibly all of the above through one dock.

So 24 MB/s is not half of a comfortable budget. It is most of a real one.

What it looks like when it runs out

Not an error, usually. You get a capture with a discontinuity in it, or a decoder that works for the first half and falls apart, or — in both applications — a warning you may or may not notice about samples being dropped.

The dangerous version is a decode that survives the gap. A missing microsecond in the middle of an I²C transaction can leave a shorter, entirely plausible transaction behind, and nothing marks it as fiction.

What to do about it

Pick the rate from the bus, not from the top of the list. Samples per bit tells you the lowest rate that still resolves your slowest signal. Use that one. For a 400 kHz I²C bus, 4 MS/s is ten samples a bit and a sixth of the bandwidth.

Give it a port of its own. Directly into the machine, not through the hub the target board is on. This is the single change that fixes most dropped-sample problems, and it costs nothing.

Close the serial monitor while you capture. It is a USB device streaming from the same bench, often through the same controller, and you can read what it printed afterwards.

Capture less. If you only need one transaction, you only need to run for the few milliseconds around it. A long capture is not free and is rarely necessary.

The one thing that is genuinely free

Unused channels. All eight inputs are read and sent as one byte whether or not you have anything clipped to them, so leaving six channels unconnected costs nothing at all — no bandwidth, no resolution, no accuracy.

Turn channels off in the application because eight empty rows make the two you care about harder to see. Do not turn them off expecting to buy anything back.