You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/Usage_tips.md
+37-5Lines changed: 37 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,11 +1,8 @@
1
1
# Usage Tips
2
2
3
-
## Put BLE functions in a task running on the NimBLE stack core
3
+
## Threadsafety
4
4
5
-
When commands are sent to the stack from a different core they can experience delays in execution.
6
-
This library detects this and invokes the esp32 IPC to reroute these commands through the correct core but this also increases overhead.
7
-
Therefore it is highly recommended to create tasks for BLE to run on the same core, the macro `CONFIG_BT_NIMBLE_PINNED_TO_CORE` can be used to set the core.
8
-
<br/>
5
+
This library is threadsafe. Attribues can be manipulated freely.
9
6
10
7
## Do not delete client instances unless necessary or unused
11
8
@@ -32,6 +29,41 @@ or nullptr such as when calling `NimBLEClient::getService`. The latter being a
32
29
Most of the functions in this library return something that should be checked before proceeding.
33
30
<br/>
34
31
32
+
## Persisted bonds can be lost due to low MAX_CCCDS
33
+
34
+
The symptom: CONFIG_BT_NIMBLE_MAX_BONDS is set to N, but a smaller number of bonds is preserved, perhaps even a single bond. The limitation of persisted bonds can be observed via NimBLEDevice::getNumBonds(). The number may not reach CONFIG_BT_NIMBLE_MAX_BONDS.
35
+
36
+
Cause: For each bond, NimBLE persists each of the CCCD (client characteristic configuration descriptor) values that have been subscribed
37
+
to by the client. If CONFIG_BT_NIMBLE_MAX_CCCDS is too low, the older CCCD values are overwritten by the newer ones. The loss of the older
38
+
CCCDs values results in those bonds being lost.
39
+
40
+
Fix: Increase CONFIG_BT_NIMBLE_MAX_CCCDS. These take approximately 40 bytes in NVS, 2 bytes for the CCCD value and the NVS metadata overhead. The value of
41
+
CONFIG_BT_NIMBLE_MAX_CCCDS should conservatively be no less than (CONFIG_BT_NIMBLE_MAX_BONDS * {maximum number of characteristics that can be subscribed to}).
42
+
43
+
## Device 'Local Name'
44
+
45
+
'Local name' refers to how the device is seen and displayed.
46
+
47
+
A devices 'Local name' can be thought of as coming from two places, the <i>Advertising "Local name"</i> and the <i>the GATT Device Name</i>.
48
+
49
+
### Advertising "Local name"
50
+
51
+
Field found in the advertising data payload. Value is set via NimBLEAdvertising::setName().
52
+
53
+
### GATT Device Name
54
+
55
+
Characteristic UUID 0x2A00 in the Generic Access service. Set via NimBLEDevice::init() or NimBLEDevice::setDeviceName().
56
+
57
+
This characteristic is read <b>after</b> connecting to the device.
58
+
59
+
### Important considerations
60
+
61
+
* OSes cache the <i>'GATT Device Name'</i>.
62
+
* OSes update the device name based on the <i>'GATT Device Name'</i> after connecting to a device. This means that if you set the <i>Advertising 'Local name'</i> to "ABCD" but the <i>'GATT Device Name'</i> to "12345", the device will be seen as "ABCD" until connecting to the device, at which time the devices name will change to "12345".
63
+
* If no <i>'Advertising "Local name"'</i> is set, OSes, such as iOS, may display the devices name as 'Unnamed' until the device is connected to, at which time the <i>'GATT Device Name'</i> is read and used instead.
64
+
65
+
It is recommended that both <i>'Advertising "Local name"'</i> <b>and</b> <i>'GATT Device Name'</i> be set appropriately, after considering the above described behavior.
66
+
35
67
## There will be bugs - please report them
36
68
37
69
No code is bug free and unit testing will not find them all on it's own. If you encounter a bug, please report it along with any logs and decoded backtrace if applicable.
0 commit comments