RSSI meter wildly ineffective

[caezar]

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?

[caezar]

> Assuming propagation loss is similar between the devices, e.g. by measuring conducted, the RSSI filter is specified to give a +/-2dB accuracy on RSSI readings

It does not. It gives multi-modal answers repeatedly forever, jumping down from the highest reading in about 5.5 dB jumps.

> Note though that you need to initiate the measurement correctly, most significantly the RSSI will have to settle.

It does not settle. The crazy answers continue forever. I knew to run this experiment because in the field we see the same behavior. Lots of hypotheses from people about why the RSSI meter is hard to use, but none of them just sat down and logged 60 minutes of continuous readings.

> As you have not described how you are doing this it's hard for me to say decisively, but this is a somewhat common cause for incorrect RSSI readings.

I initiate a continuous scan and record for 3600 seconds, approximately a million times longer than the stated settle time. Have someone run this test and you'll see without any doubt that the output is nothing like a Gaussian or one-tailed distribution but is clearly just mode-selecting. In the forum, an engineer claims "nonlinearities" that they then could not describe because it's proprietary; not the answer one expects for "how does the machine work?"

The RSSI meter does not work as intended. As a further experiment, I ran 5 minutes of continuous readings from a single transmitter and then moved the observer station an additional 3 meters away. The behavior shifted slightly but the most telling outcome is this: the farther station received a HIGHER mean RSSI reading (-72 vs -74.5).

The documentation is woefully inaccurate, as is the RSSI reading. I'm testing a really unsatisfying solution.

[caezar]

I have an idea that may answer a lot of people's questions. If the advertiser is switching among the primary advertising channels, I would understand that to give possible different RSSI readings; is that true? If so, can we get an array of RSSI values rather than a single? That would be amazingly powerful. If not, could we filter which channel we want them from, or just ask you guys to hand out RSSI from the first channel the peer was heard on? If channel hopping is really the cause of my issue, I'll be quite happy; if Nordic could communicate facts about this phenomenon out through the softdevice, that would be incredible.

[Andreas]

Hi,

 

 

caezar said:

I initiate a continuous scan and record for 3600 seconds

 OK, so I understand you are using BLE to test this and not a bare-metal solution. This complicates things a bit as you are limited to using the API and the data it reports.

 

 

caezar said:

It does not settle. The crazy answers continue forever. I knew to run this experiment because in the field we see the same behavior. Lots of hypotheses from people about why the RSSI meter is hard to use, but none of them just sat down and logged 60 minutes of continuous readings.

Settling refers to the energy level inside the radio after either enabling the radio HW or starting reception of a packet. This is not relevant when using the Softdevice as you are not able to change it, and the RSSI is collected at the ADDRESS event anyway, sufficiently far into the packet.

 

 

caezar said:

The RSSI meter does not work as intended. As a further experiment, I ran 5 minutes of continuous readings from a single transmitter and then moved the observer station an additional 3 meters away. The behavior shifted slightly but the most telling outcome is this: the farther station received a HIGHER mean RSSI reading (-72 vs -74.5).

As I mentioned when testing this way there could be differences in propagation loss due to multipath, fading etc. received by the radio. The RSSI meter just reports the signal level at the input of the receiver, if there is any variation due to physical factors this will add on top of the 2dB baseline RSSI variation and for this reason unfortunately the accuracy and use of RSSI is limited.

 

 

caezar said:

If the advertiser is switching among the primary advertising channels, I would understand that to give possible different RSSI readings; is that true?

There will likely be slightly different matchings, insertion losses, antenna characteristics and propagation on the different channels so I would expect the physical received power to be different. RSSI will thus also be different.

 

caezar said:

If so, can we get an array of RSSI values rather than a single? That would be amazingly powerful. If not, could we filter which channel we want them from, or just ask you guys to hand out RSSI from the first channel the peer was heard on?

Unfortunately if there is no support for doing this already it will have to be implemented in a future version of the stack or controller. This will take time, depending on the priority.

 

 

Best regards,
Andreas

[caezar]

> Unfortunately if there is no support for doing this already it will have to be implemented in a future version of the stack or controller. This will take time, depending on the priority.

This would be a massive boon for anyone doing beacon work. Based on my data, I think it's safe to say that every request in the forum regarding why location doesn't work could be solved by offering 3 RSSI readings, one from each primary advert channel, in a new API. I hope Nordic will see the priority as relating to all of those customer projects. In the mean time, we will restrict advertising to a single channel in order to correct the unusable RSSI meter.

Although I imagine that someone may think this idea is a little weird, it should make location services much more accurate by offering readings from three different photon paths. At Bell Labs, I know they've used this type of system to measure the motion of human bodies in the environment based solely on WiFi subcarrier signal levels.

[caezar]

To confirm, when I switch the beacon to any one advertisement channel, the RSSI meter returns to expected behavior. Having all three channel RSSI meters would be invaluable. Please see whether the team can put this on the road map for 2021?

[hmolesworth]

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

[Cody]

Thank you hmolesworth, it does. Unfortunately, we are hoping to implement something like this on the 9160 platform which utilizes the nRF Connect SDK. Can anyone from Nordic comment as to the ability for a user to parse out the RSSI per channel on the nRF Connect SDK? Do we have access to the "p_gap_evt" struct?

[Cody]

Andreas, are you able to comment?

[Hung Bui]

Hi Cody, 
I'm taking over the case from Andreas. 
I will check with our team if there is any solution for this. 
From my understanding you are asking about 2 options: 

- report of RSSI per channel 

- Or possibility to do selective channel when scanning ? 

In the mean time please let us know how do you measure RSSI? by using the rssi value in the call back bt_le_scan_cb_t ? 

[Hung Bui]

Hi again Cody, 

I got the response from our stack team, quoted here: 

There is no such option to retrieve channel of a given advertising report. It is also not possible to scan on a given set of channels. 

There are plans to give the functionalities on our softdevice into NCS but we don't have the timeline for the features you are requesting yet.