I Just Bought a Logic Analyzer for $60. Here's How to Actually Use It.

I plugged in the Innomaker and opened PulseView. Nothing happened for 5 minutes because of a missing USB driver. That's the real beginning of this story. I'd spent 3 weeks trying to debug an I2C sensor that kept dropping out. My Hantek USB scope showed me noise, my Arduino Serial Monitor showed me error codes, but nothing told me what was actually happening on the I2C bus. Someone on r/electronics mentioned the Innomaker LA1010 and said "for $60 you can't beat it." I ordered it skeptically. When it arrived, the box contained the analyzer itself (a small plastic device the size of a deck of cards), a USB cable, 10 pre-attached test probes with clips, and a quickstart that pointed me to PulseView instead of the bundled KingstVIS software. Good advice. The LA1010 itself is 10 channels of pure digital capture at 100 Msps (megasamples per second) up to 50 MHz. The 10 Mb buffer is deep enough to hold seconds of typical protocol traffic. It works on 3.3V and 5V logic without configuration. No external power supply needed—the USB cable powers it. The probes are grab-and-go clips. They have alligator ground connectors and come pre-numbered 0–9 on the cable labels. This numbering matters. PulseView will ask "which channel are you measuring?" and you need to match the probe label to your setup.

Skip the KingstVIS software that ships with the LA1010. KingstVIS is functional but outdated, and its protocol decoders are weak. PulseView is open-source, maintained by the community, and has protocol decoders you'll actually trust. On macOS, download PulseView 0.42 or later from sigrok.org. On Windows, grab the installer. On Linux, your package manager probably has it. Install it normally. Plug the Innomaker in via USB. Open PulseView. Click the Device dropdown at the top left. You should see "Saleae Logic (generic)" or "FX2 device." If you see nothing, your USB driver is missing. This happened to me on Windows. The fix: download the Zadig tool from zadig.akeo.ie, select the Innomaker in the list, and install the WinUSB driver. It takes 30 seconds. After that, replug the device and PulseView will see it. Once PulseView detects the device, click the Channels button (or press C). You'll see a list of 16 channels. The LA1010 exposes 10 active channels (0–9 are the ones wired to your probes). Disable channels 10–15. This saves memory and makes the display cleaner. Left-click on Channel 0 and verify the voltage setting. For Arduino work, set it to 3.3V/5V auto-detect or lock it to 5V. The threshold matters here—PulseView uses this to decide if a signal is "high" or "low." For 5V logic, a threshold around 2.5V is standard. Done. You're ready to capture.

This is where I made my first mistake. I clipped Channel 0 to the SPI clock line and Channel 1 to MOSI (data out) and started a capture. The decode garbage. Reason: no ground reference. The probes need a common ground. Your Innomaker needs to share ground with the circuit you're measuring. If you don't connect grounds, PulseView sees floating noise and interprets it as random 1s and 0s. Fix: clip the alligator ground connector (the black wire at the bottom of each probe) to your circuit's ground rail. On an Arduino breadboard, that's usually the negative rail. All 10 probes can share the same ground point. Use a single clip or solder a wire to a PCB test point. The probes just need low-impedance return path to your device's ground. Once ground is solid, the next mistake is channel numbering. The probe labels go 0–9. These match exactly to PulseView's channel list. Probe labeled "0" sends to Channel 0 in software. This matters when you enable protocol decoders. If you say "I2C SCL is on Channel 0" but your clock line is plugged into the probe labeled "5," the decoder reads garbage. Before you start capturing, write down which probe number connects to which signal. Use a sticky note on your breadboard. For SPI work: Probe 0 = CLK, Probe 1 = MOSI, Probe 2 = MISO, Probe 3 = CS. For I2C: Probe 0 = SCL, Probe 1 = SDA. This simple mapping saves 30 minutes of confused debugging. The probes themselves are rated for 250 MHz bandwidth and handle 1V–5V logic. For frequencies under 10 MHz (which covers 99% of hobbyist work), these stock probes are fine. The signal integrity is clean enough. If you care about better measurement accuracy or you're working above 10 MHz, the Hantek PP-250 2-pack is a $20 upgrade that improves rise-time measurement and comes with better grounding hardware.

Here's a test scenario: an Arduino Nano talking to a cheap SD card reader via SPI. The Nano sends a READ command and expects 512 bytes back. This is a real SPI bus with clock, data-out, data-in, and chip-select. Connect Probe 0 to the CLK line on your breadboard. Connect Probe 1 to MOSI (data going from Arduino to SD card). Connect Probe 2 to MISO (data coming back). Connect Probe 3 to the CS line. Connect the ground clip to your ground rail. In PulseView, click the green "Capture" button. Nothing will happen immediately. You need to tell it what to capture. By default, PulseView is waiting for a trigger (we'll cover that next). For your first capture, disable the trigger: click the Trigger button (it looks like a flag), then set the mode to "None." Now click Capture again. PulseView will record data for about 1 second or until you click Stop. On your Arduino, run code that sends the SPI command. A simple example: digitalWrite(CS, LOW); SPI.transfer(0x00); // Send read command. Wait, your breadboard sits quiet. After 2 seconds, click Stop in PulseView. You should now see a waveform. Channels 0–3 will show digital lines (high and low, square waves, plateaus). Channel 0 (CLK) should show a repeating clock pattern. Channel 1 (MOSI) should show data bits changing with each clock pulse. Channel 2 (MISO) should show the SD card's response. Channel 3 (CS) should be a single low pulse at the start. If all four lines are flat (all high or all low), your probes aren't connected or your ground is bad. Recheck the clips and the ground connection. If the lines jitter or flicker randomly, you've got a ground loop or a floating probe. Make sure the clip is making solid contact with the signal. Wiggle it. If it stops jittering, the contact was bad. Once you see clean waveforms, you've captured real data. That's your first success.

