rssi threshhold is the key piece in the signal detection logic. When the receiver sees that the rssi exceeds it starts the receiver, then when it drops below this level it stops.

The auto rssi threshold logic, looks at the average rssi level, then subtracts RSSI_THRESHOLD ( defaults to 9 ) and adjusts rssi threshhold. This is to allow the receiver to function in locations with a lot of RF noise.

Ignores are the receiver logic indicating it received what it thinks is noise, hence being ignored.

Right. I know that but was trying to correlate that to the status values since the names are different that the commented ones. Not sure which is which.

I figured (due to it working for a bit) it was badly calculating the threshold or rssi, not sure if there is periodic noise or a strong 433 signal now and then skewing it. I know there are 3 other weather stations I can hear on my scanner.

I was able to get this workingby using rssi:-10 which seems odd. But it forces it, I get maybe 10% decode failures which is fine.

Just to clarify this issue for example
The current debug form status and boot is

RTLRssi: -76
RTLAVGRssi: -88
RTLRssiThresh: -79
signalRssi: -71

while in the docs it says

"rssi":
"rssiThreshhold"
"currentRssi"

Looks like module prefixes were added.

I am assuming

RTLRssi = rssi
RTLAVGRss = new
RTLRssiThresh = rssiThreshhold
signalRssi = currentRssi

My confusion is what is the difference between RTLRssi and signalRssi ?
and what is set Rssi applied to for new threshold? rtlrssi or avg?

I think I found some answers in the rtl_433_esp lib, this makes more sense now, and that some of OMG env belong to it

339 RAW_SIGNAL_DEBUG ; display raw received messages
340 RSSI_SAMPLES ; Number of rssi samples to collect for average calculation, defaults to 50,000
341: RSSI_THRESHOLD ; Delta applied to average RSSI value to calculate RSSI Signal Threshold, defaults to 9
342 RTL_DEBUG ; Enable RTL_433 device decoder verbose mode for all device decoders ( 0=normal, 1=verbose, 2=verbose decoders, 3=debug decoders, 4=trace decoding. )
343 RTL_VERBOSE=## ; Enable RTL_433 device decoder verbose mode, ## is the decoder # from the appropriate memcpy line in rtl_433_ESP.cpp
...
346 SIGNAL_RSSI ; Enable collection of per pulse RSSI Values during signal reception for display in signal debug messages
347 RF_MODULE_INIT_STATUS ; Display transceiver config during startup
348: DISABLERSSITHRESHOLD ; Disable automatic setting of RSSI_THRESHOLD ( legacy behaviour ), and use MINRSSI ( -82 )
349 OOK_MODULATION ; Enable OOK Device Decoders, setting to false enables FSK Device Decoders
350 ```

Yes, updating the DOC's is in my backlog for the fall. My plan is to move the RTL_433_ESP messages to its own topic, and will update the docs at the same time.

From the current SYStoMQTT

"rssi":-19
"actRec":3,
"mhz":433.92,
"RTLRssiThresh":-93,
"RTLRssi":-98,
"RTLAVGRssi":-102,
"RTLCnt":426488,
"RTLOOKThresh":15

"rssi": - This is the current WiFi RSSI
"actRec": - Which receiver module is currently active
"mhz": - Receive frequency
"RTLRssiThresh": - This is the minimum signal RSSI value needed to enable the receiver logic.  This is a calculated value.
"RTLRssi": - Current RSSI value reported by the transceiver module
"RTLAVGRssi": - Average of Current RSSI value ( Used in calculation of RTLRssiThresh )
"RTLCnt": - Number of signals decoded
"RTLOOKThresh": - Unused

So I am assuing signalRssi the last received signals rssi?

Sorry, which message publishes signalRssi ?

In a decoded signal, the value rssi is the rssi of the decoded signal.

mqtt: status

You are correct, it is the signalRssi value of the most recent signal received.

This issue is stale because it has been open for 30 days with no activity.

This issue was closed because it has been inactive for 7 days since being marked as stale.