For years I debugged digital buses the way you debug anything you can't see: by guessing, changing one thing, and guessing again. A sensor wasn't responding over I2C, and I'd spent the better part of an evening rewriting the driver, re-checking the address, swapping the breadboard wires, and getting nowhere. The thing I should have done first was look at the wire. I finally bought a logic analyser, and the bug fell out in about ninety seconds.
The unit was one of the cheap eight-channel clones based on the Cypress FX2 chip, the ones that turn up for around twelve quid. I'd avoided them for years on the assumption that something that cheap couldn't be useful. That was wrong. With sigrok and PulseView driving it, it does exactly what an analyser ten times the price does for the kind of low-speed work I'm doing: capture the edges, decode the protocol, show you the truth.
the actual problem
Here's what I'd been failing to see. My code was talking to a sensor at what I believed was address 0x76. The datasheet said 0x76. I'd checked it five times. What I hadn't accounted for was that this particular board tied the address-select pin high, which moved the device to 0x77. No amount of staring at my own code was going to reveal that, because my code was correct for the assumption it was built on. The assumption was the bug.
The first capture made it obvious. PulseView's I2C decoder turns the two squiggly lines into something readable: a start condition, the address byte, the read/write bit, and then either an ACK or a NAK. My capture showed the controller sending 0x76, the write bit, and then a NAK. Nobody home at that address. The bus was working perfectly. It was politely telling me, on every single transaction, that I was knocking on the wrong door, and I'd never heard it because I'd never listened.
I changed the address to 0x77, captured again, and there it was: address byte, ACK, the register pointer, a repeated start, and a stream of data bytes coming back. The sensor had been sat there ready the whole time.
why protocol decode is the whole game
A logic analyser captures voltage over time, that's all. The raw view is a row of square waves per channel, and for a serial bus that's nearly useless to read by eye. You can do it, counting bits against the clock like some kind of penance, but you won't enjoy it and you'll make mistakes. The thing that makes a cheap analyser genuinely transformative is the protocol decoders.
sigrok ships decoders for a long list of protocols: I2C, SPI, UART, 1-Wire, plenty more. You tell it which channels carry clock and data, which bus you're looking at, and it overlays the decoded meaning right on top of the waveform. Suddenly you're not reading voltages, you're reading "START, 0x77, R, ACK, 0xD0, ...". You can even stack decoders, so a raw I2C layer feeds a higher-level decoder that knows your specific chip's register map and shows you register names instead of hex.
That's the bit that changes how you work. Once you can see the bus, a whole category of bug becomes trivial. Wrong address, wrong byte order, a clock that's too fast for the device, a pull-up that's missing so the line never properly reaches a logic high, a device that's NAKing because it's still busy from the last command. All of these look identical from inside your code, which is to say they look like "it doesn't work". On the wire they each have a distinct, obvious signature.
a few things worth knowing
The cheap FX2 units have real limits and it's worth being honest about them. Sample rate tops out around 24MHz on most clones, which is fine for I2C and standard UART and basic SPI, but not for anything fast. The input threshold is fixed at standard logic levels, so 3.3V and 5V signals are fine but you're out of luck on lower-voltage rails without a level shifter. And there's no analogue capture at all, so you can't see a marginal edge or a noisy line, only whether the firmware decided it was a one or a zero. For seeing why a signal is bad rather than just that it's wrong, you still want a scope.
But for "what is actually being sent on this bus", which is the question I have ninety percent of the time, the cheap analyser answers it completely. Get the FX2-based hardware, install sigrok and PulseView, and learn to wire the probes onto clock and data. The grounds matter: tie the analyser's ground to the circuit's ground or you'll capture noise.
The real lesson is older than the tool. When something digital won't talk, stop debugging the code and look at the wire. The wire doesn't lie, doesn't have a bug in its assumptions, and will tell you exactly what's happening the moment you give yourself a way to listen. I spent an evening rewriting a driver that was already correct. The analyser would have saved me all of it, and it cost less than the takeaway I ordered out of frustration that night.