Closed sfyang closed 6 years ago
I can reproduce this locally. I'll check with the underlying module owners for further investigation. From the error code, it seems that bt_gattc_discover_charc
reports error 0x3FFFFF6
(connection in use) and callbacks with status code 0x81
when querying for the 3rd argument.
Instead of calling bt_gattc_discover_charc
again after receiving BT_GATTC_DISCOVER_CHARC
with BT_ATT_ERRCODE_CONTINUE
, we should simply wait for successive events and keep inserting them into the characteristic list.
The attached modified version of ABLE
is a quick workaround that lists all the 128-bit characteristics of the chosen device.
ABLE_multiple_event.zip
The modified version above involves:
EventBlockerMultiple
and waitAndProcessEventMultiple
, which changes the implementation of EventBlocker::isOnce
and EventBlocker::onEvent
. The closure / functor object passed from client have to return a bool
value that indicates whether or not all the events have arrived.discoverCharacteristicsOfService
such that it returns false
when receiving BT_ATT_ERRCODE_CONTINUE
. I can confirm that, with the "Multiple" variant of both the EventBlocker
class and the corresponding waitAndProcessEvent()
helper, a properly modified and extended LBLEClient class with method for descriptor discovery can now work correctly for both characteristic and descriptor discovery.
This issue has been briefly mentioned and demonstrated in the issue report of #90.
Consider the following modified version of the 'ConnectPeripheral.ino' example from LBLE library, which inherits the
LBLEServiceInfo
struct and puts the characteristic list into the struct (thus probably solves #90 to some extend), and also extends the LBLEClient class to use the newABLEServiceInfo
struct:Upload the compiled code to a LinkIt 7697 HDK, connect to the same BLE peripheral as #90, and get the following output from Arduino Serial Monitor:
Scan the same device using the following node.js code:
And the output is:
Comparing the output of these two cases, it is obvious that the scan result got from the LBLE library lacks lots of 128-bit UUID characteristics. For services containing more than 2 characteristics with 128-bit UUID, at most two of them are returned.
However, if further extending the
LBLEClient
class by adding methods for descriptor discovery, one can find that those missing characteristics, along with some attribute used by ATT, will be returned when waiting forBT_GATTC_DISCOVER_CHARC_DESCRIPTOR
event after making abt_gattc_discover_charc_descriptor()
call, which by itself is another erroneous behavior of the LBLE library.It looks like something is not quite right in the FreeRTOS glue code used by LBLE library.