Service discovery function takes a long time on Android

[leejh]

Hello, Nordic.

I am developing a project that is based on interactive services that exchange data through BLE connections.

Everything is good except for service discovery on Android.

I've tried a number of different methods, but I found that caching GATT is the best way to reduce service discovery time, like iOS

Does anyone have any experience with caching GATT on Android, or reducing service discovery time in other ways?

Thanks. 

I'm current using

 : nRF51822

 : SDK 9.0.0

 : Android Device

[Edvin]

Hello,

Have you tried to use any of the default examples from a later SDK? Is the service discovery equally slow? Or did you try to connect to the device using nRF Connect for Android? Is the service discovery still slow?

Have you tried sniffing the connection? You can use nRF Sniffer for that. It may reveal possible resons why it takes long time. Perhaps the connection interval is too  high, so that sending the service discovery packets and receiving the response takes a long time.

I want to ask what your connection interval is, but since this is always decided by the central, it may not be that easy to say without a sniffer trace (nRF Connect).

And while we're at it. Any particular reason why you are using SDK9? I would recommend using SDK12.3.0, which is the latest SDK version that supports nRF51.

BR,

Edvin

[leejh]

Hi, Edvin.

I tested SDK 15.3.0, the result is equally slow. Also, as a result of checking the packets through nRF Sniffer, it was also checked that it took a long time in service request and service response (about 0.5 sec)

The slow operation through nRF Connect was equally slow, but I couldn't debug it, so I couldn't check the exact time.

I tried various connection intervals and found that it was not a connection speed problem, but a service discovery problem.

The reason for using SDK9 is that we have been working on many projects have been done with the SDK9 and there is no difference from SDK12 in the part we need.

[Edvin]

If it takes 0.5 seconds, why does it take that long compared to iOS? Does iOS complete faster? from the sniffer trace, why does it take longer? Is the Android using longer time to call the service discovery? Is it possible to send the sniffer trace? If possible one that is slow and one that is fast (as expected).

It doesn't sound like there is much we can do. The nRF should reply to the service discovery as soon as it is received. Perhaps you can try with a different android phone and see if the behavior is the same, or if you can find some way in the android application to speed it up. But if it also happens in nRF Connect for Android, then it sounds like the delay is caused by the Bluetooth chip/driver on the phone.

BR,

Edvin

[leejh]

We have done a lot of tests, and Android takes 0.5 seconds on average, and there are very few within 0.4 seconds. The iPhone has 0.3 seconds, and after finding first service discovering, it caches the GATT and does not request a service from the next.

So, We concluded that caching GATT on Android is the answer, and we didn't find a way to do it in the Android Bluetooth standard library, so we wrote this post. Back to the question, do you know how to cache the GATT in the Android Bluetooth Library??

[Edvin]

I am not sure. I believe you should check with an Android forum. We deliver some test applications, such as nRF Toolbox. These use the Android libraries, and that is not something that we have made, so I am not sure how that works. 

BR,

Edvin