feat(firmware): opt-in CSI census and AP survey diagnostics - #1830
Open
clonea1 wants to merge 1 commit into
Open
feat(firmware): opt-in CSI census and AP survey diagnostics#1830clonea1 wants to merge 1 commit into
clonea1 wants to merge 1 commit into
Conversation
Two questions come up whenever a node underperforms and neither can be answered from the outside: what is this node actually hearing, and what does the RF around it look like. Both are answerable on the node and were not. The census counts frames per transmitter at three points -- as received, after the rate gate, and as sent -- so the drop between stages is attributable. "The node is only sending 6 fps" has very different causes depending on whether it heard 6 or heard 400 and discarded the rest. The AP survey performs one scan and logs every visible BSSID with its channel and RSSI, which answers whether a weak node is weak because of distance or because it associated with the wrong AP. Both are behind compile flags (RUVIEW_DIAG_CENSUS, RUVIEW_DIAG_SCAN) and off by default. Neither belongs in a soak or a production flash: the census logs continuously, and the scan takes the radio off its operating channel, which is a CSI outage and a chance to lose the association. The survey is additionally delayed 10 s after boot so it measures steady state rather than competing with connection setup. Co-Authored-By: claude-flow <ruv@ruv.net>
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
1 participant
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.
Two questions come up whenever a node underperforms and neither can be
answered from the outside: what is this node actually hearing, and what does
the RF around it look like. Both are answerable on the node and were not.
The census counts frames per transmitter at three points -- as received, after
the rate gate, and as sent -- so the drop between stages is attributable. "The
node is only sending 6 fps" has very different causes depending on whether it
heard 6 or heard 400 and discarded the rest.
The AP survey performs one scan and logs every visible BSSID with its channel
and RSSI, which answers whether a weak node is weak because of distance or
because it associated with the wrong AP.
Both are behind compile flags (RUVIEW_DIAG_CENSUS, RUVIEW_DIAG_SCAN) and off
by default. Neither belongs in a soak or a production flash: the census logs
continuously, and the scan takes the radio off its operating channel, which is
a CSI outage and a chance to lose the association. The survey is additionally
delayed 10 s after boot so it measures steady state rather than competing with
connection setup.
Rebased onto current
main. One conflict inmain.c, additive on both sides and resolved by keeping both. Firmware builds clean for esp32c6 on ESP-IDF v5.4.