Flipper .sub and .ir decoder: RF and infrared captures

A Flipper Zero capture is a text file with a key: value header and, usually, a list of pulse durations in microseconds. .sub files hold sub-GHz radio; .ir files hold infrared. Both come in two forms - raw, which is the waveform, and parsed, where the Flipper already recognised the protocol and stored the key instead.

Infrared

Nearly every consumer remote is one of four protocols, and the leader pulse identifies them before a single bit is read. A 9ms mark followed by a 4.5ms space is NEC. 4.5/4.5 is Samsung's variant of the same coding. 2.4ms then 600us is Sony SIRC. Philips RC5 has no leader at all - it is Manchester-coded throughout, at 889us per half-bit.

• NEC sends address, ~address, command, ~command. When the address bytes are not complements, that is not corruption - it is extended NEC, and the address is 16 bits.
• A 9ms/2.25ms frame with no data is a NEC repeat code. The button is being held; the address and command are in the frame before it.
• Sony SIRC transmits three times per press by design, so three identical frames are one button, not three.
• RC5 carries a toggle bit that flips on each new press. Two frames differing only in that bit are two presses of the same button - which is how you tell a held button from a repeated one.

Sub-GHz, and whether a replay will work

The common OOK protocols - Princeton/PT2262, CAME, NICE FLO, Holtek - are all the same shape: a base pulse width, bits as short-long or long-short, and a long gap between repeats. The decoder finds that base width from the data rather than trusting the header, which matters because a capture's stated preset is often wrong.

The bit count then names the protocol, and the answer to the challenge usually follows immediately. 24 bits is Princeton: a static code, identical every press, so capture-and-replay works and there is nothing to break. 66 bits is KeeLoq: a rolling code whose hopping half changes every press, so replaying the capture will be rejected and the challenge is about the cipher, not the capture.

One detail worth knowing: a remote sends its code several times per button press, separated by a long sync gap. Decoding across that gap produces one long nonsense key, so the burst is split on it first and the repeat count is reported - a capture with four identical frames is one press.