RSSI meter wildly ineffective

Question

The nRF 52840 RSSI "meter" is not usable. 
 I tested in an RF (2.4Ghz) quiet neighborhood. Using a reference receiver, I measured RSSI variance around +/-3 dB (95% confidence interval) from each of 5 transmitters; this is in line with expectation. Noise was below -99 at all times during the 1 hour test. I positioned a nRF 52840 20 cm away from the reference measurement station. The Nordic RSSI values did not exhibit a Gaussian noise curve at all, but instead reported three strong modes at -79, -65, and -58; each with incredibly small tails. Binning the results according to proximity to these modes revealed a variance of 0.2 dB (95%), which is more precise than noise will allow. From this evidence I gather three important facts: a more distant node can have a higher RSSI, the RSSI cannot be averaged to reduce "noise" as the values are nonlinear and modal, and therefore there is no way to estimate relative signal strength from the relative signal strength indicator. I used 5 transmitters during this test and observed similar behavior from each, both reasonable values from my reference receiver and unreasonable values from the Nordic chip. RSSI does not work as intended. Please document this behavior, consider disabling the API for this part, and further document which nRF parts actually work. 
 
 Please tell me what part I have to replace in my next board design to achieve usable RSSI?

Hung Bui · Accepted Answer

Correct, unfortunately it's not supported on nRF Connect right now. Limiting your advertising packet to one channel is currently the only option. Another option is to handle the scanning directly from the radio. We do that on our nRF5 for Mesh SDK.

hmolesworth · Answer

Being lazy (== busy) I haven't read the entire thread in detail, but I already display separate RSSI values for all 40 channels - including the advertising channels - on an e-Ink display. Does this help at all? Place in ble_evt_handler()

        case BLE_GAP_EVT_RSSI_CHANGED:                 // 28 RSSI report
            rssi_value =  p_gap_evt->params.rssi_changed.rssi;
            int16_t channel_rssi =  p_gap_evt->params.rssi_changed.ch_index;
            NRF_LOG_INFO("RSSI changed, new: %d, channel: %2d, power %ddBm",rssi_value, channel_rssi, p_gap_evt->params.adv_report.tx_power);
            int16_t LimitedValue = rssi_value; if (LimitedValue < -99) LimitedValue = -99;  if (LimitedValue > 99) LimitedValue = 99;
            rssiValues[channel_rssi] = LimitedValue;
            break;
            
        case BLE_GAP_EVT_CONNECTED:
            // Start RSSI collection for reports
            //   Minimum change in dBm before triggering BLE_GAP_EVT_RSSI_CHANGED event
            //   Number of RSSI samples with a change of threshold_dbm or more before BLE_GAP_EVT_RSSI_CHANGED event
            err_code = sd_ble_gap_rssi_start(p_gap_evt->conn_handle, 4, 2);   
            APP_ERROR_CHECK(err_code); 
            // Set RSSI to minimums
            InitRssiValues();
            Blah Blah
            break;

        case BLE_GAP_EVT_CONNECTED:
            // Set RSSI to minimums
            InitRssiValues();
            Blah Blah
            break;


Assumes:
// Channel rssi values, 37 data and 3 advertising
int16_t rssiValues[40] = {-99};
#define BLE_CHANNEL_COUNT sizeof(rssiValues)/sizeof(rssiValues[0])
#define BLE_DATA_CHANNELS (BLE_CHANNEL_COUNT-3)
STATIC_ASSERT(BLE_CHANNEL_COUNT == 40, "BLE_CHANNEL_COUNT == 40 error");

static void InitRssiValues(void)
{
    for (uint16_t i=0; i<BLE_CHANNEL_COUNT; i++)
    {
        rssiValues[i] = -99;
    }
}

This on the Central, by the way

RSSI meter wildly ineffective

Top Replies