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,

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.

[JustinL]

Okay, thank you for the ideas to try.