BLE notification takes too long

RE: BLE notification takes too long

Karl Ylvisaker — Thu, 19 Jan 2023 08:09:27 GMT

[quote user="Natan ALLARD"]I finally managed to fix my problem by changing the way I put the data in the FIFO, instead of using k_malloc I used k_fifo_alloc_put and it seems to be fixed.[/quote]

Great, I am happy to hear that you were able to resolve the issue! :)

[quote user="Natan ALLARD"]Thank you for your help and all the information you gave me.[/quote][quote user="Natan ALLARD"]In any case everything you told me was very helpful to optimize the application.[/quote]

It is no problem at all, I am glad that you found the information helpful! :)

Please do not hesitate to open up another ticket if you should encounter any other issues or questions in the future.

Good luck with your development!

Best regards,
Karl

RE: BLE notification takes too long

Natan ALLARD — Wed, 18 Jan 2023 15:34:54 GMT

Thank you for your help and all the information you gave me.

I finally managed to fix my problem by changing the way I put the data in the FIFO, instead of using k_malloc I used k_fifo_alloc_put and it seems to be fixed.

In any case everything you told me was very helpful to optimize the application.

Best regards

RE: BLE notification takes too long

Karl Ylvisaker — Wed, 18 Jan 2023 13:10:01 GMT

[quote user="Natan ALLARD"]Yes sorry If I wasn't clear. The I can see logs prior to the crash. When i activate the notification it sends some of the data (I know because I see it on the nrf mobile app and because I print logs) then it crashes.[/quote]

No need to apologize, I will just ask if anything is unclear :)

Great to know that you are able to see logs up until the crash. Have you added any local error handling to the notify function call?
For starters, you could add some logging to alert you in the case that the notify function call fails.

[quote user="Natan ALLARD"]I understand the ring buffer but isn't it similar to the FIFO I implemented ?[/quote]

Yes, the difference between the ring buffer and the FIFO is that the ring buffer will start to overwrite itself instead of overflowing, in the case that data is starting to back up significantly. This way, you could avoid crashing due to the buffer overflowing, for instance.

[quote user="Natan ALLARD"]I need to send them in a consecutive order.[/quote]

Thank you for clarifying. Does the data ever 'time out'? I.e is there ever a time threshold where 'old' data no longer will be useful?
If so, then that threshold could be used as a natural limitation on the FIFO buffer size.

Best regards,
Karl

RE: BLE notification takes too long

Natan ALLARD — Wed, 18 Jan 2023 07:21:12 GMT

Yes sorry If I wasn't clear. The I can see logs prior to the crash. When i activate the notification it sends some of the data (I know because I see it on the nrf mobile app and because I print logs) then it crashes.

I need to send them in a consecutive order. I understand the ring buffer but isn't it similar to the FIFO I implemented ?

Thank you,

RE: BLE notification takes too long

Karl Ylvisaker — Wed, 18 Jan 2023 07:12:28 GMT

[quote user="Natan ALLARD"]I am not seeing any log at all when it crashes.[/quote]

Yes, but are you seeing logs prior to the crash? Are you seeing any logs at all?

[quote user="Natan ALLARD"]And I think I understand but what can I do to fix this?[/quote]

The best approach to this depends on how important it is whether every sensor measurement makes it across to the peer or not - will the sensor data ever time-out, or stop being useful to the central, or should all data be sent in consecutive order and if it can not then the connection should be terminated?
In case of the latter I would recommend implementing a ring buffer as mentioned in my previous comments.

Best regards,
Karl

RE: BLE notification takes too long

Natan ALLARD — Tue, 17 Jan 2023 09:08:52 GMT

Thank you for these information.

I am not seeing any log at all when it crashes.

And I think I understand but what can I do to fix this?

RE: BLE notification takes too long

Karl Ylvisaker — Tue, 17 Jan 2023 07:44:53 GMT

[quote user="Natan ALLARD"]I don't manage to get any error code printed even though I have indeed activated the logging with[/quote]

Is it just the error code that is missing from the logs, or are you not seeing any logs at all?

[quote user="Natan ALLARD"]So after sending there shouldn't be data anymore on the peripheral.[/quote]

Yes, but in the case of a transmission that is not acknowledged (such as if a packet is dropped) then the data is not deleted until the packet is acknowledged by the peer.
So the device will keep trying to send the same packet until it either succeeds, or the connection times out.
In the latter case it will keep trying to send the same packet until the Connection Supervision Timeout occurs, which in the mean time would have filled up the ring buffer with unsent sensor samples.

