Omit SNR/RSSI instead of publishing hardcoded 12.5/-65 when no radio data#13
Open
ACETyr wants to merge 1 commit into
Open
Conversation
…data buildPacketJSON() (the no-raw-data path) passed hardcoded 12.5f / -65 to buildPacketMessage(), so every packet published without fresh raw radio data carried fabricated SNR/RSSI indistinguishable from real readings. Measured at ~3-20% of packets per observer on the live network (sampled via the CoreScope aggregator), which silently pollutes network-wide RF analytics. buildPacketMessage() now omits the SNR/RSSI fields when passed sentinel values (<= -900); real measurements are always within sane radio ranges and format as before. Consumers see an explicit gap instead of a fabricated reading. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.
What
When the MQTT observer has no real radio measurement for a packet, omit the
SNR/RSSIfieldsinstead of publishing the hardcoded constants
12.5/-65.src/helpers/MQTTMessageBuilder.cpp:buildPacketJSON()(the no-raw-data overload) previously passed literal12.5f/-65tobuildPacketMessage()("// SNR/RSSI - using reasonable default"). It now passes sentinels.buildPacketMessage()emits theSNR/RSSIfields only when the value is real (sentinel<= -900→ omit). Real measurements are always within sane radio ranges and serialize exactly as before.
Why
buildPacketJSONFromRaw()carries the real per-packet SNR/RSSI, but the publish path falls back tobuildPacketJSON()whenever fresh raw radio data isn't available (noraw_datapassed and theglobal
_last_raw_*snapshot older than 1 s —MQTTBridge.cpp). Because the MQTT publish runs on aseparate task that drains the queue asynchronously, that 1 s window is missed often.
The result is fabricated values indistinguishable from real readings. Measured against the public
CoreScope aggregator (200-packet samples per observer): the exact
(SNR=12.5, RSSI=-65)pair appearson ~3–20% of packets for every observer running this bridge (and 0% on a non-bridge observer),
silently polluting network-wide RF analytics (
avgSnr/avgRssi//analytics/rf). Confirmedend-to-end on a controlled node by correlating the serial RX log (real radio values) to the published
MQTT JSON by packet
hash: published12.5/-65exactly where the radio reported real, differentvalues.
Omitting is honest about the gap — consumers can detect a missing field, but cannot detect a
fabricated reading.
Testing
pio run -e Heltec_v3_repeater_observer_mqtt→ SUCCESS (ESP32-S3 image built).buildPacketJSONFromRaw()(the real-data path) is unaffected.Note
This only stops the fabrication. Reducing how often the fallback fires (e.g. carrying the
per-packet SNR/RSSI into
QueuedPacketat reception so the publish path doesn't depend on the 1 s_last_raw_*window) is a separate, optional robustness improvement.