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? 

[PB]

1. SD s132_nrf52_7.2.0 and nrf5_sdk_17.1.0_ddde560
2. 52832-AAE1
3. I established a connection not in the actual environment but in my dev setup where RSSI behaves normally. Indeed RSSI difference can be observed. In the attached screenshot first range from the vertical line is not connected, second is when i kept a idle BLE connection to the device. Short interruption was caused by script which measured the RSSI and not the actual device
   

Update 2023-02-21:

We did some checks starting with RSSI viewer and comparison between office (works ok) and target site (has problems). Clearly the target site has strong WiFi but it's not advertising channels so it should not affect the RSSI on channels 37-39?

Target:

Office:

Also when connected with BLE on target site there was no significant RSSI difference in advertisements.

[Sigurd]

Hi,

The RSSI detector will measure the energy in the channel but some energy from the adjacent channel will also we part of this. It doesn't distinguish between different modulation. So all energy that falls in the channel will be measured. It can also fluctuate a lot if you have reflections of the received signal.

[PB]

Hello, Thank you for the answer. I am aware of these effects and that other radios like WiFi will also get detected by RSSI detector on some channels. What I am trying to understand is how RSSI is calculated for CH 37-39 so that I see the same signal on 1 and 10-20m distances in one environment and what could cause such effect. Reflections wouldn't make the signal so strong on big distance or even if it would it would fluctuate more but it's steady ~65dBm on 1m and on 10m in some settings.

nRF52840 is slightly more responsive so the value change a bit more with distance but still not as you'd expect. 

Could this be related to low ambient temperature which is +/- 0°C given that it's winter and the space is not heated?