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?

[Andreas]

Hi,

 

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. Note though that you need to initiate the measurement correctly, most significantly the RSSI will have to settle. From the PS:

The RSSI is measured continuously and the value filtered using a single-pole IIR filter. After a signal level change, the RSSI will settle after approximately RSSI_SETTLE.

RSSI_SETTLE is 15µs typical, meaning if you initate the RSSI measurement less than 15µs after the radio has started in RX, or less than 15µs after starting reception of a packet, the reported RSSI will not be correct. 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.

 

Best regards,
Andreas

[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.