Download the whole package (handoff.tar.gz)

Handoff dossier — unknown 868 MHz sensor near Uster (ZH)

Purpose. Everything needed to finish reverse-engineering one specific radio transmission, without access to the receiver. Written for a stronger model (or a patient human) to pick up cold.

One-line status. Physical layer and framing are solid; the payload format is not solved. The remaining blocker is not signal quality (−18 dBFS bursts, 55 dB in-band SNR) but that the payload has been bit-identical in every frame for ≥ 20 minutes, so there is nothing varying to correlate against weather — see §6 for why that may itself be the finding.

1. What is established, with confidence

Not a battery-powered weather station reporting normally: the duty cycle is 41 % and the channel is 600 kHz outside the 868.0–868.6 sensor band. The owner says the unit is mains-wired, which removes the battery-lifetime objection to the duty cycle but not the channel or the rate.

2. Signal parameters

centre (hops)   866.71 … 867.92 MHz   (receiver reads 18.6 ppm low)
modulation      2-FSK, h ≈ 1.13, ±13 kHz deviation, constant envelope
symbol rate     ~22 973 Bd from the modulation spectrum; clock scan prefers 22 720 Bd
symbol period   43.5 µs
burst length    25.9 ms  (594 symbols)
burst period    62.77 ms, stdev < 1 ms, occasional skipped slots
duty            41 %
levels          burst −17.4 dBFS, noise −56.1 dBFS, SNR 55 dB in 46 kHz
chip family     Silicon Labs Si4x3x (sync 0x2DD4), i.e. Si443x/Si446x/Si4010 class

Exact timing, hop list and per-burst data: data/phy.json, data/frames.json, data/bitstreams.txt.

3. Frame layout (as decoded)

[ 63 × alternating 1010… ][ 0x2D 0xD4 ][ ~7 data bytes ][ alternating 1010… to end ]
                            sync word     payload            idle filler (~450 symbols)

One complete frame (t = 0.121 s, 867.54721 MHz, 593 symbols):

010101010101010101010101010101010101010101010101010101010101010 0 010110111010100 0001101010100011 …
└──────────────────── preamble, 63 symbols ──────────────────┘   └─ sync 2D D4 ─┘ └─ payload ─

Hex of the whole post-sync string, as reported by the naive splitter: 2DD41AA30918F0420 / 2DD41AA30918F04102 depending on rate.

Payload byte hypotheses are not trustworthy yet — see §6.

4. Frame structure — RESOLVED, and the payload is opaque (third pass)

Clock. A fixed samples-per-symbol grid drifts across 594 symbols; fitting one period to the alternating runs (preamble + idle, both pure 1010…) gives 43.478 µs ± 0.004 µs = 23.000 kBd. Sampling phase is then locked by matching the sync word. Decoding is now stable.

Scale. An 8-minute capture at 867.3 MHz (2.0 GB IQ, deep/long4.iq) yields 2,035 decoded frames, 1,604 byte-aligned: 976 beacons, 405 data frames. The earlier nine data frames were far too few to analyse.

Frame layout (payload begins immediately after the sync — an earlier bug had 15 bits of sync mixed into every "payload", which invalidated the first checksum tests):

2D D4 | 1A A3 09 18 | XX | 41 | 02 | <27…54 bytes>
sync     constant      ↑    ↑    ↑     data region
                    counter flag  type

Other devices. ~170 of 1,604 frames carry different prefixes (1a a3 09 41, 1a a3 09 19, 1a 31 e0 82, 1a a3 7a 82 …): several sensors share this channel and this framing.

What the data region resists — all tested, all negative

Conclusion. Framing, ID, counter and flags are understood and reproducible. The 54-byte data region is high-entropy with only faint structure — consistent with encryption or compression, not with bit-packed sensor fields. Without the vendor spec or a known-plaintext lever, black-box analysis stops here.

5. What has been tried and failed

• rtl_433, 270 s across 866.9 / 867.3 / 867.9 MHz, every decoder enabled → 0 frames. Not a tuning problem: the sync word matches, but our 43.5 µs symbols match none of the 30 decoders (they expect 26–500 µs; the weather ones want 56–58 µs).
• Payload splitting by idle-resumption → unstable length (see §4).
• Second frame type hidden in the 38 rejected bursts → ruled out. 0 of 38 contain the sync; they are bit-clock slips, not another format.
• Correlating bytes with weather → impossible so far because the payload never changes (§6).

6. The payload is frozen — and that is probably the finding

Across 293 s (1,825 bursts, 70 frames demodulated) there were 2 distinct payloads, 69 of them identical. The same string appears in the earlier 10 s capture too. Whatever the fields are, they are not updating.

For a sensor, that means either (a) the radio is transmitting a constant registration/beacon packet rather than measurements, or (b) it is sampling a dead sensor and sending a constant sentinel, or (c) it is not a sensor at all but a link/streaming device that only emits status here and sends data in a mode we have not captured.

