Logic analyzer decoder: UART, I2C, SPI and 1-Wire
Drop a CSV or VCD capture of digital lines and read the protocol out of it - serial text, I2C transactions, SPI words, or 1-Wire bytes.
Open in ctfpalA hardware challenge often hands over a capture rather than a file: a few hundred thousand samples of two or three wires, exported from a Saleae or PulseView as CSV, or dumped from a simulation as VCD. The flag is in there, one bit at a time, and the work is deciding which protocol you are looking at and then reading it.
Working out what the capture is
- One line that idles high, with pulses at a regular width - UART. The shortest pulse is one bit time, so 104us means 9600 baud and 8.7us means 115200.
- One line with a low pulse of 480us or more - 1-Wire. That long low is a reset, and whether anything pulls the line back down afterwards tells you if a device is even present.
- Two lines where one changes while the other is high - I2C. That is a start or stop condition, and it is the one thing that may not happen during data, which is exactly why it works as framing.
- Three or four lines, one of them a regular clock - SPI. The extra line is chip select, and without it there is no framing at all.
The decoder here runs that check itself when a capture is loaded and preselects a protocol and the channel roles - with the reason it picked them shown next to it, so a wrong guess is obvious rather than mysterious.
The settings that actually go wrong
Baud rate is auto-detected from the shortest pulse and snapped to a standard rate only when it is within 5%. That matters: a bit-banged MIDI link at 31250 baud is genuinely not a standard rate, and snapping it to 38400 would produce a confident page of garbage instead of the text.
SPI mode is CPOL and CPHA together, and the failure is asymmetric. Getting CPOL wrong often costs nothing, because a data line held for the whole clock period reads the same on either edge. Getting CPHA wrong moves the sampling point half a period onto data that is changing, and the output is nonsense. If three of the four modes look identical and one does not, the odd one out is not the right one.
Inverted signalling turns up whenever the capture was taken on the wrong side of a level shifter or straight off an RS-232 line. A UART decode that produces bytes but no readable text is worth one click of the invert box before anything else.
What the errors mean
Every decoder here reports what it could not decode alongside what it could, because in a hardware challenge that is usually the interesting half. A framing error says the bit rate is slightly off or the capture is truncated. An unacknowledged I2C address says nothing is at that address - which is itself the answer to "which of these devices exists". A word cut short by chip select says the transfer really was interrupted, as opposed to your capture simply ending.