Summary
The README mentions DISABLERSSITHRESHOLD as a flag that "disables automatic setting of RSSI_THRESHOLD (legacy behaviour), and uses MINRSSI (-82)" — but doesn't explain the failure mode when the actual environment's noise floor reads below MINRSSI. In that case currentRssi > rssiThreshold is never true, the gate is permanently closed, and the user gets zero events with no diagnostic output indicating why.
What I hit
In a recent project on CC1101 (a particular AGC configuration left the chip's RSSI register averaging around -100 dBm). With -DDISABLERSSITHRESHOLD set, the gate was pinned at default MINRSSI=-82. The condition -100 > -82 is false for every sample, so receiveMode never went true, so even very strong real signals never made it through to the slicer. Library was silent. GDO0 was actively producing edges (verified by raw digitalRead polling in user code), but the ISR was discarding them because of the gate.
It took hours to trace because the README implies DISABLERSSITHRESHOLD is the "permissive / always open" option, when it really just pins the gate at a specific level that may or may not be appropriate for your noise floor.
Suggested doc additions
In the relevant section of the README (after the DISABLERSSITHRESHOLD description):
Note: when DISABLERSSITHRESHOLD is set, the RSSI gate is pinned at MINRSSI (default -82 dBm). If your environment's noise floor reads below MINRSSI — which can happen with certain AGC configurations, sensitive front-ends, or quiet RF environments — the gate will be permanently closed and you will see zero events even with strong signals present. In that case override -DMINRSSI=-100 (or any value comfortably below your measured floor) to open the gate. To find your actual noise floor, read the chip's RSSI register repeatedly while no signal is present.
It might also be worth adding a "no events at all? troubleshooting" section, walking users through:
- Check
radio.begin() returned RADIOLIB_ERR_NONE
- Verify the chip is responding via PARTNUM / VERSION readback (CC1101: PARTNUM=0x00, VERSION=0x04/0x14/0x17/0x18)
- Poll RSSI for ~5 s to determine the actual noise floor in your setup
- Choose
MINRSSI well below that floor (or leave auto-threshold enabled)
- Sanity-check
MINIMUM_PULSE_LENGTH and MINIMUM_SIGNAL_LENGTH against expected signal characteristics
- If still no events but real signals are present: instrument GDO0 directly with
digitalRead polling — if it toggles, the library's gating is the issue, not the radio
Happy to put together a doc PR with this content if it's wanted.
Related
Filed alongside #207 (raw pulses callback) and #208 (AGCCTRL2 default deafness). Together these are the three things that cost real debugging time in our project; documenting / fixing them would smooth the path for the next person bringing up rtl_433_ESP on cheap-remote use cases.
Summary
The README mentions
DISABLERSSITHRESHOLDas a flag that "disables automatic setting of RSSI_THRESHOLD (legacy behaviour), and uses MINRSSI (-82)" — but doesn't explain the failure mode when the actual environment's noise floor reads belowMINRSSI. In that casecurrentRssi > rssiThresholdis never true, the gate is permanently closed, and the user gets zero events with no diagnostic output indicating why.What I hit
In a recent project on CC1101 (a particular AGC configuration left the chip's RSSI register averaging around -100 dBm). With
-DDISABLERSSITHRESHOLDset, the gate was pinned at defaultMINRSSI=-82. The condition-100 > -82isfalsefor every sample, soreceiveModenever wenttrue, so even very strong real signals never made it through to the slicer. Library was silent. GDO0 was actively producing edges (verified by rawdigitalReadpolling in user code), but the ISR was discarding them because of the gate.It took hours to trace because the README implies
DISABLERSSITHRESHOLDis the "permissive / always open" option, when it really just pins the gate at a specific level that may or may not be appropriate for your noise floor.Suggested doc additions
In the relevant section of the README (after the
DISABLERSSITHRESHOLDdescription):It might also be worth adding a "no events at all? troubleshooting" section, walking users through:
radio.begin()returnedRADIOLIB_ERR_NONEMINRSSIwell below that floor (or leave auto-threshold enabled)MINIMUM_PULSE_LENGTHandMINIMUM_SIGNAL_LENGTHagainst expected signal characteristicsdigitalReadpolling — if it toggles, the library's gating is the issue, not the radioHappy to put together a doc PR with this content if it's wanted.
Related
Filed alongside #207 (raw pulses callback) and #208 (AGCCTRL2 default deafness). Together these are the three things that cost real debugging time in our project; documenting / fixing them would smooth the path for the next person bringing up rtl_433_ESP on cheap-remote use cases.