From Logic Analyzer to PlotJuggler: Correlating Hardware Signals with Robot Logs

This site’s top bar has promoted a small USB logic analyzer alongside PlotJuggler for a while, without ever explaining why the two belong in the same sentence. This post is that explanation. The short version: robot logs tell you what the software believed happened, and a logic analyzer tells you what the hardware actually did — and the interesting bugs live in the gap between those two stories. Correlating a captured digital signal with plotted telemetry from the same moment is how you find out which story is wrong.

Two views of the same event

Consider a familiar failure: a motor, actuator or peripheral intermittently does nothing, and the logs look clean. The software issued the command — that is in the log, timestamped, plotted, undeniable. What the log cannot show is whether the signal ever left the board: whether the line toggled, whether a chip-select asserted, whether the bus carried the frame or sat idle while the driver reported success. A logic analyzer answers exactly those questions by recording the digital signals themselves. Neither view is “the truth” alone. The log is the intended behaviour; the capture is the physical behaviour; debugging is comparing them at the same moment in time.

The correlation workflow

1. Capture both sides of the event. Run the system with the logic analyzer attached to the signals under suspicion, and record the robot’s normal logs or stream for the same run. Note one unmistakable shared event — a button press, a mode change, a distinctive command — that appears in both records.
2. Review the telemetry in PlotJuggler first. Load the recording, find the failure window, and establish exactly what the software did and when, relative to that shared event. If the data is live rather than recorded, the same session can take a stream — see streaming data into PlotJuggler over WebSocket and MQTT.
3. Read the capture against the same reference point. In the analyzer’s software, locate the shared event and measure from it to the signals in question: did the line change, when, and in what order relative to the logged command?
4. Align the two timelines mentally with time offset discipline. The habit from time-offset alignment in PlotJuggler applies here in spirit: until the shared event lines up in both views, apparent delays may be clock differences rather than behaviour.
5. Draw the conclusion the evidence supports. Signal present and correct, but the log shows no response: the problem is upstream of the pin — sensing, wiring back, or software interpretation. Signal absent while the log claims action: the problem is between the software and the pin. Either way, a vague intermittent fault just became a located one.

Where derived signals help on the software side

Correlation is easier when the telemetry side shows intent crisply. If the log records a state or a flag rather than the command itself, build the comparison view in PlotJuggler: plot the command path, the reported state, and any feedback signal together, and use a Lua custom function where the quantity that matters is a combination — for example a derived “commanded but not acknowledged” condition over time. On PlotJuggler 4, Python transforms serve the same purpose. The sharper the software-side picture, the smaller the window you need to search in the hardware capture, and logic captures reward small windows.

When this workflow is worth the extra instrument

• Intermittent faults that logs alone have repeatedly failed to explain.
• Suspected wiring, level or timing problems between boards, where software evidence has already been exhausted.
• Bring-up of a new peripheral or bus, when “the driver sent it” and “the device received it” both need proving independently.
• Disagreements between teams — firmware pointing at hardware, hardware pointing at firmware — where a capture both sides can read settles the question.

And when it is not: purely algorithmic problems, planning and logic bugs, and anything fully reproducible in the recorded data alone. A logic analyzer earns its bench space on the boundary between software and hardware, which is a specific — and for robot builders, frequently visited — place.

Logs describe intentions, captures describe physics, and most hard robotics bugs are disagreements between the two. Put the records side by side, align them on an event both witnessed, and the disagreement will usually point at its own cause.