ESP32: BLE rapid NOTIFY -> OSError: [Errno 12] ENOMEM

[stephanelsmith]

When pushing data throug BLE using notify, I eventually run into "OSError: [Errno 12] ENOMEM". I'm able to work-around by catching the error, doing a short asyncio.sleep_ms(), and then trying again, rinse/repeat. This seems to be my main throughput limitation at the moment.

Quick search in modbluetooth_btstack.c seems to indiciate that data was failed to copy at that instant.

// GATTS Notify/Indicate (att_server_notify/indicate)
// * When available, copies buffer immediately.
// * Otherwise fails with BTSTACK_ACL_BUFFERS_FULL

Is there anything over or under the hood to be done here? Or are there any knobs or tricks out there to push BLE throughput?

I'm running with MTU 515 (thanks to #9369 commit). I'm trying to maximize ble throughput, especially as the esp32-s3 should be BLE 5.0!

[jimmo]

@stephanelsmith
Are you in control of both sides of the connection? Using L2CAP Connection-oriented-Channels is a much better alternative for streaming data. They are supported aioble too.

[andreamerello]

FWIW, I'm hitting the very same problem on a stm32 (micropython 1.19.1, custom board, recompiled from sources), but here the sleep & retry doesn't help :(

[jimmo]

(@andreamerello I think we discussed this on Discord, but replying here so others can see it -- @stephanelsmith FYI)

There needs to be flow control such that the notification has a chance to send, and the scheduler needs a chance to run the host stack for each notification. Ensure you do not sleep in a scheduled task, and in general keep the use of scheduled tasks to a minimum (see https://docs.micropython.org/en/latest/reference/isr_rules.html -- the same guidance applies to scheduled tasks). Using asyncio (and aioble) can help a lot here.

In general you must have some way to know the notification has been received before sending the next one. You can tweak build options in NimBLE to allow more than one outstanding notification (and increase the "window size" correspondingly) but this is a throughput optimisation rather than just making it work.

To my knowledge the best way to maximise throughput using GATT notifications is to notify-with-data (i.e. do not write the characteristic first, only notify it), and then issue a write from the client to signal reception.

That said, it's much better to use L2CAP CoC for this purpose because the flow control is built in.

[tsiens]

@stephanelsmith May I ask if you have resolved it，I use ble notify to send gyroscope data -> OSError: [Errno 12] ENOMEM，I guess the data generated by the gyroscope is faster than the nofity speed