How to Use a Logic Analyzer for Digital Signal Debugging: Saleae, Sigrok, and Protocol Decoding

An oscilloscope shows you what a signal's voltage is doing over time; a logic analyzer shows you what a bus is actually saying. For debugging I2C sensors that won't ACK, SPI transfers that return garbage, or a UART connection that just prints noise, a cheap 8-channel USB logic analyzer paired with free software will find the problem in minutes where staring at code and guessing can burn an entire evening. This guide covers picking a logic analyzer, wiring it up safely, and reading the protocol decodes that turn raw digital transitions into an actual conversation you can debug.

What a Logic Analyzer Does (and Doesn't) Show You

A logic analyzer samples one or more digital lines at high speed and records whether each is high or low at each sample point — it has no concept of analog voltage level, so it can't diagnose a signal that's marginal (say, 2.8V instead of a clean 3.3V) the way an oscilloscope can. What it's uniquely good at is capturing many channels at once and decoding them into the actual protocol traffic — I2C addresses and register writes, SPI byte transfers, UART ASCII text — which is exactly the information needed to debug a communication failure between two digital devices rather than a signal integrity problem.

Choosing a Logic Analyzer

OptionChannels/SpeedNotes Generic "CY7C68013A" clone (often sold simply as "USB Logic Analyzer")8 channels, up to ~24MHz reliableExtremely cheap and the most common entry point; works well with the free, open-source Sigrok/PulseView software and is plenty for I2C, SPI, and UART debugging at typical maker-project speeds Saleae Logic 8 / Logic Pro 88 channels (Pro adds analog channels), up to 100MHz+Commercial-grade capture reliability and a polished, well-documented decoder library; the Saleae Logic software itself is free even without owning genuine Saleae hardware, though third-party clones are not officially supported DSLogic / DSLogic Plus16 channels, higher sample depthA step up in channel count and buffer depth for more complex multi-bus captures, also Sigrok-compatible

For the vast majority of maker debugging — a stuck I2C sensor, a misbehaving SPI display, a UART that won't sync — an 8-channel sub-24MHz analyzer is more than sufficient, since these protocols typically run well under 1MHz in maker projects.

Wiring It Up Safely

• Always share ground between the logic analyzer and the circuit under test — without a common ground reference, captured signal levels are meaningless and can even read as random noise.
• Check voltage compatibility before connecting. Most inexpensive logic analyzers are 3.3V-logic inputs and are not 5V tolerant — connecting directly to a 5V Arduino bus without a level shifter or series resistor can damage the analyzer's input. Confirm the tolerance in the specific unit's documentation rather than assuming.
• Use a series resistor (a few hundred ohms to 1k) on each signal line as cheap insurance against an accidental short or voltage mismatch — it has negligible effect on capture quality at typical maker-project bus speeds.
• Tap the bus, don't insert in series — logic analyzer inputs are high-impedance and meant to listen passively; connect probe wires as a parallel tap on SDA/SCL, MOSI/MISO/SCK/CS, or TX/RX rather than breaking the circuit to route through the analyzer.

Capturing and Decoding I2C

1. Connect analyzer channels to SDA and SCL, plus ground.
2. In PulseView (Sigrok) or the Saleae Logic software, add the I2C protocol decoder and assign the correct channels.
3. Trigger the capture, then perform the action that reproduces the problem (a sensor read, an EEPROM write) on the target device.
4. Read the decoded output directly — it shows the 7-bit address, read/write bit, ACK/NACK for each byte, and the actual data bytes transferred. A NACK where an ACK is expected almost always means either the wrong address or the device isn't actually present/powered on the bus; a repeated address issue is a classic address-conflict symptom on a bus with multiple similar sensors.

Capturing and Decoding SPI

1. Connect MOSI, MISO, SCK, and CS (chip select) plus ground.
2. Add the SPI decoder and specify clock polarity/phase (CPOL/CPHA) matching what the target device expects — getting this wrong is itself a common cause of garbled SPI data, and the logic analyzer capture is exactly how you confirm which mode is actually in use.
3. Decoded output shows each byte transferred in both directions, framed by CS going active and inactive — useful for confirming a device is actually responding on MISO at all, versus a wiring fault where MISO is floating or shorted.

Capturing and Decoding UART

1. Connect TX (and RX if debugging both directions) plus ground.
2. Add the UART decoder and set baud rate, data bits, parity, and stop bits to match the expected configuration — a logic analyzer capture at the wrong assumed baud rate will decode as garbage even on a perfectly healthy signal, which is a very common false alarm.
3. Decoded output renders as readable ASCII text alongside the raw bit timing, making this the fastest way to confirm whether a "non-responsive" serial device is actually silent, or is sending data at a different baud rate than the receiving code expects.

Common Debugging Scenarios

SymptomWhat the analyzer reveals I2C sensor never detected in a bus scanConfirms whether the device even attempts to ACK its address, isolating a wiring/power problem from a software address mismatch SPI display shows garbage or nothingConfirms clock mode, byte order, and whether CS is actually toggling when the code expects it to Serial console prints mojibakeNear-always a baud rate mismatch, immediately visible once decoded at the correct rate Intermittent sensor read failuresLong captures can catch the exact moment a bus glitch, missing ACK, or clock stretch event happens, rather than relying on print-statement guesswork in code

Safety

Never connect a logic analyzer's inputs to mains-referenced or high-voltage circuitry — these are low-voltage digital instruments only, and there is no isolation protecting the analyzer (or the USB port it's plugged into) from a voltage spike beyond its rated input range. When probing an unfamiliar board, verify logic levels with a multimeter first if there's any doubt about whether a rail is 3.3V or 5V logic.

A logic analyzer turns "why isn't this sensor working" from a guessing game into a direct read of exactly what's happening on the wire, which is often the fastest debugging tool in the entire electronics toolkit once a project moves beyond blinking an LED. Paired with a multimeter for power-rail sanity checks and an oscilloscope for genuine analog signal problems, it rounds out a complete bench debugging setup for ESP32, Arduino, Flipper Zero GPIO, and PCB projects alike.