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?
In the descriptor is perfectly fine. 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? Cheers, simon On Sat, Jul 2, 2016 at 8:31 AM, Christopher Collins <[email protected]> wrote: > On Sat, Jul 02, 2016 at 03:40:25AM -0700, Simon Ratner wrote: > > Hi devs, > > > > Any plans to expose a way to read last-seen rssi of a connection? > > I found ble_hci_util_read_rssi(), but it seems to always return rc=4 for > me. > > > > Cheers, > > simon > > Hi Simon, > > Two things: > > * Yes - we will need to add a function to the host interface which > allows the application to query the RSSI of a peer. It might make sense > to just throw it into the big connection descriptor that > ble_gap_find_conn() retrieves. > > * ble_hci_util_read_rssi() should work. 4 (BLE_HS_EMSGSIZE) is an odd > return code to be getting; it indicates that the host thinks the > controller sent back an invalid command complete event in > acknowledgement. Just to clarify - you are getting 4 as the return code > (and not as the retrieved rssi, e.g.)? > > Thanks, > Chris >
