RSSI equation and it's variables

[PB]

Hello,

I would like to understand more about a topic which has been covered here many times. Since I haven't found an answer I wanted to dig a bit deeper than the RSSI vs distance and discuss how does the SD calculate RSSI in detail? 

I have a case of different RSSI readings in different environments which is totally normal. The tricky thing is that our RSSI is the same value on 12m as it is few cm away from nRF52832 scanning chip. And it's roughly -62! That's not just on nRF52832/52840 but phones also exhibit this behaviour. This is a difference in RSSI range between two places we are testing in is visible on the plot below:

The site on left a big open space with some metal, non heated space (it's cold but above 0°C) with wrought 30 BLE emitters. The one on right is office space with normal temperature with hundreds of BLE advertisers.

Since RSSI uses a noise floor as reference I decided to change it with DTM firmware and emitted a constant carrier on CH 37-39 to see what happens in the office space. And the results looked like in this screenshot.

Difference in range is clearly visible, CH37 being the worst offender. Unfortunately I cannot do a similar test on target site. 

The reason for writing this message is to maybe understand the RSSI calculation method in more detail than:

RSSI = Prx/PO
where:
• P rx is the received power in watts (W) or decibels (dBm).
• PO is a reference power, often taken to be

And also to see if variables used to calculate the value can be exposed and compensated? For example if BLE channel noise map could be used in side of the application this would make it possible to correct the scanned values, this would be some start. For example can ble_gap_evt_qos_channel_survey_report_t be used for this somehow?

We don't expect RSSI to be ideal or always the same. But same values over >10m distances makes you wonder...

[Sigurd]

Hi,

Since I haven't found an answer I wanted to dig a bit deeper than the RSSI vs distance and discuss how does the SD calculate RSSI in detail? 

The SD does not do any calculation on the RSSI. It just gives you the RSSI from the RADIO peripheral. 

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.ps.v1.1%2Fradio.html&cp=5_2_0_22_9&anchor=rssi

I have a case of different RSSI readings in different environments which is totally normal. The tricky thing is that our RSSI is the same value on 12m as it is few cm away from nRF52832 scanning chip. And it's roughly -62! That's not just on nRF52832/52840 but phones also exhibit this behaviour.

Are you sure that you are reading the RSSI from the correct device?

[PB]

Thank you for your reply Sigurd. We have checked the that the RSSI is from correct devices and it is correct and consistent. But only in single site so we are wondering how the RADIO peripheral establishes RSSI

[Sigurd]

nRF52832 scanning chip

Do you see the same results if you are in a BLE connection? And are using sd_ble_gap_rssi_start / sd_ble_gap_rssi_get to get the RSSI?

https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s132.api.v7.3.0/group___b_l_e___g_a_p___f_u_n_c_t_i_o_n_s.html?cp=5_7_3_1_2_1_3_35#gac369253b7f5ce0fc0093a6133faa791f

[PB]

We rely on the data passed along BLE_GAP_EVT_ADV_REPORT. It is attached by:

NRF_SDH_BLE_OBSERVER(m_ble_observer, APP_BLE_OBSERVER_PRIO, _u_ble_evt_handler, NULL);

Later RSSI is taken from ble_evt_t const * const p_ble_evt in the following way:

void _u_ble_evt_handler(ble_evt_t const * const p_ble_evt)
{
ble_gap_evt_t const *p_gap_evt = &p_ble_evt->evt.gap_evt;
ble_gap_evt_adv_report_t const *p_adv_report = &p_gap_evt->params.adv_report;
ble_data_t const *adv_data = &p_adv_report->data;
ble_gap_addr_t const *peer_addr = &p_adv_report->peer_addr;
int8_t const *rssi = &p_adv_report->rssi;
//...
}

Scan is started by

sd_ble_gap_scan_start(&u_device_settings.scan_params, &_m_scan_buffer);

and stopped by:

sd_ble_gap_scan_stop()

It has been working very well for long time. It's just a single site in which the signals are behaving in such a way and the screenshot with emitting carriers on specific channels was closest we were able to replicate the behaviour. There are no strong WiFi APs, BLE jammers and such so to our knowledge external factors are not the reaon

[Sigurd]

1) What SDK and SoftDevice version are you using?

2) What revision of the nRF52832 is this?

3) Do you see the same results if you are in a BLE connection with the device?