Repository navigation
bridge: a frame the receiver locked onto and lost reaches the chip - #29
Merged
Merged
Conversation
The engine sends kind 0x0A, [failure][frame...], for a frame this node's receiver locked onto and could not trust. The chip raises HeaderErr for a header it could not read, or RxDone beside CrcErr for a payload it could not, which is what lets the firmware's error paths run at all.
Byte 47, bit 0. The engine sends kind 0x0A only to a node that says so, because a bridge without that case ends its connection on a kind it does not know and the engine has no other way to tell the two apart.
A13xB0
commented
Oct 24, 2026
A13xB0
left a comment
A13xB0
left a comment
Collaborator
Author
There was a problem hiding this comment.
LGTM. The stats record grows to 48 bytes with the capability bit, and engines read it by length, so older engines are fine.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The node half of MeshBench/meshbench#757.
The engine now sends kind
0x0A,[failure][frame...], for a frame this node locked onto and lost. The bridge hands it todeliverFrameFailed, which the pinned chip model (v1.3.3) already has:HeaderErralone for a header it could not read, orRxDonebesideCrcErrwith the corrupt bytes in the buffer for a payload it could not.The radio stats record grows from 47 bytes to 48. Byte 47, bit 0 says this bridge takes
0x0A. It has to be said: today's bridge ends its connection on any kind it does not know (default: goto done), so the engine only sends0x0Ato a node that sets the bit. Every engine reads the record on length, so an older MeshBench ignores the extra byte.Until now every lost frame reached the firmware as nothing, so MeshCore's handling of
HeaderErrandCrcErrnever ran in a simulation.Checked:
simple_repeaterbuilds cleanly against MeshCoredev(07a833bb) on Linux amd64. The engine side, including the capability bit, is tested in #757 over a real bridge. Not yet run end to end in a mesh.