Open todd2982 opened 5 hours ago
You're exactly right about the behaviour - range test should be LoRa only. If this is confirmed it should be fixed as soon as possible :)
RangeTest packets are sent with 0 hops already: https://github.com/meshtastic/firmware/blob/1b99543a1558ddfeeb7e7e2c88ef905ce79b5d12/src/modules/RangeTestModule.cpp#L113
Meaning they don't get sent out again over LoRa, but you will indeed receive them via MQTT if you're connected to MQTT.
For the public MQTT server it's already filtered out: https://github.com/meshtastic/firmware/blob/1b99543a1558ddfeeb7e7e2c88ef905ce79b5d12/src/mqtt/MQTT.cpp#L557-L558
However, there are use-cases where you might want the RangeTest on a private MQTT server. E.g., if someone uses this to do a range test where the receiving device is connected via MQTT at home. Or, to monitor which node is letting the RangeTest run continuously.
Category
Other
Hardware
Heltec V3, Seeed Card Tracker T1000-E
Firmware Version
2.5.9
Description
When MQTT on both nodes with upload and download enabled, the sequence number messages are always delivered when using the range test function regardless of actual radio range. I feel this module should only use the LoRa radio for this action, and exclude MQTT.
This was found while using private MQTT server using private channel as the primary instead of the default unencrypted LongFast channel. The sending node was a Heltec V3 connected to WiFi, and the receiving node was a T1000-e using the phone proxy feature. The sequence numbers delivered without issue regardless of range even when I was well beyond the failure point of previous tests. Turning off the phone proxy of the receiving node during the test started returning normal results that would be expected if only transmitting via LoRA.
I do not have log data at this time, but can reproduce the test for log data if requested. I did not test this with the public MQTT, and wouldn't expect it to work with the zero hop configuration.
Relevant log output
No response