RSSI meter wildly ineffective

RE: RSSI meter wildly ineffective

Hung Bui — Wed, 20 Jan 2021 11:16:49 GMT

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.

RE: RSSI meter wildly ineffective

Cody — Tue, 19 Jan 2021 20:33:34 GMT

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

RE: RSSI meter wildly ineffective

Hung Bui — Thu, 14 Jan 2021 10:27:11 GMT

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.

RE: RSSI meter wildly ineffective

Cody — Wed, 13 Jan 2021 21:10:22 GMT

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)

[quote userid="2121" url="~/f/nordic-q-a/70152/rssi-meter-wildly-ineffective/288879#288879"]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 ? [/quote]

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

RE: RSSI meter wildly ineffective

Hung Bui — Wed, 13 Jan 2021 15:02:22 GMT

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.

RE: RSSI meter wildly ineffective

Hung Bui — Wed, 13 Jan 2021 10:43:28 GMT

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 ?

RE: RSSI meter wildly ineffective

Cody — Tue, 12 Jan 2021 18:16:34 GMT

Andreas, are you able to comment?

RE: RSSI meter wildly ineffective

Cody — Mon, 11 Jan 2021 18:42:32 GMT

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?

RE: RSSI meter wildly ineffective

hmolesworth — Fri, 08 Jan 2021 01:55:09 GMT

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

RE: RSSI meter wildly ineffective

caezar — Fri, 08 Jan 2021 01:28:16 GMT

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?

RE: RSSI meter wildly ineffective

caezar — Thu, 07 Jan 2021 16:20:57 GMT

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

RE: RSSI meter wildly ineffective

Andreas — Thu, 07 Jan 2021 09:04:20 GMT

Hi,

[quote user="caezar"]I initiate a continuous scan and record for 3600 seconds[/quote]

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.

[quote user="caezar"]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.[/quote]

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.

[quote user="caezar"]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).[/quote]

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.

[quote user="caezar"] If the advertiser is switching among the primary advertising channels, I would understand that to give possible different RSSI readings; is that true?[/quote]

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.

[quote user="caezar"]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?[/quote]

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

RE: RSSI meter wildly ineffective

caezar — Thu, 07 Jan 2021 05:02:14 GMT

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.

RE: RSSI meter wildly ineffective

caezar — Wed, 06 Jan 2021 17:07:03 GMT

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

RE: RSSI meter wildly ineffective

Andreas — Wed, 06 Jan 2021 10:57:16 GMT

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