RadioLibInterface: drop "caught missed RX_DONE" from WARN to DEBUG#10255
Open
nightjoker7 wants to merge 1 commit into
Open
RadioLibInterface: drop "caught missed RX_DONE" from WARN to DEBUG#10255nightjoker7 wants to merge 1 commit into
nightjoker7 wants to merge 1 commit into
Conversation
This log line fires in the normal recovery path for back-to-back RX events: a second packet's DIO1 edge arrives while the GPIO interrupt is still disabled from processing the previous packet (between ISR disable and handler re-enable), so no edge event queues for when we re-enable. The 1 Hz `pollMissedIrqs()` backup (added in meshtastic#9658) then sees the RX_DONE IRQ flag is set, logs this line, and kicks the handler. This is the polling safety-net working as designed — not a warning condition. On a ROUTER_LATE Station G2 in an active urban mesh, it fires ~200 times per day under sustained RX load, burying actual warnings in noise. The file already uses LOG_DEBUG for analogous "we compensated for a normal radio oddity" messages: - LOG_DEBUG("Ignore false preamble detection") (line 123) - LOG_DEBUG("Ignore false header detection") (line 130) Align this one with that convention. Also expand the message slightly so anyone still watching DEBUG logs can understand what the line means without cross-referencing meshtastic#9658. No behavior change — only log level.
3 tasks
thebentern
reviewed
Apr 23, 2026
| if (iface->checkIrq(RADIOLIB_IRQ_RX_DONE)) { | ||
| LOG_WARN("caught missed RX_DONE"); | ||
| // This is the normal recovery path for back-to-back RX events where the | ||
| // second packet's DIO1 edge happens while the GPIO interrupt was still |
Contributor
There was a problem hiding this comment.
I'm fine with the log level changes, but this comment block is a novel 😓
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
2 participants
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.
Context
PR #9658 added
pollMissedIrqs()as a 1 Hz backup to catch RX_DONE events where the GPIO edge happened while the ISR was still disabled from processing the previous packet. That's a real scenario on back-to-back receptions:disableInterrupt()pollMissedIrqs()at 1 Hz notices the RX_DONE flag is set, kicks the handler → packet B gets processedThis is the polling safety net working exactly as intended. Not a warning condition.
Problem
Current log level is
LOG_WARN:On a Station G2 running in ROUTER_LATE in an active urban mesh, this fires ~200 times per day under sustained RX load — clustered during dense-RX bursts (e.g., phone-app reconnect storms, neighbor floods). It buries actual warnings in the log.
Same pattern as PR #10252's CRC_MISMATCH fix (same file): a normal radio recovery event logged at the wrong level.
Fix
Drop to
LOG_DEBUGand expand the message so it's self-documenting at DEBUG level:Alignment with existing file conventions
This matches how
RadioLibInterface.cpplogs other "we compensated for a normal radio oddity" cases:LOG_DEBUGLOG_DEBUGLOG_WARNThe new level brings #558 into line with the other two.
Risk
Minimal — log level only, no behavior change. Identical commit pattern to the CRC_MISMATCH drop in #10252.
Observation data
On my Station G2 fleet over 24 hours, captured:
Clustered at high-stress periods:
In every case the poll successfully recovered the missed IRQ and the packet was processed normally. Zero observed lost packets attributable to missed RX_DONE — the backup poll is doing its job, it just shouldn't be shouting while it does.