Controlling connect event duration as an alternative to lack of LLPM support in nRF5340

[JustinL]

Hi,

As I understand it, LLPM does not currently work on nRF5340 reliably at all (is that correct or does it work well if 1ms interval is increased to something larger?).

We are currently being forced to move from nRF52840 to nRF5340 due to compliance issues. So staying on nRF52840 is not possible.

Our use case makes heavy use of LLPM mode to enable low latency data transmission from 10 peripherals to one central. It works great on nRF52840.

We actually do not need to send data from each peripheral more often than every 10ms. But we do need 10 devices doing this every 10ms therefore connect events need to be short (1ms ideally).
So we are currently using LLPM to manage the connection event duration down to 1ms in nRF52840. 

LLPM not working on nRF5340, and not having any timeframe or guarantee that it will even ever work (maybe the new network core is too slow for this coupled with interprocessor comms??),  is a big problem for us.

So it is worth us considering if there are other methods of getting achieving the same result.

Is it possible to configure the connection event duration separately from the connection interval e.g. set a maximum event duration of 1ms? So that we can set a connection interval of 10ms but still achieve 10 separate connection events in that 10ms period. The hope is that the scheduler takes into account this configured 1ms event duration and arranges separate connections every 1ms. Each peripheral will still only be contacted once every 10ms.

Feels like a long shot but this is a big issue for us. The product simply will not work without finding a workaround (or LLPM mode being supported).

Thanks in advance,

Justin

[Susheel Nuguru]

Hi Justin,

As far as i know all the known issues in the LLPM with nRF53 were addressed and the example for LLPM is working as intended (according to the internal discussion logs) . Could you please be more specific on what you mean "LLPM not working on nRF5340".

[JustinL]

Hi Susheel,

On this thread, from initially 4 months ago, Einar Thorsrud (Nordic Support Engineer) said "It turns out that LLPM does not work properly on the nRF53 yet, and it is still unsupported. " and reiterated just 2 months ago with "Hi. There is no change yet, and LLPM is still not performing as well with the nRF5340 as with nRF52840. This will not change in the next nRF Connect SDK release. I cannot say when this will be improved" 

and a github pull request from Jun:
"

LLPM is not supported on nrf5340 and this sample does not run on
nrf5340. Remove support for it.

Signed-off-by: Jan Müller [email protected]"

Combined with our own experience of it not working reliably (see below) led us to believe that it is not currently supported and in fact, may never be supported.

If it is in fact supported and should work that would be great, really great!!
It would be useful to know therefore definitely what the state of play is because it will be worth putting in a lot of effort debugging in detail if others have it running fine. In fact, if it should work we can start by trying the sample LLPM app and seeing if that works. 

If it is not going to be supported ever then this is a big problem and a massive step backward in latency. Or are there workarounds?

This is our issue: 

We have ported our firmware from nrf connect sdk 1.3.1 running on nrf52840dk to nrf connect sdk 1.6.1 running on nrf5340dk.

Everything has ported very well. 

Except that now when we start 1ms LLPM comms, the first 50 notify exchanges are fine then central stops calling our notify call back function even though the peripheral still has notify data waiting for central to pick up.

(We originally had an issue like this on nrf52840 and your engineers suggested a number of heap and other zephyr config options which fixed the instability - maybe there is tuning needed here??)

If there has been a recent fix, maybe we need to work from master rather than sdk 1.6.1.

Thanks,

Justin

[Susheel Nuguru]

Hi Justin,

Thank you for very clear pointers. It was my mistake NOT to see the latest updates on the internal logs (on a different thread). I apologize for that miss.

Yes on nRF53 there seems to performance issue when using minimal time of 1ms for LLPM interval. The reason is that the network core seems to be very occupied when using LLPM and/or QoS. There are a lot of cache miss happening which contributes to some performance issues at that low connection interval. This is not easy to fix on a dual core devices as this involves some non trivial changes on the architectural level. 

In short, the LLPM is not production quality tagged because of these performance issues and the issues you are seeing are known internally to the BLE controller team. The fixes are not on the near roadmap and I strongly suggest you to talk to your local Regional Sales Manager to see if they can prioritize working on these fixes.

[JustinL]

Hi Susheel,

Thank you for confirming that.

Are you able to ask the BLE team if running the whole BLE stack on the net core fixes the problem? We could then write our own net core code and send just the data we need across to the app core.

Also, are there are thoughts on the question of using short connection event duration as per my first question that started the support ticket?

Thanks,

Justin

[Susheel Nuguru]

Hi Justin,

We do not have any testing that validates the performance other than for 1ms CI -- which fails (DRGN-15135). We do however believe that the problem will be that the BT host will not be able to fetch and send data fast enough, causing empty packets/NACKs some connection events. You can try to increase the number of controller data buffers, run both host+controller on network core and look for other optimizations. But these suggestions are based on our understanding and NOT the test data. So unfortunately you can try to use these pointers to see if there is some improvement but the official fix comes from us at a later point after some deep architectural optimizations. We do not know the timelines of this yet.