According to the documentation associated with the function, it reads the RSSI of the last successfully received packet; Thus, if there is no successfully received packet, it may be returning -120 as an error/uninitialized?
The RSSI from the scanReport is the direct access to the value, so using that should be fine in lieu of the function not working correctly.
Listed under the BLE_StackGap.h file at line 1049, it says:
/** Rssi of the responding device.
* Range: -127 <= N <= +20
* Units: dBm
* N = 127 -> RSSI not available
Thus, it may be listing the incorrect values when you call the function due to not being available while not connected/scanning devices? There is most likely a requirement such as being connected, actively scanning, or calling it when you receive an advertisement packet...
When I'm connected to a peer device, is it the one I'm getting the RSSI on? Using the scanReport->rssi?
1 of 1 people found this helpful
The RSSI value will be associated with the currently connected device, so yes.
By Using the CyBle_GetRssi(), Is there a way to determine if packet received is not an error packet.
Based on the RSSI alone? No. The RSSI is merely a "signal strength" value, that is associated (roughly due to wireless interference) with distance and antenna power/gain. It's like a "volume level", but for wireless packets received to tell you how "loud" the wireless signal was. This doesn't correlate with the type of packet as far as I know.
You should be able to handle the HCI errors and the Link Layer errors through the API associated with the BLE module. (Right-click on the BLE module in topdesign.cysch and select "Open API Documentation", and look for HCI and Link Layer interactions)
I don't know for sure if you will be able to interact with the error packets for the lowest level communications over BLE, but you should be able to get pretty close from what I've seen.
Thank you for the replies!