Re: RP2040 - Indication missing confirmation -

[Matthias Ringwald]

Hi Nikolas

BTstack is single-thread by design, so its API should only be called from the main / Bluetooth thread.
In that case, nothing will happen if you poll att_server_can_send_packet_now() - in fact, I would expect it to block/hang forever.

To send a notification, please request a callack with att_server_request_to_send_notification and send it from the callback.
To send an indication, please request a callback with att_server_request_to_send_indication and send it from the callback.
If you follow this scheme, all notifications and indications should be delivered correctly.

Cheers
Matthias

> On 21 Mar 2025, at 10:45, 'Nikolas von Lonski' via btstack-dev <btsta...@googlegroups.com> wrote:
>
> Hi,
> We recently update from Pico-SDK 1.7 to 2.1.1
>
> As it turns out there must have been some change somewhere in the mix which broke the way our BLE implementation worked.
>
> The way we schedule our notifications/indications is as follows:
> while ( !l_notification_scheduler.force_quit ) {
> // Wait for a pending notification
> if (!DECREMENT_NOTIFICATION_COUNT(NOTIFICATION_POLL_RATE_MS)) {
> // We don't have any pending notifications
> continue;
> }
>
> // Wait for a notification slot
> DECREMENT_SLOT_COUNT();
>
> while ( !l_notification_scheduler.force_quit &&
> !att_server_can_send_packet_now(l_context_ptr->connection.handle) ) {
> vTaskDelay(pdMS_TO_TICKS(5));
> }
>
> if ( l_notification_scheduler.force_quit ) {
> INCREMENT_SLOT_COUNT();
> continue; // while loop check will exit
> }
>
> // Request a notification slot
> att_server_request_can_send_now_event(l_context_ptr->connection.handle);
> }
>
> We have various notifications competing for radio time and of course writes can also take place.
>
> In the previous version we never had an issue with indications simply getting lost. In the current version this appears to be the case.
>
> Now there are multiple updates that are interrwined. Upgrade to RTOS v11 main from the smp branch.
> Update to the next major Pico-SDK (with minors).
> Update of the BTStack. All of them needing to be updated at the same time.
>
>
> My intutition tells me it's some kind of scheduling issue with the BTStack.
>
> What do you think?
>
> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to btstack-dev...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/btstack-dev/e5410c46-d78a-414b-8713-ab5a15fc965an%40googlegroups.com.

[Nikolas von Lonski]

Hi Mathias,

Thanks for the reply :grin:
Just to clarify.
We have a dedicated thread polling to see if a packet can be sent now and if yes we request the ATT_CAN_SEND_NOW event. (at least that is how I understood it)
This event is passed into our callback which finally calls our send_indication / send_notification.
After your reply I found out this API is deprecated.

We need this design because we split our packets over multiple indications when doing large transfers.
Your suggesting providing two distinct callbacks one for notification, one for indication, independently.
And the BTStack should handle ordering/handling if its getting hammered from different threads requesting these callbacks? Even from a different core?
I will try and refactor to see if that fixes it. :smile:

As per documentation:
--- page 69
Finally, in order to send Notifications and Indications independently from
the main application, att server register can send now callback can be used to
request a callback when it’s possible to send a Notification or Indication.
---

[Matthias Ringwald]

Hi Nikolas

BTstack isn' thread-safe (by design). Please move all Bluetooth logic to the "main" thread - this is the thread that receives all events / packets from BTstack.
If you have different threads that require Bluetooth operations, you could use a thread-safe queue and post into that queue from any thread at any time,
with the 'main' thread processing this queue. You can also use btstack_run_loop_execute_on_main_thread to schedule a callback to a function by the 'main' thread.

A Notification can be sent any time there's space on the Bluetooth Controller. An Indication needs to wait for the previous Indication to get acknowledged.
If you want to simplify your logic, you can send Notifications from the callback registered with att_server_request_to_send_indication (it's just slower..)

You can register as many callbacks with att_server_request_to_send_notification as you have btstack_context_callback_registration_t structs available.
I suggest to have a single one and in that callback always just send the next one.

Cheers
Matthais

> To view this discussion visit https://groups.google.com/d/msgid/btstack-dev/fb9bcfbe-1a31-4962-8f05-3dcb2c93f27fn%40googlegroups.com.