add Certus IC1/IC2/IC8 classification + merge experimental-new-pkt

FORMAT.md

@@ -178,7 +178,53 @@ Notes:
 
 ### INP: "new packet"
 
-Work in progress.
+Work in progress. Simplex-DL burst format distinct from Block1 channels, seen in captures on 1626.40-1626.52 MHz. Each burst carries a 96-bit header (three 32-bit hdr words), up to 18 data blocks of 40 bits, and a 24-bit trailer.
+
+Header variants (selected by `hdr[1][4:8]`):
+
+- `H:1` (`hdr_id in {1000, 0111}`): `[hdr0:32][hdr1:32][data:16][CRC8][tail:8]`. CRC scope = 80 bits.
+- `H:2` (`hdr_id == 0110`): `[hdr0:32][hdr1:32][CRC8][tail:24]`. CRC scope = 72 bits. Source IDs observed so far are disjoint from H:1, suggesting a distinct beam/sat role.
+- `H:0`: any other `hdr_id`, layout not yet resolved.
+
+Types v1/v2/v3 depend on which CRC variant validates; see `IridiumNPMessage` for the exact logic.
+
+#### source_id split heuristic
+
+The `:NNNNN` value after the frame header is a 14-bit `source_id` extracted from `s2s[0][10:24]`. In our captures it partitions cleanly as `[sv_id:8][beam_id:6]`, i.e. `sv_id = source_id >> 6` and `beam_id = source_id & 0x3f`. This split is heuristic and not universally validated - some `hdr[0]` values span many sv_ids - so the fields are printed with a `?` marker:
+
+    INP: ... :04294 sv?:067 bm?:06 H:2 T:0 h<...>
+
+Consumers should treat `sv?` / `bm?` as best-effort interpretation, not authoritative decode.
+
+### IC1 / IC2 / IC8: Iridium Certus (NEXT / EBBS) traffic bursts
+
+Recognizer for Iridium NEXT Certus traffic channel bursts carrying user voice or IP data. Same 0x789 unique word as Block1 channels, but the rest of the waveform uses coherent QPSK (or 16APSK) with Turbo FEC instead of DEQPSK with BCH. The Block1-oriented demod pipeline emits differentially-decoded bits that are not directly meaningful for these bursts, so we classify them by symbol count alone and expose the raw (wrongly-decoded) bits for diagnostic purposes.
+
+Symbol counts and modulations consistent with publicly documented Certus bearers:
+
+| Tag | Symbol count | Modulation | Code | Payload bits |
+|---|---|---|---|---|
+| `IC1` | 200 | QPSK 4/5 | Turbo rate 4/5 | 320 |
+| `IC2` | 432 | QPSK 2/3 | Turbo rate 2/3 | 576 |
+| `IC8` | 1824 | QPSK 2/3 or 16APSK 2/3 | Turbo rate 2/3 | 2432 or 4848 |
+
+Example:
+
+    IC2: [...] 432 DL raw:0011001111110011 0011001101100011 [...]
+
+Column|Content|Example|Comment
+--:|-|-|-
+8|Length in symbols|432|200 for C1, 432 for C2, 1824 for C8
+9|Direction|DL|Certus L-band simplex downlink (1626.1-1626.5 MHz)
+10|raw:|raw:\<all bits\>|Raw demod output - NOT directly decodable in this form
+
+Notes and caveats:
+
+1. These bits are not the payload. The gr-iridium demodulator applies differential decoding unconditionally. That is correct for Block1 DEQPSK but wrong for coherent-QPSK Certus. Proper decoding requires a gr-iridium patch to expose the coherent-QPSK symbols before differential decode, followed by the Iridium-specific Turbo decoder and interleaver.
+2. Interleaver not public. The Iridium-NEXT-specific interleaver and puncturing patterns are not publicly documented; without them, Turbo decoding will not recover user data even with the correct bits.
+3. The recognizer only covers NEXT traffic (C1/C2/C8). DBCCH and other new broadcast channels are not currently detected.
+4. The current recognizer does not distinguish 16APSK-modulated C8 bursts from QPSK-modulated variants - both produce the same per-symbol count in the demod output.
+5. The paper "Systematic Security Analysis of the Iridium Satellite Radio Link" (Jedermann et al., USENIX Security 2026, arXiv:2603.12062) covers the Iridium radio link in depth and is a recommended follow-up reference.
 
 ### IBC: Broadcast