Capture RF samples of the 868.35 MHz nRF905 link

[andy778]

Why

The inner/outer units talk over an nRF905 GFSK link at 868.35 MHz. We need raw IQ captures to (a) confirm the air parameters (data rate, address, CRC, payload length) and (b) validate the rtl_433 decoder skeleton on stream/rtl433.

What to do (needs an RTL-SDR or HackRF near the unit)

# raw IQ + auto-detected pulse data, tuned to the link
rtl_433 -f 868.35M -s 1024k -S all

This writes g*.cu8 capture files. Capture during several different device states (idle, pump/aerator active, an alarm if you can trigger one) and note the wall-clock time of each event — that timing log is what later lets us map payload bytes to readings.

Then load a .cu8 in Universal Radio Hacker (URH) to read off: modulation (expect GFSK), data rate (50 vs 100 kbps), preamble, address bytes, payload length, CRC.

Deliverable

• A handful of .cu8 captures + a short text log of what the unit was doing at each timestamp. Share them (attach here or drop in a captures/ dir).

Blocks: finishing the rtl_433 decoder; validating any radio-config findings from firmware.

[andy778]

Status update

The core goal — capturing the link and reading off the air parameters — is largely done. Full analysis is in docs/rtl433.md (§0/§0a) and the decoder skeleton in tools/rtl433/uponor_clean1.c, merged in #59.

Done

• Captured the 868.35 MHz link with an RTL-SDR across multiple sessions (a 21.6-min run at 250 kS/s, then a 5-min run at 1.024 MS/s off-center + high gain).
• Air parameters confirmed (this is what the issue asked for):
  • Modulation: FSK/GFSK, deviation ~±38 kHz.
  • Line rate: 100 kbps (not the nRF905-default 50).
  • Payload is software Manchester-encoded (~3–4 % illegal pairs vs ~50 % for random NRZ), i.e. ~50 kbps of data, ~40 bytes/packet. The 8051 does the Manchester in software; the radio PHY is NRZ.
  • Cadence: one event every ~62 s; each event is a two-packet exchange (~6.2 ms packet → ~19 ms gap → ~6.6 ms packet) with very different RSSI = near/far units answering each other.
  • Framing: ababab sync run, then a constant fd 7a … 83 header/address region; payloads are near-static (~38 bytes byte-identical across consecutive events, only the tail moves).
• Decoder demodulates and Manchester-decodes cleanly (FSK_MC_ZEROBIT); two reference frames are recorded as a diff target (§0c).
• Cross-checked against the MC9S08 firmware (Document firmware analysis findings (Path B) #49, Add reproducible Ghidra analysis tooling #50): the on-air framing is entirely the 8051's doing and not in the CPU flash, so the PHY had to come from captures — which it now has.

Not done (URH step was superseded — analysis was done in numpy + rtl_433 -A instead, which got us further)

Definition of Done — to close this issue

1. Capture artifacts checked in / attached. The .cu8 captures currently live outside the repo. Attach a representative capture here (or the shifted/decoded slice) plus the timestamped event log, so the results are reproducible. (Note: the large raw .cu8 files should NOT be committed to the repo — attach to the issue or link, and keep only a small documented slice if needed.)
2. CRC resolved — confirm nRF905 CRC mode (0/8/16) and its byte position in the frame. Still open ([U4]).
3. Exact byte alignment of address vs payload past the fd7a…83 region ([U2]/[U3]/[U5]).
4. Display-correlated capture — the last real blocker: change the water level / force an alarm on the unit and record which decoded tail byte moves, binding payload bytes → physical readings ([U6]). The firmware gives us what the codes mean (alarm-code + setpoint tables, §0b) once we find their positions.

Items 2–4 are the remaining telemetry-mapping work. If we'd rather scope this issue to "capture + air-parameter characterisation" (items 1 only), that part is effectively complete and the byte-mapping (2–4) could move to a dedicated follow-up issue.

[andy778]

Status update (2026-07-12)

Items 2–3 from the Definition of Done above are now resolved (were still open as of the last comment):

• CRC (item 2) — done. CRC-16/CCITT-FALSE, poly 0x1021, init 0xFFFF, big-endian trailer, over address + payload. Confirmed on-air (verified live by the rtl_433 decoder's CRC gate). See docs/ghidra/README.md.
• Byte alignment (item 3) — done. Full 32-byte payload map recovered from the MC9S08 firmware's own serializer (FUN_ce01): header/length, constant tag, direction byte, two 3-byte node IDs (poll/ack cookie), message length N, N-byte body, and a stale-buffer tail that is NOT data. Same doc, byte map table.
• Item 4 (display-correlated capture) — 4/5 done. A boot-burst capture (power-cycle the outer unit) caught 4 of the 5 alarm types on air (status/chemical_low/high_water/sludge_reminder), all state=0, matching the firmware-predicted type→panel-symbol mapping exactly. device_fault (0x26) is firmware-confirmed but has never actually gone out over the air with state=1 — nobody has forced a real fault condition and captured it.
• Item 1 (capture artifacts checked in) — still not done. No .cu8/.json capture has ever landed in this repo; findings are documented in docs/radio-capture-log.md but the underlying capture files aren't archived anywhere in-repo.

Remaining to close this issue

1. Archive a small representative capture (or the decoded JSON slice) in the repo, per the note above about not committing large raw .cu8 files.
2. Trigger and capture a real device_fault (0x26, state=1) frame — the last unconfirmed alarm type.

Given how much has landed since this was opened, I'd suggest closing this issue and moving the two remaining items to a dedicated follow-up ("archive a sample capture + catch device_fault live").