nRF5340 function bt_nus_send() taking 40ms to execute, how to speed up?

RE: nRF5340 function bt_nus_send() taking 40ms to execute, how to speed up?

afok-esmart — Thu, 25 Jan 2024 00:20:06 GMT

(OP replying here) It's been a while and the forum discussion has sort of steered towards ESB rather than BLE, so I thought I would suggest an answer to help answer my original question.

As Hung Bui reported, delays that are:

> 7.5ms can be achieved by lowering connection interval (but I never tried it personally)
> 2-3ms can be achieved by using BLE LLPM
- The '2-3ms' is a rough range; unfortunately I don't have the exact numbers on-hand
> (sub) 1ms can be achieved by using ESB (not BLE)

RE: nRF5340 function bt_nus_send() taking 40ms to execute, how to speed up?

Hung Bui — Thu, 11 Jan 2024 13:29:23 GMT

Hi Afok,
I haven't tested myself but have you made sure you use the same configuration on both sides PTX and PRX.
Also you may want to send packet with noack. You would need to set selective_auto_ack = true to noack to take effect.

There is a TX complete call back on the PTX that you can add to check if the packet is sent.

RE: nRF5340 function bt_nus_send() taking 40ms to execute, how to speed up?

afok-esmart — Thu, 11 Jan 2024 10:22:35 GMT

I did experiment with "use_fast_ramp_up" as well (most likely would use it for my project if I got it working, as I do indeed have control over both ends of comms). It did lower the time between packets to 0.25-0.3ms, but only if my PTX "tx_payload" had length 6 bytes or less.

It would stop working if the payload had more bytes (none of the LEDs on PRX would ever toggle). I still need to check if PTX is even sending them to begin with, and also see if PRX has anything else that makes it unable to serve the radio fast enough. Do you have any thoughts about what else I can try looking into?

RE: nRF5340 function bt_nus_send() taking 40ms to execute, how to speed up?

Hung Bui — Thu, 11 Jan 2024 10:11:51 GMT

Hi Afok,

You can crank it up even more by using use_fast_ramp_up in the ESB configuration.

This will select the fast ramping up mode of the radio, allowing it to have shorter latency. The only drawback is that it will make it not compatible with old device running normal ESB. So if you have control over both ends of the communication, you can use this mode.

RE: nRF5340 function bt_nus_send() taking 40ms to execute, how to speed up?

afok-esmart — Thu, 11 Jan 2024 09:24:20 GMT

Yes, I believe you're correct. Disabling PRX logging (w/ CONFIG_LOG=n) and turning off PTX success messages helped with that. I still saw PTX outputting "TX FAILED EVENT" but based on the logic analyzer, I believe it corresponds to longer time between packets that is needed when PTX retransmits the packet (since the LED sequence continues as normal i.e., the packet was not "lost"). I did also notice disabling PTX logging also helped a little more in allowing me to shorten the delay.

But at least for my project's purposes, and because I'm just quickly testing the fastest speed I can send packets/events, the "failed events" are fine for now. As an FYI, I was able to bring down the time between packets to as low as roughly 0.5ms, by primarily using k_sleep(K_USEC()) for that PTX delay. I also played around with ESB configuration options that may have helped, such as:

config.retransmit_count = 0; (in PTX, esb_initialize())
config.selective_auto_ack = false; (in PTX and PRX, esb_initialize())
config.retransmit_delay = 400; (in PTX, esb_initialize())
CONFIG_ESB_NEVER_DISABLE_TX=y (in prj.conf)

The above was indeed from using 2 nRF52840 DKs. Also happy to report that the code ran just as well on 2 nRF5340 DKs (build configuration set to use network core).

I'll need to investigate some of the more intricate details for ESB in the following days. I'll circle back to this post again if/once I have more questions or have come to a resolution.

RE: nRF5340 function bt_nus_send() taking 40ms to execute, how to speed up?

Hung Bui — Tue, 09 Jan 2024 14:03:56 GMT

Hi Afok,

Could you try disable logging ?

CONFIG_LOG=n

It could be that the PRX was too slow printing log on the content of the packet it receives that it couldn't serve the radio quickly enough.

I did a test here with k_sleep(K_MSEC(1)); and don't see any failed packet. You should turn off TX_SUCCESS printing out on PTX as well.

I assume you are testing using 2 nRF52840 DK ?

RE: nRF5340 function bt_nus_send() taking 40ms to execute, how to speed up?

afok-esmart — Tue, 09 Jan 2024 09:38:58 GMT

I'll get in touch w/ Mr. Obot; thanks for the contact info!

