Problem with large CIG

RE: Problem with large CIG

Karl Ylvisaker — Mon, 13 Feb 2023 16:15:51 GMT

Hello again, Chris

Thank you for your extreme patience with this.
I have been out of office for some time, but now I am back.

You can configure the maximum data length using the CONFIG_BT_CTRL_DATA_LENGTH_MAX kconfig, or you could also use the CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT to dictate the length of each connection event.

[quote user="cstjohn"]perhaps there was a change to avoid assigning >100% radio time?[/quote]

I have not heard any such change being necessary, but it would be good to hear what you find when you reduce the air time used by the ACLs.
In general, this should make things easier for the scheduler, which in turn might make the connections more stable.

We recently also merged a new controller version, 3322, which comes with some optimization of the scheduler in regards to the scheduling of concurrent ACLs and ISOs, which you might be interested in checking out.
There is no rpmsg change necessary between 3310 and 3322, so you could just swap it for the 3322 to see if the situation improves for your use-case.

Best regards,
Karl

RE: Problem with large CIG

cstjohn — Mon, 13 Feb 2023 10:16:46 GMT

any progress on this? How should I disable Data Length Extension to avoid 2xACLs using so much radio time?

RE: Problem with large CIG

cstjohn — Wed, 25 Jan 2023 08:50:53 GMT

I think I may be starting to understand what is going on.

2x 240 bytes @10ms with NSE=3 doesn't appear to overload the channel, but with additional 2x ACL using Data Length Extension I think it does. Reducing to NSE=2 works on both 3303 and 3307.

Still not sure why 3303 behaves differently from 3307 in this respect; perhaps there was a change to avoid assigning >100% radio time?

How could I disable Data Length Extension (assuming it is enabled...) to test if this really is the problem?

RE: Problem with large CIG

cstjohn — Fri, 20 Jan 2023 15:12:30 GMT

NRF-SDK version is 2.1.99, snapshot on Nov 21 2022 https://github.com/nrfconnect/sdk-nrf/commit/4ea03df1aba9763661c5ee1daccf02ccf32fc436

The application is based on nrf5340_audio

3303:

3307:

as you can see, with 3307 the second CIS isn't requested and both peripherals timeout after 4s. I see similar results with 3310.

Thanks,

Chris

RE: Problem with large CIG

Karl Ylvisaker — Fri, 13 Jan 2023 14:25:45 GMT

Hello,

[quote user=""]* 1 CIS with 240 byte payload works fine with fw 3307[/quote]

I assume you meant to write 1 CIG here, is that correct?

[quote user=""]Is there some regression in 3307[/quote]

There should be no regression on this, no.
Which nRF Connect SDK version are you working with, and could you elaborate exactly on how it fails when you try to establish the CIG, compared to how it worked when you did the same with the 3307 controller?

Best regards,
Karl