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.

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

[Cody]

Hello Hung Bui,

Thank you for your response.

Both of those options are correct, on a Thingy91/nRF Connect based platform we are using the nRF52840 in BLE HCI mode where we are scanning for devices, we are curious if we can perform the following:
1) For a scan result, determine what channel it was discovered on (37,38,39)
2) Configure the scanner to scan only on a specific channel (ie. 39)

Hung Bui said:

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 ? 

- Correct

I was doing some research of my own yesterday and came across this thread, https://devzone.nordicsemi.com/f/nordic-q-a/69099/ncs-bt_le_scan_start-api-is-limited-to-report-phy-and-adv-detail, where Sigurd points out that you can register a callback using the function, bt_le_scan_cb_register in order to receive a struct with significantly more information than using the following callback type in conjunction with bt_le_scan_start in zephyr/include/bluetooth/bluetooth.h:

bt_le_scan_cb_t(const bt_addr_le_t *addr, s8_t rssi, u8_t adv_type, struct net_buf_simple *buf)

The struct received with the callback passed in to bt_le_scan_cb_register has the following form:

/** LE advertisement packet information */
struct bt_le_scan_recv_info {
	/** @brief Advertiser LE address and type.
	 *
	 *  If advertiser is anonymous then this address will be
	 *  @ref BT_ADDR_LE_ANY.
	 */
	const bt_addr_le_t *addr;

	/** Advertising Set Identifier. */
	u8_t sid;

	/** Strength of advertiser signal. */
	s8_t rssi;

	/** Transmit power of the advertiser. */
	s8_t tx_power;

	/** Advertising packet type. */
	u8_t adv_type;

	/** Advertising packet properties. */
	u16_t adv_props;

	/** Primary advertising channel PHY. */
	u8_t primary_phy;

	/** Secondary advertising channel PHY. */
	u8_t secondary_phy;
};

This struct contains primary phy channel and secondary phy channel, is there something I am missing here?

Update: Took some time to implement this and it looks like the primary_phy field is always reporting a "1".

[Hung Bui]

Hi Cody, 

primary_phy and secondary_phy are the info about the modulation on the PHY layer. So it can be either 1Mbps, 2Mbps, CODED PHY 125kbps or CODED PHY 500kbps. It's not related to the 3 advertising channels that we are discussing here. 

[Cody]

Bummer, so it sounds like this is only possible in the nRF5 SDK and not the nRF Connect SDK?

[Hung Bui]

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.