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]

Hello,

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. 

To easily verify the on-air time it will take to send a packet you can use the Online Power Profiler, for instance :) 
The reason why you are seeing 20 ms here is likely that it is the Connection Interval used for the connection where the data is sent.
The shortest possible Connection Interval for BLE communication is 7.5 ms, which would mean that you on average will send 120 bytes every connection event (7.5 ms).
Your buffer will need to be able to store this, and potentially some additional packets of this size in case multiple packets of this size suddenly is sent in a single connection event due to a previous packet loss, for instance. 
How large is your receiving buffer currently?
Is this a central or peripheral device you are developing?

Best regards,
Karl

[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]

Hello, thank you for your answer.

I thought I configured the connection interval to be 7812us (which I believe is the time to let 9 packet be exchanged on each connection event) with CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT. Is it the right way to do it ?

My device is a peripheral and I use the Nordic connect mobile app as a central. Therefore I don't know the size of the app buffer. 

Best regards,

Natan 

[Natan ALLARD]

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

But thank you for your answer.