A trigger tells PulseView "start recording when you see this event." Without a trigger, PulseView records continuously and you get a random snapshot. With a good trigger, you capture the exact moment something goes wrong. Click the Trigger button. You'll see options for Trigger Type. The default is "None" (free-running). Change it to "Edge." When you select Edge, you'll pick a channel (say, Channel 0 for clock) and a direction (Rising = low-to-high transition, Falling = high-to-low transition). Set it to "Rising" on Channel 0. This means "PulseView, start recording the moment the clock line goes from low to high." Now click Capture and watch what happens. PulseView will wait silently. The moment your SPI clock rises (the moment the Arduino drives it high), PulseView triggers and starts buffering. You'll see data appear on screen. This is useful when you have intermittent problems. Instead of recording 5 seconds of idle silence and hunting for the bad bit, you trigger on the exact event that fails. Example: you're debugging I2C and the slave sometimes NACKs (pulls the clock low for too long). Set a trigger on SDA (data line) going low. When it misbehaves, PulseView captures it. Level triggers are similar but they care about state, not transitions. "Trigger when Channel 0 is high" will start recording and wait for the channel to stay high for a bit. Use Edge 99% of the time. Pre-trigger is critical. When you set a trigger, by default PulseView only records what happens *after* the trigger. You miss the setup. The pre-trigger buffer captures data *before* the trigger fires. This is how you see the root cause. In the Trigger dialog, look for a slider labeled "Pre-trigger." Set it to 50%. This means half your 10 Mb buffer will hold data from before the trigger, and half will hold data after. Now when the trigger fires, you see 500 ms of history leading up to the event. This is invaluable for finding why a signal failed. After your SPI test, try this: set a trigger on Channel 3 (CS) going low. Run the SPI command. PulseView will wait and then snap to the exact moment the Arduino pulls chip-select low. You'll see all the setup that led to it.

Raw waveforms are useful, but you don't want to manually count bits and decode bytes. PulseView has protocol decoders. For I2C, this is game-changing. Set up a simple I2C test: an Arduino with a temperature sensor on I2C. Connect Probe 0 to SCL (clock), Probe 1 to SDA (data). Set ground. Click Capture, set Trigger to None, run your Arduino code, wait 2 seconds, click Stop. You'll see two waveforms. SCL will pulse up and down. SDA will be mostly high but drop periodically as data bits are sent. These square waves are I2C, but they're hard to read by eye. At the bottom of the PulseView window, right-click in the empty Decoders area. Select "I2C." A dialog appears asking for the SCL channel (select 0) and the SDA channel (select 1). Click OK. PulseView will re-render the waveform. Now instead of raw clock and data, you'll see decoded I2C packets: "START", "ADDRESS 0x48 WRITE", "DATA 0xA5", "ACK", etc. Each byte is labeled with the actual value. This is what the sensor saw. Now open your Arduino code and check: does the address match what you sent? Does the data byte match what you expected? If you're reading temperature and you got back 0x42, does that make sense (probably yes, 66°F is reasonable)? The decoder shows you whether the bus is actually saying what you think. If the decode shows garbage or repeated "NACK" (negative acknowledgement), your I2C bus has a problem. Common causes: missing pull-up resistors, a slave device that's not powered, a clock line that's stuck low, or the wrong I2C address. The decoder shows you *what* is wrong (which byte failed, which ACK didn't come). Your next step is to use the oscilloscope or a multimeter to measure the rise-time and voltage levels. Protocol decoders exist for SPI, UART, CAN, 1-Wire, I2S, JTAG, SWD, and more. The setup is identical: right-click, select the decoder, assign the channels, and PulseView decodes automatically. This turns raw captures into actionable data.

