BLE notification takes too long

[Natan ALLARD]

Hello everyone,

I'm developing an application for an nrf52840 with the nrf connect VS Code extension.

The application runs three threads. One to acquire 40 bytes of data from a sensor at a frequency of 400Hz, another to process those data, and a third to send the result through BLE notifications.

It is important to note that I shouldn't lose the synchronization with the sensor for the processing but I can send the processed data slower. Therefore I configured the BLE like this : 

CONFIG_BT=y
CONFIG_BT_DEBUG_LOG=y
CONFIG_BT_PERIPHERAL=y

CONFIG_BT_USER_DATA_LEN_UPDATE=y

CONFIG_BT_ATT_PREPARE_COUNT=9
CONFIG_BT_BUF_ACL_TX_COUNT=9
CONFIG_BT_BUF_ACL_RX_SIZE=47
CONFIG_BT_CTLR_DATA_LENGTH_MAX=47
CONFIG_BT_L2CAP_TX_MTU=47
CONFIG_BT_BUF_ACL_TX_SIZE=47
CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT=7812

If my calculations are good, it should take 868µs to send a packet. But when I measure the time taken by the bt_gatt_notify it is around 20ms. 

This slows all of my processes and therefore makes the FIFOs which are in charge of passing the data from one thread to another filled very quickly.

The FIFO is filled like this : 

size_t size = sizeof(struct raw_tx_buf);
char *raw_mem_ptr = k_malloc(size);
__ASSERT_NO_MSG(raw_mem_ptr != 0);

memcpy(raw_mem_ptr, &raw_tx, size);

k_fifo_put(&raw_tx_fifo, raw_mem_ptr);

And read like this : 

struct raw_tx_buf *raw_buf = k_fifo_get(&raw_tx_fifo,K_FOREVER);

bt_gatt_notify(NULL,&mcd_svc.attrs[2],raw->raw_data,sizeof(raw->raw_data);

k_free(raw_buf);

If I can't make the notification function go faster, how can I prevent the overfilling of the FIFO which makes everything crash ?

Thanks in advance for your answer.

[PjGlasso]

I recall an automatic 10ms delay is added delay in BLE advertise to advertising packet to avoid collisions. So I would look there?

maybe just send the data or a sync with the advertising , or like a broadcast with a timestamp? 20ms seams like the minimum but someone else could chime in and clear that up. TIA ;-)

HTH

GL :-p

[Karl Ylvisaker]

You are correct that a random delay between 0 and 10 ms is added before every advertising to avoid consecutive collisions between advertising devices, but I do not get the impression that Natan intends to transfer the measurements using advertising packets since they mention that it is important that every measurement makes it across to the other device - which you can not guarantee with an advertisement (it is of course not guaranteed with a BLE connection either, but at least you will be notified if the transmission fail so that it will be tried again).

As you mention this advertising delay makes synchronization with an advertising device hard, since the exact time of the advertisements will drift a lot over time.

Best regards,
Karl

[Natan ALLARD]

Yes Karl is right, I am not sending the data with advertising.

But thank you for your answer.