Problem with large CIG

[cstjohn]

I'm creating a CIG with two CIS each carrying 240 byte payloads. It worked fine with NET fw 3303 but has stopped working with NET fw 3307

* 2 CIS with 120 byte payload works fine with fw 3307

* 1 CIS with 240 byte payload works fine with fw 3307

Is there some regression in 3307 or a setting I need to give with the new firmware?

Thanks,

Chris

[Karl Ylvisaker]

Hello,

* 1 CIS with 240 byte payload works fine with fw 3307

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

Is there some regression in 3307

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

[cstjohn]

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

[cstjohn]

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?

[cstjohn]

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

[Karl Ylvisaker]

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.

cstjohn said:

perhaps there was a change to avoid assigning >100% radio time?

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