Mistake #1: Using the wrong probe for the signal. I wanted to measure SPI MOSI and clipped Probe 1 to the MOSI line. But I thought "Probe 1" meant "second probe in the bundle" when actually Probe 1 is physically labeled on the cable. I then opened PulseView and told it "MOSI is on Channel 2." The decoder read channel 2 (which was actually my CS line) and showed garbage. The fix: always match probe label to channel number. Write it down. Mistake #2: Forgetting the ground connection. This is the number one rookie mistake. Everything looks like noise. You zoom in and the signal is fuzzy. You think "maybe my probes are bad" and order new ones. A month later you notice the ground clip wasn't clipped to anything. Face-palm. Always check ground first. Mistake #3: Setting the trigger on the wrong edge. I wanted to capture a read cycle from an I2C sensor. I set a trigger on SDA falling (the line going low at the start of a transmission). But the sensor sends multiple bytes, and SDA falls multiple times. PulseView triggered on the first falling edge, I saw the first byte, and thought I understood the problem. I didn't see the second byte, which was the one actually failing. The fix: understand your protocol. For I2C, trigger on START (SDA falls while SCL is high). For SPI, trigger on CS going low. For UART, trigger on the start bit. Make sure you trigger at the beginning of the *whole* transaction, not in the middle. Other common gotchas: setting the voltage threshold too low (PulseView thinks noise is data), forgetting to disable unused channels (slows down the capture), and setting pre-trigger to 0% (you see the problem *after* it's already broken, not before). Before you blame the tool, verify: ground is connected, probe labels match channel numbers, trigger is set to capture the *start* of the event, and voltage threshold is reasonable for your logic level.

After you capture data, you might be looking at 1 million bits on screen. Everything is compressed into a thin line. You need to zoom in to see the actual problem. PulseView has zoom controls at the top: + and - buttons. Click + repeatedly until you can see individual bits. Keep zooming until you see the square wave edges clearly. You can also scroll left and right across the capture. Click and drag the waveform horizontally to pan through time. If your capture is 10 seconds long and the bad bit is at the 7-second mark, you'll pan right to find it. For I2C, after you enable the I2C decoder, the decoded text ("START", "ADDRESS", "ACK", etc.) appears as annotations above the waveform. Click on an annotation to jump to that part of the capture. This is super useful. If the decoder says the third byte is garbage, click that annotation and PulseView zooms to exactly that byte. Once you see the bad bit clearly, measure it. Does the clock line stay high long enough? Is the data line actually changing? Look at the timing. A bus that's supposed to run at 100 kHz (10 µs per cycle) but is actually running at 50 kHz tells you something is pulling lines down too hard or the pull-up resistors are too large. Use the measure tool: right-click on the waveform and select "Measure." You can now click two points in time and PulseView shows you the time delta. This tells you how long a pulse is, how long data is stable, etc. Real numbers lead to real solutions.

After you capture and decode data, save it. File > Export as VCD (Value Change Dump). This saves the binary capture to disk. VCD is a standard format—most oscilloscopes and analyzers can read it. You can reload it into PulseView months later and remember exactly what you saw. Build a reference library. Capture "good" I2C traffic (when your sensor works correctly). Save it as "sensor-working-2026-02-20.vcd". Capture "bad" I2C traffic (when the sensor fails). Save it as "sensor-broken-2026-02-20.vcd". Now you have two captures to compare side by side. Open both in separate PulseView windows. Side-by-side comparison is powerful. Scroll through the working capture and note what the good waveform looks like: clock rising time, data setup and hold time, ACK timing. Then look at the broken capture. "Aha, the ACK comes 2 µs too late" or "the clock is stuck low." The comparison shows you what changed. After you fix the problem (new pull-up resistor, different I2C address), capture the same scenario again. Compare your new capture to the reference. Did the clock rise-time improve? Did the ACK come on time? The before/after comparison validates your fix. Save these captures in a project folder: debug-logs/i2c-sensor-issue/. Include notes: the date, the code version, the problem you were investigating, and the fix you applied. Six months from now when you hit the same issue on a different project, you'll flip through your old captures and think "oh, it's the pull-up resistor again." You've built an institutional memory of your debugging.

You captured something but the decode shows garbage or the waveform looks wrong. Don't panic. Walk through these three steps. Step 1: Check the physical connection. Unplug the Innomaker from USB and plug it back in. Wiggle every probe clip. Make sure the ground clip is making solid contact (a loose ground causes floating noise). Start a new capture. If the jitter disappears, the connection was the problem. Step 2: Verify the channel assignment. Open your code or your breadboard notes. Which signal did you clip to which probe? Now look at PulseView's channel labels. Do they match? If you clipped the clock line to "Probe 0" but told PulseView "clock is on Channel 2," the decoder is reading the wrong signal. Reassign channels in PulseView (click the Channels button, enable/disable the right ones) and try again. Step 3: Check the voltage threshold. Click the Channels button. For each active channel, look at the Threshold setting. For 5V logic, the threshold should be around 2.5V (the midpoint between 0V and 5V). For 3.3V logic, use 1.65V. If the threshold is set to 0.5V, PulseView might see noise as data. Adjust it and capture again. You should see cleaner waveforms. If the waveform still looks wrong, measure it with another tool. Plug an oscilloscope into the same signal and see if it shows similar behavior. If the oscilloscope shows a clean signal but the logic analyzer shows garbage, the problem is likely ground loop or EMI (electromagnetic interference). Move the ground clip or shield the probe cable. If both tools show weird behavior, the circuit itself has a problem. Go back to your code and hardware. Are you toggling the right GPIO pin? Is the pull-up resistor the right value? Is the slave device powered? The tool isn't lying—your circuit is. Most "the capture looks wrong" situations are actually "I forgot to connect ground" or "I told the software the wrong channel." These three steps fix 90% of issues in 5 minutes.