BLE RSSI

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决
2,085 次查看
michaelbrudevo1
Contributor III

I am making a call to Gap_ReadRssi shortly after the connection is established and I am getting RSSI readings of 0.  I expected to see a value of 127 (gGapRssiNotAvailable_d) or something correct (likely -50 or less).  Is this a known issue in version 1.0.2 of the connectivity software (running on a MKW31Z)?

Also, how soon after a connection can I expect RSSI readings to become valid?  And are they updated every connection event?  Any chance there can be an API to automatically produce gConnEvtRssiRead_c events when RSSI is updated?

标签 (2)
1 解答
1,668 次查看
miguel_reyes
NXP Employee
NXP Employee

Hi michaelbrudevold

You are correct about the behavior you are seeing. The RSSI is valid only after the first packet was received in connection (on data channels). The Gap_ReadRssi API should not and does not wait for the first connection to happen as it may never happen due to supervision timeout being triggered before the connection was established. Regarding the returned value ('0' instead of '127'). We will fix this in the next release, so, API will return the expected 127. 

About your questions:

  1. How soon after a connection can I expect RSSI readings to become valid? It must wait for the first connection event to be able to get a valid RSSI.   
  2. And are they updated every connection event?  Yes, the RSSI is obtained at every valid received packet. 
  3. Any chance there can be an API to automatically produce gConnEvtRssiRead_c events when RSSI is updated? We don't support such feature. 

Please, mark this question as answered if above information resolved your questions. 

Thanks and best regards,

Miguel

在原帖中查看解决方案

1 回复
1,669 次查看
miguel_reyes
NXP Employee
NXP Employee

Hi michaelbrudevold

You are correct about the behavior you are seeing. The RSSI is valid only after the first packet was received in connection (on data channels). The Gap_ReadRssi API should not and does not wait for the first connection to happen as it may never happen due to supervision timeout being triggered before the connection was established. Regarding the returned value ('0' instead of '127'). We will fix this in the next release, so, API will return the expected 127. 

About your questions:

  1. How soon after a connection can I expect RSSI readings to become valid? It must wait for the first connection event to be able to get a valid RSSI.   
  2. And are they updated every connection event?  Yes, the RSSI is obtained at every valid received packet. 
  3. Any chance there can be an API to automatically produce gConnEvtRssiRead_c events when RSSI is updated? We don't support such feature. 

Please, mark this question as answered if above information resolved your questions. 

Thanks and best regards,

Miguel