Is this still an issue, or was it answered in another post?
This has never been answered to my knowledge.
Based on our experiments it appears that after sending 4 notifications, further notifications are silently dropped.
If there is only buffer space for 4 notifications, is that a global limit or per-characteristic?
It would be great to have confirmation on exactly what happens in this case, and if there is a recommended way to avoid it. Because of the need for some sort of flow control via responses from the master, it's very difficult to put 4 packets in each connection interval.
It would also be nice if there was a way to query the stack to find out how much buffer space remains (i.e. if 1 notify has been sent and there are 3 more slots, assuming that is how it works).
Is there any way to receive a callback after a connection interval has passed?
In that case we might be able to queue up 4 more notify packets so they are ready to go on the next interval.
If you are using SDK 2.x, please check speed_test application. There are several modes/tests, but in
TEST_NOTIFICATIONS mode the device sends notifications as fast as possible.
You can check number of available buffers using blecm_getAvailableTxBuffers() function. I think it is 14. And you are right, if you try to send a notification when there are no buffers, it will silently fail.
Unfortunately as I am using the 20732S module, I cannot use SDK 2.0. (Is this correct?)
However perhaps the example from the 2.0 SDK might still work if it does not rely on new API calls.
I'll try blecm_getAvailableTxBuffers() and see what it reports.
Any idea whether there's a callback after a connection interval completes?
1 of 1 people found this helpful
> Any idea whether there's a callback after a connection interval completes?
Not in SDK 1.1.0. There is an optional API available with SDK 2.0 where you can register a callback that will be invoked either right before or right after the connection event. However, this is not available in SDK 1.1.0.
> In that case we might be able to queue up 4 more notify packets so they are ready to go on the next interval.
When a slave, there is no guarantee that the master will poll multiple times in a connection interval, even when the MD bit in the header of the notification packet is set because the master could have other tasks (scans/advertisements/other connections - classic or low energy). So the best way is to check with the stack using blecm_getAvailableTxBuffers().
> However perhaps the example from the 2.0 SDK might still work if it does not rely on new API calls.
Yes, you should be able to port most of the speed_test sample app to SDK 1.1.0, except the part where it stuffs the notifications with using ulp_getRand(), which is not available in SDK 1.1.0. But you should be able to generate some other sequence of data in its place.
THanks, this answers my questions.