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.
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.
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
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
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
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
BSP isn't perfect either but this is still more of a board or project level
decision in my mind than the more generic MCU level so my vote would be
moving it to the BSP. It's much easier to spin a new BSP than it is modify
the MCU level code.
Also breaking the clock source out to the MCU code
