Sub‑GHz Troubleshooting: “Decode Looks Right but Replay Fails”

Getting a clean-looking decode is not the same as emitting a signal the receiver will accept. Replay failures usually come from frequency plan mismatches, timing/modulation differences, or security controls like rolling codes.

Permission-first: only test on devices you own or have explicit written authorization to assess. Many real-world Sub‑GHz systems control safety/security functions—treat them as off-limits without written scope. See Legal & Ethics.

1) Frequency plan + region gotchas

2) Modulation and timing mismatches

Some decoders output a symbolic representation that looks correct, while replay requires faithful timing, preambles, and modulation settings to match the receiver’s tolerance.

3) Rolling codes and backend validation

4) RF power, antenna, and “too close” problems

5) A repeatable validation workflow

  1. Capture 5–10 presses of a known-good lab remote, not just one event.
  2. Compare captures: if every press differs significantly, suspect rolling code (expected).
  3. Validate frequency + modulation on the receive side first (can you re-capture your own replay?).
  4. Replay at multiple distances (e.g., 0.5 m, 2 m) with a tuned antenna.
  5. Document the exact parameters used so results are reproducible later.

Validation criteria

  1. You can explain failure as either (a) plan/modulation mismatch, (b) RF/antenna environment, or (c) security control (rolling code).
  2. You can reproduce results across multiple presses/captures, not a single lucky event.
  3. You can re-capture your own replay on a second receiver (sanity check the emission path).