New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some characteristics are missing if performing characteristic discovery with the LBLEClient class using LBLE library #91
Comments
I can reproduce this locally. I'll check with the underlying module owners for further investigation. From the error code, it seems that |
Instead of calling The attached modified version of The modified version above involves:
|
I can confirm that, with the "Multiple" variant of both the |
* #89: use `equal_range` when searching for elements in STL multimap, instead of using `find`. `find` is not guaranteed to return the first element in the equal range. * #90: Add a new set of interfaces to `LBLEClient` that allows user to identify a characteristic by using service index and characteristic index, instead of using UUID. Note that it is possible for a device to have multiple characteristics with the same UUID. * #90: Add a new example `EnumerateCharacteristic.ino` that uses the new indices-based interface of `LBLEClient` to list all the services and characteristics in the connected BLE device. * #90: Use `bt_gattc_read_charc` instead of `bt_gattc_read_using_charc_uuid` to read characteristics. * #91: when calling `bt_gattc_discover_charc`, we need to wait for multiple `BT_GATTC_DISCOVER_CHARC` event. We added new helper function `waitAndProcessEventMultiple` that supports such event waiting behavior. * Refactored `LBLEValueBuffer` to support re-interpreting its raw buffer content into String, float, int, and char types.
## Bug Fixes * #89: use `equal_range` when searching for elements in STL multimap, instead of using `find`. `find` is not guaranteed to return the first element in the equal range. * #90: Add a new set of interfaces to `LBLEClient` that allows user to identify a characteristic by using service index and characteristic index, instead of using UUID. Note that it is possible for a device to have multiple characteristics with the same UUID. * #90: Add a new example `EnumerateCharacteristic.ino` that uses the new indices-based interface of `LBLEClient` to list all the services and characteristics in the connected BLE device. * #90: Use `bt_gattc_read_charc` instead of `bt_gattc_read_using_charc_uuid` to read characteristics. * #91: when calling `bt_gattc_discover_charc`, we need to wait for multiple `BT_GATTC_DISCOVER_CHARC` event. We added new helper function `waitAndProcessEventMultiple` that supports such event waiting behavior. * Refactored `LBLEValueBuffer` to support re-interpreting its raw buffer content into String, float, int, and char types.
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.
The text was updated successfully, but these errors were encountered: