cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Smart Bluetooth

legic_1490776
Contributor II

For our application we want to be able to download a larger amount of data from the tag upon request (>>22 bytes).

Is there a suggested best approach to doing this?

We're looking at designing the protocol based on the tag sending 4 notifications per connection event, with acks returned in a writable characteristic.

For this purpose it would be great to be gain more insight on how notifications work within the stack.

How large is the queue of unsent notifications in the stack?  Is there any way to find out how many unsent notifications are currently pending?  What happens if there is no room in the queue?


Is there any way to receive a callback to trigger after a notify is sent?

Is there any way to receive a callback when a connection event is over?


0 Likes
1 Solution
ArvindS_76
Employee

> 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.

View solution in original post

6 Replies
MichaelF_56
Moderator
Moderator

Lewis,

Is this still an issue, or was it answered in another post?

0 Likes
legic_1490776
Contributor II

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.

0 Likes
VictorZ_46
Employee

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.

0 Likes
legic_1490776
Contributor II

Thanks, victor.

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?

0 Likes
ArvindS_76
Employee

> 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.

View solution in original post

legic_1490776
Contributor II

THanks, this answers my questions.

0 Likes