Sure. So if I changed the TX's k_sleep() call to delay 1ms, then connect the nRF Serial Terminal to the nRF52 w/ TX code, I'm seeing the terminal output usually alternate between "TX SUCCESS EVENT" and "TX FAILED EVENT" (seeing failed message roughly 50% of the time). I hooked up a logic analyzer to the LED GPIO pins of the nRF52 w/ RX code, and notice the LEDs not toggling at a regular interval (most of the time there's no activity, then some randomly-spaced toggling every couple seconds or so). Let me know if you need more details.

RE: nRF5340 function bt_nus_send() taking 40ms to execute, how to speed up?

Hung Bui — Mon, 08 Jan 2024 08:36:59 GMT

Hi Afok,

[quote user="afok-esmart"]Given my team's timeline, we are also considering using the nRF54. Do you have any updates on when and/or how we could get our hands on nRF54 eval. boards (at least 2 of them)?[/quote]

Please contact our local Sales representative for the request. If you are located in California please contact Mr. Mike Obot at: mike.obot [at] nordicsemi.no

Regarding the question with lower than 10ms interval. I would need to check with our expert in ESB. Please give us more detail on what's the error you see.

RE: nRF5340 function bt_nus_send() taking 40ms to execute, how to speed up?

afok-esmart — Fri, 05 Jan 2024 19:12:50 GMT

Thank you for the ESB info and suggestions! I will look into those some more to better evaluate ESB for our purposes.

Given my team's timeline, we are also considering using the nRF54. Do you have any updates on when and/or how we could get our hands on nRF54 eval. boards (at least 2 of them)?

-------

EDIT1: I also went ahead with just trying the ESB demo code (nRF Connect 2.5.0, path nrf\samples\esb). This time I tried nRF52 DK's instead of nRF53's, since that's what I had on hand at the time. But I tried manipulating the TX code's k_sleep() call to lower the delay, and the lowest I could get it without significant "failed events" is around 10ms. I'll keep investigating the code to see how I can optimize it more, but what would you recommend I do to lower that more?

RE: nRF5340 function bt_nus_send() taking 40ms to execute, how to speed up?

Hung Bui — Wed, 20 Dec 2023 14:25:11 GMT

Hi Afok,

There isn't a document that calculate the power consumption for ESB. You would need to look into the numbers in the product specification. The current consumption numbers are for radio activity in general, not just for BLE.

It can be difficult to calculate the power consumption by just looking at the number when the radio is transmitting (TX). You would need to calculate the ramp-up process the time it take to do transmission vs the time it's sleeping. My suggestion is to either to write some code and measure the current consumption directly. Or base on the online profiler made for BLE and do some calculation adjusting for your application.

Please be aware that when you do low latency with ESB, most likely the PRX (the one that receive) will have to stay in active RX all the time this will draw quite high current (for example 2.7mA for the radio).
On the TX side if you continuously transmitting at 1ms interval, you may also need to keep the HFCLK running all the time as the ramping up time for the HFCLK may take half a millisecond.

It's hard to achieve very low power consumption when doing very low latency. They don't come together.

RE: nRF5340 function bt_nus_send() taking 40ms to execute, how to speed up?

afok-esmart — Tue, 19 Dec 2023 18:12:21 GMT

Thanks for the connection parameter link and nRF53 LLPM status.

I took a look at ESB and it seems promising for what we need, but we would need to examine the power consumption. My team originally chose nRF53 because of its low power when using BLE, and we would like to prioritize low consumption in our application as well. I know the datasheet lists it out for BLE, but is there a document/website highlighting power consumption metrics for using ESB?

RE: nRF5340 function bt_nus_send() taking 40ms to execute, how to speed up?

Hung Bui — Tue, 19 Dec 2023 13:36:17 GMT

Hi Afok,

Regarding the question about changing the connection interval, I would suggest to go through our Academy course here: https://academy.nordicsemi.com/courses/bluetooth-low-energy-fundamentals/lessons/lesson-3-bluetooth-le-connections/topic/connection-process/

At chapter 3 we cover the connection parameter update.

[quote user="afok-esmart"]I took a look at the LLPM example, but after reading up on the README, I found the SoftDevice Controller info stating that "Low Latency Packet mode is not supported on the nRF53 Series". So then is achieving low latency on these nRF53's impossible then? From my limited understanding, SoftDevice is a library; would it technically be possible to write "our own library" (custom lower-level code) to make it happen?[/quote]

You are right. I forgot that the support for LLPM with NRF53 was removed. We have removed the support for it a few year back due to performance issue. You can take a look here: RE: LLPM on two NRF5340

We hope to get the feature into our next generation chip the nRF54.

You can take a look at our propriety protocol such as ESB for your application. It's more flexible with regard to the low latency communication. You can do ESB and BLE concurrently.

RE: nRF5340 function bt_nus_send() taking 40ms to execute, how to speed up?

afok-esmart — Mon, 18 Dec 2023 20:31:58 GMT

We are using the nRF's in a medical application; as such, we need the device to be operating essentially in real-time. That's about as much info as I can provide at this time.

I will need to investigate further on whether the multi-packet, 7.5ms latency setup is acceptable. Our 1ms delay restriction is only the external component/processor end's input, so we do have some flexibility with the wireless communication. Would you be able to point me to some examples that show how the connection interval can be changed please? I've checked a couple examples so far and haven't found anything yet. I think the interval change in the LLPM example also relates to HCI which seems specific to LLPM and not the typical BLE functions.

I took a look at the LLPM example, but after reading up on the README, I found the SoftDevice Controller info stating that "Low Latency Packet mode is not supported on the nRF53 Series". So then is achieving low latency on these nRF53's impossible then? From my limited understanding, SoftDevice is a library; would it technically be possible to write "our own library" (custom lower-level code) to make it happen?

--------

EDIT1: Additional question -do you anticipate support for LLPM on the nRF53 in the future?

EDIT2: More info on the application - this portion of BLE in the project is anticipated to be only for the nRF devices specifically. As we don't need to handle other devices, going for proprietary is definitely an option.

RE: nRF5340 function bt_nus_send() taking 40ms to execute, how to speed up?

Hung Bui — Mon, 18 Dec 2023 13:20:04 GMT

Hi,

Could you give us some more information about the application ?
Please beware that the minimum connection interval in BLE is 7.5ms. So if you want lower latency than that you would need to go for proprietary. In your case it's most likely the connection interval was 45ms.

Is it possible to combine multi packet in to one and processing them at 7.5ms latency ?

If the 1ms latency is a hard requirement, then you may want to take a look at our LLPM Bluetooth proprietary extension here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/bluetooth/llpm/README.html

It's made for applications such as gaming mouse or keyboard.