Decode a real protocol

Goal

Capture a fixed-code device you own, let the Flipper recognise and name its protocol, and save the capture with a clear name. By the end you'll have one real .sub file on your SD card and you'll understand every line inside it.

A fixed-code device sends the same message every single time you press the button. That makes it the perfect first target: predictable, easy to recognise, and safe to practise on. Rolling codes — the ones that change on every press — are Module 5's problem. Today we stay in the friendly shallows.

From pulses to bits to meaning

Strip away the jargon and a Sub-GHz remote does something almost silly in its simplicity: it switches a little radio transmitter on and off in a fast, deliberate pattern. That's the on-off keying (OOK) you met in Module 2. A long "on" here, a short "on" there, gaps in between — a flicker of radio light, like Morse code sent far too fast for a human to follow.

The receiver's job is to measure the timing of those flickers and rebuild the pattern. The Flipper does the same. It records how long each pulse and each gap lasts, in microseconds (millionths of a second), and lines them up as a train of highs and lows:

Now the leap. A "short" pulse might mean the bit 0 and a "long" pulse the bit 1 — or the other way round, or encoded as a pair of pulses. Different manufacturers made different choices, and each of those choices is a protocol: an agreed rule for turning timing into bits. Once you know the rule, a meaningless flicker becomes a number. And that number is the whole secret the remote is shouting to its receiver.

Play with the decoder below. Feed it a pulse train and watch it become bits the way the Flipper does it — short and long widths in, ones and zeros out.

The Flipper carries a built-in library of these rules. When you capture in Sub-GHz → Read, it doesn't just log the pulses — it tries every rule it knows against them. If one fits, it prints the protocol's name and hands you the decoded key. If none fits, it stays quiet, and that silence is itself information (Module 5).

What a protocol actually contains

A decoded fixed-code message is not one lump of random bits. It has structure, and every family arranges the same three ideas a little differently:

So "the key" the Flipper shows you is really the serial and command bits packed together into one number. Press the same button twice on a fixed-code remote and you get the identical key both times — that repeatability is exactly what makes it "fixed." It's also, as we'll see in Module 5, exactly why fixed codes are easy to copy and rolling codes were invented.

Families the Flipper recognises

Momentum ships knowing dozens of fixed-code families. You don't need to memorise them, but you'll meet these names on the Read screen again and again:

Numbers vary by product; treat this as a map, not a spec sheet. The point is that "Princeton, 24 bit" is the kind of plain-English answer the Flipper gives you once it recognises the rule.

What the Read screen shows you

Open Sub-GHz → Read, hold your remote a hand-span away, and press its button. Read defaults to the most common band and preset (433.92 MHz, AM650), which is where most of the world's remotes live — you can change the frequency from within Read if Module 1 told you the remote lives elsewhere. When a known protocol comes through, the screen fills in a small dossier:

Protocol

The family name the Flipper matched, e.g. Princeton or CAME.

Key

The decoded message as a hexadecimal number — the serial and command bits together. This is the value you'll replay in Module 4.

Bit

How many bits long the message is (24, 12, 40…). A quick sanity check: it should match the family.

Fq / Mod

The frequency and modulation it decoded on — handy confirmation you were on the right settings.

Button

For some protocols, which button the bits map to. Not every family exposes this.

Anatomy of a .sub file

When you Save a capture, the Flipper writes a small plain-text file with the extension .sub onto the SD card, under the Sub-GHz folder. It's genuinely just text — you can open it on a computer in any editor. Here's a realistic decoded save for a 24-bit Princeton remote:

Filetype: Flipper SubGhz Key File
Version: 1
Frequency: 433920000
Preset: FuriHalSubGhzPresetOok650Async
Protocol: Princeton
Bit: 24
Key: 00 00 00 00 00 8C 5A 3B
TE: 400

Nine short lines, and each one is a decision the Flipper made about how to reproduce your signal. Read it top to bottom:

Filetype

Flipper SubGhz Key File — this is a decoded capture (a known protocol with a key), as opposed to a raw recording, which you'll meet in Module 5.

Version

1 — the file-format version. Lets future firmware read old files.

Frequency

433920000 — in hertz, so this is 433.92 MHz. The exact channel to transmit on.

Preset

…PresetOok650Async — the modulation and filter to use: OOK (on-off keying, i.e. AM) with the 650 kHz-wide filter. This is the AM650 preset written out in full.

Protocol

Princeton — which decoding/encoding rule turns the key back into pulses.

Bit

24 — how many bits of the key are meaningful.

Key

00 00 00 … 8C 5A 3B — the message itself, in hex. The leading zeros pad it out to a fixed width; the last few bytes carry the real value.

TE

400 — the timing element in microseconds: the base pulse width Princeton multiplies to build its short and long pulses. Get this wrong and the receiver won't understand the replay.

Notice there is no counter and nothing secret here — just enough to rebuild an identical pulse train on demand. That completeness is the whole reason a fixed code can be replayed perfectly, and the whole reason it can also be copied by anyone in range. Hold that thought; it's the hinge the next two modules turn on.

Lab

Keep this file. In Module 4 you'll transmit it back — legally, to your own device — and watch the doorbell ring or the LED flip on.

Going deeper

Check yourself

Verify the details

Read the primary sources: Flipper: reading signals and presets · Flipper: static and dynamic protocol support. Course review: 10 September 2026.