Consequence for the next model: weather correlation needs varying payloads. Either capture over hours (temperature/humidity drift should eventually flip low-order bits) or force a change (warm the sensor, cover a solar panel, block a rain gauge).

7. Weather context (for correlation once the payload varies)

Model data, not a station reading — Uster, 2026-11-15, capture window 12:20–12:45 CET:

Current payload candidates to test against these: 2DD41AA30918F04102, 2DD41AA30918F82081, D16EA0D51848C7820. Full data: data/weather_uster.json.

Note the incidental near-misses in 1A A3 09 18 F0 41 02: 09 ≈ 9 °C, 18 = 24 (cloud %), 41 = 65. These are almost certainly coincidence at n=1 — do not build on them.

8. Candidate protocols sharing this framing

data/candidates.md lists all 30 rtl_433 decoders that key on 0xAA 0xAA 0x2D 0xD4, with their pulse widths and sources. Reading two or three of them (e.g. ambientweather_wh31e.c, bresser_5in1.c, lacrosse_tx34.c) is the fastest way to learn the field conventions used by this chip family: nibble-packed BCD, inverted bytes, one's-complement check bytes, and how they handle the 0xAA preamble. None matches our timing, but the style is likely shared.

9. Suggested next steps, in order

1. Stabilise the clock (highest value). Continuous clock recovery, or estimate the rate per burst from the idle alternation, then check whether every burst yields the same payload length. Success criterion: one length in > 95 % of bursts.
2. Capture long. Hours, not minutes, and log only decoded payloads with timestamps (cheap: no IQ storage needed). Watch for any bit flipping as the day cools.
3. Force a change if the sensor is reachable: warmth, shade, or a battery pull.
4. Test structure hypotheses on the stabilised payload: check for a CRC-8/16 over the first N bytes (try polys 0x07, 0x31, 0x1021; LSB and MSB first), a constant ID vs a changing tail, and nibble-swapped BCD against §7.
5. Identify the chirp-free stream: confirm the hopping sequence is a fixed cycle (log the channel order over hundreds of bursts and look for a period) — that alone may name the chip's FHSS demo firmware.

10. Files

README.md                     this dossier
manifest.json                 file list + sizes + sha256 prefixes
data/phy.json                 measured PHY, calibration, timing, hop set
data/frames.json              every demodulated burst: t, mhz, full bitstring
data/bitstreams.txt           same, one line per burst, tab-separated
data/weather_uster.json       weather at capture time + search targets
data/candidates.md            the 30 Silicon Labs decoders (pulse width, source file)
iq/excerpt_867.6MHz_2048k.u8  300 ms of raw IQ, interleaved uint8, contains full bursts
iq/excerpt_867.6MHz_2048k.json format and provenance for the above
code/decode.py                self-contained decoder — start here, one command
code/locked_demod.py          phase-locked decoder (the one that resolved §4)
code/checksum_pn9.py          PN9 + CRC-8/16 tests (all negative)
code/bulk_demod.py            streaming decoder for multi-GB captures
code/encoding_sweep.py        832-encoding autocorrelation sweep (§4)
data/bulk4.jsonl              2,035 frames from the 8-minute capture
data/locked_frames.json       payload bits per burst from the phase-locked decoder
code/fsk_demod.py             single-burst demodulator + plots (numpy/scipy/matplotlib)
code/clock_scan.py            the rate sweep that produced §4
code/all_frames.py            batch demodulator that produced frames.json

Reproduce from the IQ excerpt — verified working, prints 4 bursts, sync at symbol 63:

python3 code/decode.py iq/excerpt_867.6MHz_2048k.u8 867.6 22720

Output for the excerpt (post-sync bits, idle filler truncated):

  0 t=  0.064s  866.99724 MHz dur= 25.9 ms  preamble= 63  sync@63  bits=587
    post-sync: 0001101010100011000010010001100011110000010000010000001001101010…
  1 t=  0.127s  866.69756 MHz dur= 25.9 ms  preamble= 63  sync@63  bits=587
    post-sync: 0001101010100011000010010001100011110000100000100000010010101010…
  2 t=  0.190s  866.79727 MHz dur= 25.9 ms  preamble= 62  sync@62  bits=586
  3 t=  0.253s  867.79727 MHz dur= 25.9 ms  preamble= 62  sync@62  bits=586

Note bursts 0 and 1 disagree in the tail by one bit position — visible clock slip, exactly the problem described in §4. Compare at other rates (22680, 22973, 23120, 23640) and look for the rate at which all four agree.

11. Provenance

Captured 2026-11-15, ~12:15–12:45 CET, Uster/ZH area, RTL-SDR Blog V4 (R828D) via rtl-sdr 2.0.3, 2.048 MS/s, 8-bit IQ, gain 40.2 dB, stock whip indoors. Antenna gain at 868 MHz unknown, so all absolute levels carry ±10 dB of uncertainty; the frequency axis is good to ±20 ppm after calibration against ADS-B 1090.000 MHz and the 869.525 MHz SRD channel.

Package contents

Every file is listed with its size and SHA-256 prefix. The tarball above contains all of them.