Read RSSI value

RE: Read RSSI value

Chaabane — Wed, 22 Nov 2017 09:16:54 GMT

Thank you Martin, now it is working for me

RE: Read RSSI value

MartinBL — Wed, 22 Nov 2017 09:03:11 GMT

Q1: I didn't read your code carefully enough. You should use p_ble_evt->evt.gap_evt.params.adv_report.rssi to get the RSSI. Then you will get it in every adv report, not just the scan reports.

Q3: Not really. If the phone doesn't support 2Mbps or coded phy it is simply not physically possible. It is possible though, that your module is designed to advertise on 1Mbps phy and then switch to coded phy after you have connected.

RE: Read RSSI value

Chaabane — Tue, 21 Nov 2017 16:02:14 GMT

Thinking about it, RSSI values can be positive. It is just that i'm not used to have such a strong signal with the modules I used before!

RE: Read RSSI value

Chaabane — Tue, 21 Nov 2017 15:53:02 GMT

Hi Martin, Thank you for the feedback.

Q1: without scan_rsp checking I get RSSI values : 0, 2 and 6. They don't look like real RSSI in dBm ?. That's why I put this condition for testing purposes. so the real question is why I'm receiving these values of RSSI and also is it normal that the RSSI si declared as signed char ?

Q2 : Ok, that's what I thought.

Q3: When using my phone (doesn't have bleutooth 5) with nRF connect App I am able to see both modules. I verified that the PHY used in both modules is LE coded by using 'config print' command in PuTTY. Does that make sense ?

Q4: OK.

Thank you. Chaabane

RE: Read RSSI value

MartinBL — Tue, 21 Nov 2017 15:25:35 GMT

Hi,

Q1: I'm not sure if I understand why you useif ( p_gap_evt->params.adv_report.scan_rsp ). Do you really only want to print RSSI on scan responses? You are not necessarily getting a scan response from all devices. Why don't you simply use NRF_LOG_INFO("rssi =%d dBm",p_gap_evt->params.rssi_changed.rssi);, and no if(...) in each BLE_GAP_EVT_ADV_REPORT event? This would print the RSSI from every single received advertising packet.

Q2: The event will occur each time a device is discovered.

Q3: Yes. Devices on different physical layers cannot hear each other.

Q4: You should use the BLE_GAP_EVT_ADV_REPORT event.