I got me a really cheap 8 Channel Logic Analyzer from Aliexpress, and I like it.

The only thing I had to do to make it work with PulseViewon FC39 was installing the sigrok-firmware-fx2lafw-0.1.7-9.fc39.noarch package, and that was about it.

Simply set it up as fx2lafw (generic driver for FX2 based LAs) (fx2lafw) in PulseView and off you go.

Let’s do some simple measurements using my Flipper zero and the “GPIO Sentry Safe” application. Setup:

LA     FZ
GND -- GND
CH1 -- C!

Flipper Zero Action Shot

Setting up the capture frequency as such:

  • Sampling frequency: 1 MHz
  • Number of samples: 10 M samples

It turns out that this device is much more capable than my OpenBench Logic Sniffer! The sample depth is much better!

How I decoded the dang thing:

Pick one single bit, not a combination of rising/falling edge, as such:

PulseView single bit

Note the frequency calcuated; it shows ‘4.808 kHz’ - this can be directly interpreted as Baud, and 4800 Baud sounds sensible.

Now add a UART protocol decoder, click on the new UART line in the pulse view, and set:

  • RX: Channel D0
  • Baud rate: 4800

Magic!

Decoded UART

Comparing this to the source code of the Flipper Zero Application (FAP):

                        } else if(sentry_state->status == 0) {
                            sentry_state->status = 1;

                            reset_code(1, 2, 3, 4, 5);
                            furi_delay_ms(500);
                            try_code(1, 2, 3, 4, 5);

                            sentry_state->status = 2;
                        }

So it does…

  1. Use reset_code(1, 2, 3, 4, 5);
  2. Wait for 500 ms
  3. Use try_code(1, 2, 3, 4, 5);

`reset_code() does:

  1. send_request(0x75, a, b, c, d, e);, so I am expecting 0x75 0x01 0x02 0x03 0x04 0x05 being sent; it does, but another number, 0x84, is being added. Further inspecting send_request() reveals that it calculates a checksum, which is simply the sum of the commadn 0x75 and all parameters being send. The sum is simply 0x84 - which matched!
  2. Inspecting the break between two pulse, in my sample it’s not 500ms, but 583 ms. But anyway.
  3. try_code() works the same; what’s sent is 0x71 0x01 0x02 0x03 0x04 0x05 0x80 with the last octect being the checksum again - which matches.

OK, every command sequence always has a leading 0x00. Sourcecode of send_request() agrees:

    uint8_t data[8] = {0x0, command, a, b, c, d, e, checksum};

I also find:

    furi_delay_ms(100);

So that’s why the 500 ms break is a little longer than expected. W00t!

Addendum: I tried a few more things. Trigger type ‘falling edge’ works like charm. Also the sample buffer is really great, but I kind of question the claimed 24 MHz sampling rate. At this rate UART frames do not seem to be properly decoded any more, but I don’t know if this is related to the device or PulseView itself.