Jonathan BennettandClaude Opus 5 08e5811deb Don't let a stale HEADER_ERR re-arm RX over a live frame
Before: a header that fails on noise, a collision or a foreign frame
latches HEADER_ERR and no RX_DONE follows it. `checkStaleRxFlags()`
counts HEADER_VALID and HEADER_ERR as one boolean, so the error starts
the max-packet window that re-arms RX. A good frame arriving inside that
window raises HEADER_VALID beside the error, which does not restart the
window - a header was already up. One max packet after the error was
first seen, the poll re-arms, and `startReceive()`'s standby aborts the
frame still on the air.

After: the window is timed from the valid header alone. A HEADER_ERR
beside a HEADER_VALID is retired at once and decides nothing, because one
header raises one flag or the other (SX1262 DS rev 2.1 table 13-29), so
the two together are two frames and the error is the older one.

A lone stale HEADER_ERR past its window is now cleared rather than
re-armed on every chip but SX128x. The re-arm exists for the SX1280 wedge
of DS rev 3.3 16.2, which a clear does not unwedge; on SX126x, LR11x0 and
LR20x0 the demodulator is already hunting for a preamble again, and a
clear never aborts a frame that may be in one. `headerErrWedgesRx()` is
the per-chip hook, true only on SX128x. SX126x already clears HEADER_ERR
unconditionally in `resumeRunningReceive()` for the same reason.

The busy decision is unaffected: `receiveDetected()` reads only
HEADER_VALID and PREAMBLE_DETECTED, so the cost of the bug was a dropped
reception, never a talk-over.

How: `staleRxFlagAction()` takes HEADER_VALID and HEADER_ERR separately
plus the per-chip wedge flag, and gains a ClearHeaderErr verdict.
`checkStaleRxFlags()` keeps a second stamp bit for "the window was
started by a valid header", so a valid header restarts a failed one's
window the way develop already has a header restart a bare preamble's.
Five native cases cover it, two of them the regression itself.

Found and analysed by Tom (NomDeTom), who also wrote the commit the
behaviour came from, 45262f825 in #11137.

Claude-Session: https://claude.ai/code/session_01DLRPmdJQTu6MDG7o2QLceR

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
2026-10-12 23:48:49 +00:00
2026-10-02 11:59:23 +00:00
2021-10-09 17:15:12 +11:00
2024-09-24 15:24:08 -05:00
2026-10-03 21:22:22 +02:00
2026-07-01 19:01:27 -05:00
2026-01-29 10:06:58 -06:00
2024-11-28 06:26:51 -06:00
2024-09-04 15:33:28 -07:00
2026-01-29 10:06:58 -06:00
2026-01-29 10:06:58 -06:00
2026-10-03 22:43:30 +00:00
2025-01-13 12:24:05 +08:00
2026-01-29 10:06:58 -06:00

Meshtastic Logo

Meshtastic Firmware

GitHub release downloads CI CLA assistant Fiscal Contributors Vercel MemBrowse

meshtastic%2Ffirmware | Trendshift

Overview

This repository contains the official device firmware for Meshtastic, an open-source LoRa mesh networking project designed for long-range, low-power communication without relying on internet or cellular infrastructure. The firmware supports various hardware platforms, including ESP32, nRF52, RP2040/RP2350, and Linux-based devices.

Meshtastic enables text messaging, location sharing, and telemetry over a decentralized mesh network, making it ideal for outdoor adventures, emergency preparedness, and remote operations.

Get Started

Join our community and help improve Meshtastic! 🚀

Stats

Alt

S
Description
No description provided
Readme GPL-3.0
317 MiB
0 Stars 1 Watchers 0 Forks
Languages
C++ 73.6%
C 21.7%
Python 2.6%
Shell 1.5%
Batchfile 0.2%
Other 0.2%