Maintain ACL connection while receiving BIS

[gocchan]

Hello, 

I am trying to develop a LE Audio product with a system like the attached image.

Both BIS and ACL are sometimes successful, but often the ACL disconnects.

According to debug messages, the disconnect reason at that time is both BT_HCI_ERR_CONN_TIMEOUT.

So I don't think one of them got reset.

Are there conditions for maintaining both BIS and ACLs? (For example, the relationship between ISO Interval and Connection Interval.)

Regards, 

Gotoda

[Karl Ylvisaker]

Hello Gotodo,

The reason for this could be that there is overlap between the BIS and ACL events, which leads to one of the devices not responding for a long enough time to trigger the connection supervision timeout.
Just for clarity, which bitrate is the BIS using, and how many retransmits are you using?

In general, we recommend that the ACL connection interval is a 2x multiple of the ISO interval, which is 10 ms in the nrf5340_audio application. What ACL connection interval were you using in your tests?
We are also aware of an instability in the current LE Audio Controller when the ACL connections are updating their connection parameters while the ISO is active. I would therefore recommend that you finish all the parameter negotiations of the ACL link before you open up the BIS.

Please try this, and let me know if you still are seeing an issue.

Best regards,
Karl

[gocchan]

Hi, 

BLE_ACL_CONN_INTERVAL is 80 (100ms).

Bitrate is 96 kbps.

BLE_ISO_RETRANSMITS is 2.

I call le_audio_enable() after "Security changed".

How do I know the finish of all ACL negotiations?

Regards, 

Gotoda

[Karl Ylvisaker]

Hello Gotoda,

Thank you for elaborating.

As a test, could you check whether the stability of the link increases if you decrease the BIS bitrate?
Just to see whether the issue is affected by scheduling conflicts or not.

gocchan said:

I call le_audio_enable() after "Security changed".

How do I know the finish of all ACL negotiations?

The initial ACL negotiations will finish after the security updates, but you could also be triggering later negotiations if either the central or peripheral intends to update the parameters later (such as in the case of a peripheral having some other preferred parameters than what the central is currently using).

You can set these defines to avoid it happening unless you explicitly start it.
For the peripehral:

CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=n

CONFIG_BT_GAP_PERIPHERAL_PREF_PARAMS=n

For the central:

CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=n

CONFIG_BT_AUTO_PHY_UPDATE=n

CONFIG_BT_AUTO_DATA_LEN_UPDATE=n

Best regards,
Karl

[gocchan]

HI,

After lowering the BIS bitrate to 32000 bps and setting the config for ACL negotiation, it seems to be a little more stable.

However, various errors still occur. Freezes occur most often. At this time, RGB2 blinks green irregularly.

I don't know what this irregular blinking indicates.

Regards, 

Gotoda

[Karl Ylvisaker]

Hello Gotoda,

gocchan said:

After lowering the BIS bitrate to 32000 bps and setting the config for ACL negotiation, it seems to be a little more stable.

More stable, are you still seeing the issue where you can start the BIS when the ACL is established?

gocchan said:

However, various errors still occur. Freezes occur most often. At this time, RGB2 blinks green irregularly.

What does your logs on both sides say when these freezes occur? By freeze, do you mean that the stream stops and resumes of itself a short time after? If not, could you describe this behavior more closely?
The RGB2 blinks green when there is ongoing CPU activity, so this is as expected.

Best regards,
Karl