A comment regarding RSSI: all frames received within a connection event will have an RSSI measurement. We only count valid CRC frames. The RSSI applies to empty pdu’s as well so the RSSI will get updated as long as the connection is valid. We also dont average the RSSI in any way; the last data channel pdu received will update the RSSI in the connection.
Will PS I hope the term “Data Channel PDU” does not confuse folks. All that means is a packet sent on a data channel as opposed to an advertising channel. Thus, LL control PDU’s, empty pdu’s, and PDU’s with actual user data in them will all update the RSSI in the connection. > On Jul 2, 2016, at 6:54 PM, Christopher Collins <[email protected]> wrote: > > On Sat, Jul 02, 2016 at 10:18:03AM -0700, Simon Ratner wrote: >> Correct, the return value is 4, and the out param remains unchanged. >> >> I am testing on nrf51; have tried calling it both directly from the >> EVENT_CONNECT callback, as well as some time later, just in case it was >> state-related. For the record, I am fairly certain it used to work >> not-too-long ago, so perhaps this is a recent breakage? > > Bummer. I will check it out. Thanks for the heads up. > >> In the descriptor is perfectly fine. > > After thinking about it some more, I think it might be best to have a > dedicated function for querying the RSSI rather than putting it in the > connection descriptor. The operation requires communication with the > controller, and I think there is some value in isolating > host-controller-communication when possible. > >> For my own edification, is there a heartbeat of some sort while the >> connection is open, or is the value just representative of the last >> packet seen? Or a one-off value at time of establishment? > > (Will, please chime in if I am talking nonsense) > > It is the RSSI of the most recently received data packet. If the peer > isn't sending any data, then the RSSI value won't get updated. > > Chris
