RE: Questions regarding BLE notifications sending in loop

fr_adv — Thu, 31 Oct 2024 10:13:55 GMT

Hello M. Nuguru,

Thanks for the explanations. Just remains a questionable point about this statement :

"Instead, if there are no free buffers, the bt_gatt_notify_uuid call will just return an error, basically saying, “Hey, I’m out of space to send more data right now.” "

I think this is contradiction to the next paragraph about the BLE stack and Zephyr. Moreover, I don't see any error log with the snippet in my previous comment.

The delays are not an issue in my case, it's perfectly clear to me that the data shall be actually sent on the radio link, and acknowledged by the BLE peer (link layer + L2CAP I guess) before filling up BLE stack buffers again and sending more notifications.

Thanks again for your feedback
Best regards

Aurélien

RE: Questions regarding BLE notifications sending in loop

Susheel Nuguru — Thu, 31 Oct 2024 09:38:41 GMT

When you call bt_gatt_notify_uuid in a loop, the BLE stack tries to send out each notification using a set of buffers it has for data transmission. Now, you’ve got only a few of these buffers (BT_L2CAP_TX_BUF_COUNT=3 and BT_BUF_ACL_TX_COUNT=3), and they fill up pretty quickly. But the thing is, the BLE stack doesn’t just freeze your thread when all the buffers are in use. Instead, if there are no free buffers, the bt_gatt_notify_uuid call will just return an error, basically saying, “Hey, I’m out of space to send more data right now.”

You’d think that running this in a high-priority thread would hog all the CPU or that it would trigger the watchdog, but that’s not the case. Here’s why:

The BLE stack works asynchronously. It sends out the data over the air, and once a buffer is freed up (when the notification is sent), it becomes available for the next notification. This means your loop isn’t blocking everything — it just waits until there’s space again.
Zephyr, the real-time operating system you’re using, is pretty clever. Even though your thread has a higher priority, the system uses preemptive multitasking. If your thread can’t do much because it’s waiting for buffers to free up, the system lets lower-priority threads (like your main thread that keeps the watchdog happy) run in the meantime. So, your main thread can still do its job, like resetting the watchdog, and everything stays stable.

Sometimes you’ll notice delays between notifications, and that’s because the BLE stack needs time to send out the data and free up buffers. Your loop doesn’t explicitly wait or yield, but the BLE stack and Zephyr handle this behind the scenes, keeping things from locking up. It is not very straightforward to explain the exact delays as it depends on many things as timings of the application thread and isr context/priorities/pre and post processing. All of these influence the times.