bt_att: att_timeout: ATT Timeout for device for Notify, after adding the one more characteristics

[AkashP]

I have created 4 Custom services, each service has below characteristics.

Service 1 -  Total 21 characteristics

Service 2 - Total 5 characteristics

Service 3 -  Total 3 characteristics

Service 4 - Total 2 characteristics

In Service 2 - One of the characteristics is having Read and Notification , I am using while loop to send bigger size data in terms of 1990 bytes for each notification. It is working without any issue.

Now added one extra characteristics in service 1 - So Total 22 characteristics in service 1. 

Now Notification of Service 2 characteristics is sending data but getting error as bt_att: att_timeout: ATT Timeout for device after some time.

Please help to resolve this issue.

Using Zephyr SDKs v2.5.0 version

[ovrebekk]

Hi Akash

First off I would consider using a more compact service with less characteristics, by combining more functionality into each one. In theory you can use as many as you like (within the limitations set by the 16-bit handle), but having a large attribute table will increase memory consumption and slow down the service discovery process, which could impact the usability of your product. 

I am using while loop to send bigger size data in terms of 1990 bytes for each notification. It is working without any issue.

I assume you mean you are segmenting each 1990 update block into smaller blocks? How much data are you sending in each notification?

Now Notification of Service 2 characteristics is sending data but getting error as bt_att: att_timeout: ATT Timeout for device after some time.

This is an interesting problem. When sending notifications you are not sending requests, only commands, which means an ATT timeout should not be possible. Most likely there is some other part of your application sending an ATT request that times out for some reason. 

Would you be able to enable logging in debug mode (to get as much log data as possible) and attach the log to the case? 

Possibly a sniffer trace will also be needed to find the issue. Assuming you don't have a professional Bluetooth sniffer available we provide our own, which is much more reasonably priced (all you need is a separate dongle or DK):
https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le

Best regards
Torbjørn

[AkashP]

I am using 128bit UUID.

Sending 1990bytes in each notification. For 382KBytes of data, sending 192 times(while loop).

[ovrebekk]

Hi 

AkashP said:

I am using 128bit UUID.

Makes sense since you are clearly using a proprietary service. Using a 128-bit UUID should not make a big difference, it is only during service discovery that this has any real impact. 

AkashP said:

Sending 1990bytes in each notification.

Not sure how you are managing this? 

Attributes are limited to 512 bytes in size max, so if you want to send larger payloads than this you would need to split it up into chunks of 512 bytes or less. 

Best regards
Torbjørn

[alberteinstein]

the bt_att: att_timeout: ATT Timeout for device error may occur when the peer device sends an unexpected ATT request or when the connection parameters are not optimal for the notification frequency. You may want to check the following things:

Make sure that the peer device is not sending any ATT requests while you are sending notifications from Service 2. You can use a tool like nRF Connect to monitor the ATT traffic and see if there are any conflicts.

Try adjusting the connection parameters to reduce the latency and increase the throughput. You can use the bt_le_set_param API to change the connection interval, latency, and timeout values. You may also want to enable the CONFIG_BT_DATA_LEN_UPDATE option to increase the maximum data length.

iq test

[AkashP]

Sorry I was on Holiday. I missed to send response to Read Request and Hence the Timeout was triggering.