You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Simon Ratner <si...@proxy.co> on 2016/07/02 10:40:25 UTC
Read rssi of established connection
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
Re: Read rssi of established connection
Posted by Simon Ratner <si...@proxy.co>.
Perfect, that works.
Thanks, Chris!
On Sat, Jul 2, 2016 at 7:33 PM, Christopher Collins <cc...@apache.org>
wrote:
> On Sat, Jul 02, 2016 at 10:18:03AM -0700, Simon Ratner wrote:
> [ble_hci_util_read_rssi()]
> > Correct, the return value is 4, and the out param remains unchanged.
>
> I have fixed this bug in develop. Thanks again for reporting it.
>
> A proper function for querying rssi will get added to the API soon. At
> the moment, I would just keep using ble_hci_util_read_rssi(). I imagine
> the real function will be quite similar to this one.
>
> Chris
>
Re: Read rssi of established connection
Posted by Christopher Collins <cc...@apache.org>.
On Sat, Jul 02, 2016 at 10:18:03AM -0700, Simon Ratner wrote:
[ble_hci_util_read_rssi()]
> Correct, the return value is 4, and the out param remains unchanged.
I have fixed this bug in develop. Thanks again for reporting it.
A proper function for querying rssi will get added to the API soon. At
the moment, I would just keep using ble_hci_util_read_rssi(). I imagine
the real function will be quite similar to this one.
Chris
Re: Read rssi of established connection
Posted by will sanfilippo <wi...@runtime.io>.
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 <cc...@apache.org> 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
Re: Read rssi of established connection
Posted by Christopher Collins <cc...@apache.org>.
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
Re: Read rssi of established connection
Posted by Simon Ratner <si...@proxy.co>.
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 <cc...@apache.org>
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
>
Re: Read rssi of established connection
Posted by Christopher Collins <cc...@apache.org>.
On Sat, Jul 02, 2016 at 08:31:18AM -0700, Christopher Collins wrote:
> * 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.)?
I should add that I don't have the necessary hardwrae handy at the
moment, or I would test it myself. I hope to get a look at this later
today.
Chris
Re: Read rssi of established connection
Posted by Christopher Collins <cc...@apache.org>.
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