Best regards,
Karl

RE: BLE notification takes too long

Natan ALLARD — Mon, 16 Jan 2023 12:21:09 GMT

I don't manage to get any error code printed even though I have indeed activated the logging with

CONFIG_LOG=y
CONFIG_LOG_PRINTK=y
CONFIG_DEBUG_THREAD_INFO=y

CONFIG_BT=y
CONFIG_BT_DEBUG_LOG=y

RE: BLE notification takes too long

Natan ALLARD — Mon, 16 Jan 2023 12:18:33 GMT

Yes, from what I understood when the FIFO is read, the data is supposed to be removed from it. And after sending the data I use k_free to free the memory of the allocated before with k_malloc.

So after sending there shouldn't be data anymore on the peripheral.

RE: BLE notification takes too long

Karl Ylvisaker — Mon, 16 Jan 2023 12:07:47 GMT

Yes - you can change this to match the requirements of your application.
But, assuming 4 s Connection Supervision Timeout means that you could potentially have 40*400*4 = 64 kB of unsent data when the connection times out.
In the worst case scenario (with a really poor connection) you could only be getting through a packet every ~4s, which could cause your ring buffer to overflow as well, but in this case the connection is basically lost for all communication purposes.

Does the data ever 'expire'? / does there ever come a point from which the data no longer is useable to the central?
If so, you should change the supervision timeout to match this requirement, or have the ring buffer start to overwrite unuseful data as soon as this happens.

Best regards,
Karl

RE: BLE notification takes too long

Natan ALLARD — Mon, 16 Jan 2023 10:54:01 GMT

Ok i see, the connection supervision timeout is still at default value so 4s I guess.

RE: BLE notification takes too long

Karl Ylvisaker — Mon, 16 Jan 2023 10:50:32 GMT

Do you have logging enabled for your project?
If so, the error code should be printed before it resets due to the returned error.
You could then implement local specific error handling for the function that returns the error.

I would then also recommend considering to create a ring buffer that can be used to cache the sensor data that fails to be queued, so that you do not loose it.
This buffer should be big enough to accommodate all the data that could build up before the connection supervision timeout occurs.
Dropped packets are also the reason why you should make sure that your connection event length is longer than what is needed to send a single sensor measurement, since you might need to re-send built-up packets from previously lost packets in addition to the new samples.
How long is the duration of the connection supervision timeout in your application?

Best regards,
Karl

RE: BLE notification takes too long

Natan ALLARD — Mon, 16 Jan 2023 10:09:05 GMT

Ok thank you I understand better and after reading zephyr documentation it says that the default connection interval is 30ms so that matches.

Regarding the buffer overflow, I don't really see it because it crashes down and reboot when I try to send the data.

I tried with a lower acquisition frequency and it goes without a problem. that's what led me to think the buffer is overflowing because it gets filled faster than the sending function can empty it.

RE: BLE notification takes too long

Karl Ylvisaker — Mon, 16 Jan 2023 10:01:37 GMT

[quote user="Natan ALLARD"]MAX_CONN_EVENT_LEN_DEFAULT[/quote]

Connection event length is indeed the length available in a single connection event, but the time between each of these events are determined by the Connection Interval, which is part of the connection parameters, so it is the Connection Interval that has the biggest impact on the latency here.

[quote user="Natan ALLARD"]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. [/quote]

Thank you for clarifying.
By this do you mean that you are seeing the buffer overflow on the central side?
Or is the issue that the call to queue the data for sending on the peripheral side fails due to the buffer overflow? If so, what exactly does the log say when this happens?

Best regards,
Karl

RE: BLE notification takes too long

Natan ALLARD — Mon, 16 Jan 2023 08:05:19 GMT

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

But thank you for your answer.

RE: BLE notification takes too long

Natan ALLARD — Mon, 16 Jan 2023 08:02:55 GMT

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

RE: BLE notification takes too long

Karl Ylvisaker — Mon, 16 Jan 2023 07:51:32 GMT

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

RE: BLE notification takes too long

Karl Ylvisaker — Mon, 16 Jan 2023 07:47:08 GMT

Hello,

[quote user=""]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. [/quote]

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

RE: BLE notification takes too long

PjGlasso — Fri, 13 Jan 2023 20:58:43 GMT

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