Add rtl_433 decoder (100 kbps Manchester) and firmware field analysis

[andy778]

Summary

• Add the rtl_433 decoder for the Uponor Clean 1 868 MHz inner/outer link, built from real RTL-SDR captures: 100 kbps line rate carrying software-Manchester data (raw 01->1, 10->0), ~40 bytes/packet, constant fd7a bababa 83 header, near-static telemetry sent as a two-packet exchange every ~62 s. Demods at 100 kbps, Manchester-decodes both bit phases and keeps the cleaner one, anchors on fd7a, emits header + raw payload hex. Ships disabled=1 until fields/CRC are pinned down.
• docs/rtl433.md: capture procedure, empirical results, and a firmware section. Ghidra analysis of the MC9S08 flash shows the on-air byte layout is not in the CPU — it is only an SPI slave on a custom MC9S08<->8051 message bus; the nRF9E5's 8051 owns framing/Manchester. Firmware does give the decode targets (alarm-code and setpoint tables), so field mapping ([U6]) needs a display-correlated capture.
• Add the Ghidra helper scripts used: DumpBytes, FindRefsInRange, ForceDecompile.
• .gitignore ignores *.cu8 (large IQ captures stay local).

Test plan

• Build inside an rtl_433 checkout (copy tools/rtl433/uponor_clean1.c into src/devices/, register in include/rtl_433_devices.h + src/CMakeLists.txt, cmake && make).
• Run against a capture with -R <num> (decoder is disabled by default) and confirm it emits the fd7a bababa 83 header + payload hex.
• Field semantics ([U6]) still require a display-correlated capture before enabling.

🤖 Generated with Claude Code

[andy778]

this if missing the -f parameter

[andy778]

Addressed both review comments in 6748389:

• tools/rtl433/uponor_clean1.c:64 (missing -f) — added -f 868.20M to the flex-decoder example (tune ~150 kHz low so the carrier lands off the RTL-SDR DC spike).
• tools/rtl433/uponor_clean1.c:88 (native Manchester?) — rtl_433 does have bitbuffer_manchester_decode(), and it even uses the same convention (emits the second bit of each pair, so raw 01->1 / 10->0). I deliberately kept the custom pass: the native one aborts at the first Manchester violation and decodes a single phase alignment, whereas real captures of this link carry ~3–4% illegal pairs (noise) at an unknown bit phase, so we need violation tolerance + best-of-two-phase selection. Added an inline comment explaining this.

(Note: there's a stray empty pending review on this PR from a failed reply attempt — you may want to discard it in the UI; I wasn't permitted to delete it.)

[andy778]

Improved the flex -X command based on the live capture output.

The old rtl_433 -f 868.20M -X 'n=uclean1,m=FSK_PCM,s=10,l=10,r=100' produced ~24 noise rows (len 2-72) mixed in with the real ~650-bit packets. Two changes clean this up:

• -Y minmax — selects the FSK peak detector. The default detector fragments the weaker (far-unit) packet into several short rows; with minmax, a 4-event replay of the saved capture yields 8 clean ~650-bit packets (4 events × near+far).
• bits>=400 — drops the noise rows. Real packets are ~635-654 raw bits; strays are <100 bits, so this filter removes them without touching real frames.

New command:

rtl_433 -f 868.20M -Y minmax -X 'n=uclean1,m=FSK_PCM,s=10,l=10,r=100,bits>=400'

Also documented (both in docs/rtl433.md and the decoder header) that the native decode_mc flex option does not work here — it aborts at the first Manchester violation and only tries phase 0, so these phase-offset, slightly-noisy packets collapse to empty rows. That's why the C decoder keeps its own violation-tolerant, two-phase Manchester pass.