[Feature Request / Bug] int.thresh is hardcoded to 0 in Companion firmware— expose _prefs.interference_threshold

[jirogit]

Summary

In Companion firmware, getInterferenceThreshold() unconditionally returns 0, ignoring _prefs.interference_threshold entirely. As a result, RSSI-based carrier sensing (LBT: Listen Bore Transmission) is effectively disabled on Companion nodes, with no way for users to enable it — even though the preference field exists in NodePrefs and set int.thresh is fully functional on Repeater and Room Server firmware.

Root Cause

In examples/companion_radio/MyMesh.cpp:

int MyMesh::getInterferenceThreshold() const {
return 0; // disabled for now, until currentRSSI() problem is resolved
}

The comment references an unresolved currentRSSI() problem. By contrast, the Repeater implementation in examples/simple_repeater/MyMesh.h correctly reads from _prefs:

int getInterferenceThreshold() const override {
return _prefs.interference_threshold;
}

The Companion firmware already holds a NodePrefs _prefs instance (declared in MyMesh.h) which contains the interference_threshold field — it is simply never used in this path.

Current Behavior

Firmware
getInterferenceThreshold()
User-configurable

Repeater
returns _prefs.interference_threshold
✅ via set int.thresh

Room Server
returns _prefs.interference_threshold
✅ via set int.thresh

Companion
always returns 0
❌ hardcoded

Proposed Fix

Step 1 — examples/companion_radio/MyMesh.cpp

// Before:
int MyMesh::getInterferenceThreshold() const {
return 0; // disabled for now, until currentRSSI() problem is resolved
}

// After:
int MyMesh::getInterferenceThreshold() const {
return _prefs.interference_threshold;
}

Step 2 — expose set int.thresh / get int.thresh to Companion (firmware side)

Currently set int.thresh is handled only in CommonCLI.cpp and is not accessible from Companion firmware. As a first step, adding int.thresh handling to the Companion's configuration command path (serial/BLE CLI) would allow users to configure it without recompiling — consistent with how it is already handled in Repeater and Room Server firmware.

Step 3 — mobile app UI (separate task, separate repository)

Once the firmware accepts set int.thresh on Companion nodes, exposing interference_threshold as a field in the MeshCore iOS/Android app's radio settings screen would make this accessible to the widest range of users. As this requires changes to the app repository, it is noted here as a follow-up task rather than part of this issue.

Status of the currentRSSI() Problem

The comment in the code suggests currentRSSI() was unreliable at the time this was written. From a quick reading of the current code this issue may have been addressed, but I would like to know the project's perspective. It would be helpful to clarify:
Has this issue been resolved in recent RadioLib versions?
Is there a known workaround (e.g., using getRSSI() directly on the radio object)?
If currentRSSI() is still unreliable on some hardware, a safe fallback would be to leave the default at 0 (disabled) but allow users to opt in by setting a non-zero value — rather than preventing them from doing so at all.

References

examples/companion_radio/MyMesh.cpp — hardcoded return 0

examples/simple_repeater/MyMesh.h — correct _prefs.interference_threshold usage

src/helpers/CommonCLI.cpp lines 290–291, 445–446 — set int.thresh implementation

src/helpers/CommonCLI.h line 42 — interference_threshold field in NodePrefs

Related: #1157, #1553, #2079

[weebl2000]

Also related: #1727 - you might want to try that one out. It uses channel activity detection for checking for interference before sending.

[jirogit]

Also related: #1727 - you might want to try that one out. It uses channel activity detection for checking for interference before sending.

Thank you weebl2000 for your comment. That looks more practical for many regions.

However, hardware CAD (which detects LoRa preambles only) is useful but does not fully satisfy the Japanese legal requirement. Japanese carrier sense / LBT (Listen Before Talk) requires deferring transmission when non-LoRa radios are also using the channel. More details #2079

[jirogit]

However, hardware CAD (which detects LoRa preambles only) is useful but does not fully satisfy the Japanese legal requirement. Japanese carrier sense / LBT (Listen Before Talk) requires deferring transmission when non-LoRa radios are also using the channel. More details #2079

This PR ( #2218 .) implements Japan-compliant LBT for Companion firmware without relying on getInterferenceThreshold(). Instead, isChannelActive() directly performs 5ms continuous RSSI sensing (−80dBm absolute threshold, ARIB STD-T108 §4.4) when operating on Japan 920MHz frequencies, bypassing the hardcoded return 0 entirely.
This does not resolve the broader issue of exposing set int.thresh to Companion firmware or the mobile app UI — those remain valid follow-up tasks. But for Japan regulatory compliance specifically, the LBT requirement is now met independently of the interference threshold preference.