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