How to set BLE min and max connection interval to avoid ATT Timeout error ?

[hmw]

I did the multilink central function when I used zephyr OS
Connecting the five peripherals is stable at first, but after a while the error of <err> bt_att: ATT Timeout will appear
Since Zephyr only provides one-to-one examples, there is no clear way of writing in the multilink part.
After many attempts, I found that modifying the min and max connection interval can make the connection stable for a long time, but if the setting is not good, the stable connection will end at once.

However, an ATT Timeout error will eventually occur (just how fast it happens)

If my goal is to connect 30 peripherals, how do I set these 4 values?

#define MIN_CONNECTION_INTERVAL
#define MAX_CONNECTION_INTERVAL
#define SLAVE_LATENCY
#define SUPERVISION_TIMEOUT

I know the formula that is
Supervision Timeout > (1 +slaveLatency)* (connectionInterval)
But I don’t know what the value of connectionInterval is
Is connectionInterval = MAX_CONNECTION_INTERVAL - MIN_CONNECTION_INTERVAL?
Is there any formula basis for setting connection parameters?
In addition, why setting the connection parameter affects the speed of the ATT Timeout error occur?

Thanks,

Poyi

[Karl Ylvisaker]

Hello Poyi,

If my goal is to connect 30 peripherals

Please be advised that our SoftDevices only support up to 20 connects, as per their specification. You can read more about this in the S140 specification, for example.

I know the formula that is
Supervision Timeout > (1 +slaveLatency)* (connectionInterval)
But I don’t know what the value of connectionInterval is
Is connectionInterval = MAX_CONNECTION_INTERVAL - MIN_CONNECTION_INTERVAL?
Is there any formula basis for setting connection parameters?

The acceptable connection interval for a device is specified as a range, to allow some leeway in choosing the interval.
The actually used connection interval is always determined by the Central, but the peripheral device may have a certain preference ( given as a range between connection interval MIN and MAX ) and if this preference is not met then the peripheral device may be programmed to disconnect from the central. The peripheral may also stay connected to a central with a connection interval outside of what is specified, but then you will have to account for all possible intervals in your peripheral's program.

If you would like to force a certain interval, you may set MIN = MAX. This will leave no leeway for negotiations, and thus the connections interval will either be the specified number, or the connection will be broken.

In addition, why setting the connection parameter affects the speed of the ATT Timeout error occur?

Timeout happens when the connection events are not met by the peer device for a specified duration. This duration should be long enough to allow for unexpected packet loss or corruption in addition to the expected slave latency and interval ( as per the formula you shared ).
Are you seeing the Timeouts reported on your central side? If so, is there any reason to suspect that few of the packets makes it all the way to the central each connection interval? Factors that play into this is packet length, line of sight, interference from environment, etc.

Best regards,
Karl

[hmw]

Thanks for your reply
So I will target one central to 15 peripherals on Zephyr
I set these settings in prj.conf

CONFIG_BT_DEBUG_ATT=y
CONFIG_ASSERT=y

After connecting 5 more devices, the following picture will appear

It feels more like my att request did not receive a reply within the specified time
Is there any way to pass this situation to avoid my central being stuck in this timeout error

Thanks,

Poyi

[Karl Ylvisaker]

Hello Poyi,

hmw said:

So I will target one central to 15 peripherals on Zephyr

Great!

hmw said:

It feels more like my att request did not receive a reply within the specified time
Is there any way to pass this situation to avoid my central being stuck in this timeout error

Are you familiar with the nRF Sniffer tool?
If you could share with me a sniffer trace of the on-air communication when this happens, that would be very helpful.
If you are not familiar with the sniffer tool already I highly recommend that you do so now, since it is one of the most powerful tools to wield when working with BLE development.

In the sniffer trace we will be able to see exactly what is happening with the 5th device.
Please make sure to select the 5th device in the device-dropdown-menu before entering into the connection with the central, in order to have the sniffer follow into the connection and see what is happening.


Looking forward to resolving this issue together!

Best regards,
Karl

[hmw]

You mean I can download the code of the sniffer from this web :  the nRF Sniffer tool

So can this allow my nrf52840dk to track the communication status of one central to multiple peripherals?

I will try it 

Thanks,

Poyi

[Karl Ylvisaker]

hmw said:

You mean I can download the code of the sniffer from this web :  the nRF Sniffer tool

Correct, you can download the firmware and guide to use the sniffer tool at that link.

hmw said:

So can this allow my nrf52840dk to track the communication status of one central to multiple peripherals?

No, the sniffer may only follow into a single connection at the time. But, it seems that your issue happens every time the 5th device is connected, is it not so?
In that case, it would be good to capture a sniffer trace of the communication happening between the 5th device and the central.

hmw said:

I will try it 

Great, I look forward to hearing the results of your test!

Best regards,
Karl