Trouble finding characteristics using android nRF toolbox, while the nRF Connect android app finds it ok

RE: Trouble finding characteristics using android nRF toolbox, while the nRF Connect android app finds it ok

Aleksander Nowakowski — Thu, 21 Sep 2017 17:56:54 GMT

We will have it fix on nRF Toolbox soon. Thanks for pointing it out.

RE: Trouble finding characteristics using android nRF toolbox, while the nRF Connect android app finds it ok

Aleksander Nowakowski — Thu, 21 Sep 2017 17:56:21 GMT

You may call this method in previous APIs as well, since 19 or 20, afair, just using reflections as it's hidden with @hide.

RE: Trouble finding characteristics using android nRF toolbox, while the nRF Connect android app finds it ok

desnyki — Thu, 21 Sep 2017 17:14:11 GMT

I tried clearing the device cache, but that didn't turn out to be the issue. After further investigation on the hardware side the BlueZ chip would go into BR / EDR mode. This allowed for a successful GATT connection on the Android side, but the services did not exist in onServicesDiscovered. In order for the services to show up, the connection had to explicitly specify a BLE connection.

NRFToolbox connection code:

device.getDevice().connectGatt(applicationContext, false, mGattCallback);

The fix:

device.getDevice().connectGatt(applicationContext, false, mGattCallback, BluetoothDevice.TRANSPORT_LE);

Note: this method call requires Android API 23.

RE: Trouble finding characteristics using android nRF toolbox, while the nRF Connect android app finds it ok

Aleksander Nowakowski — Mon, 10 Jul 2017 14:01:19 GMT

Hi,

First of all, service UUIDs used in the adv packet don't need to be present in the device database. You may advertise with whatever, and what services you have on the device is a different thing. Of course it's good to expose what you have, not cheat, but it's practically possible to do this.

I think your issue may be related to the Android device caching services. In nRF Connect we used to (before Nougat) clear cache every time you disconnect from a device and close the tab (it's shown on the log, can be viewed in nRF Logger as this is the last thing nRF Connect does before closing the tab and the built-it log). We did it not to keep cache clear, but it made the next connection more stable and reliable. Since Nougat we assume that the BLE is mature enough, and if user want's to refresh cache, there is an option in the menu for that.

In nRF Toolbox we don't clear cache, so it may be that when you connected to a device before you flashed the current firmware, the old services were cached and now the app displays the old ones. Opening nRF Connect clears cache on disconnect, so next time you open nRF Toolbox it will do the proper service discovery.

This explanation is not completely compatible with your issue, but please check if it's correct. Perhaps when you flash BPM/CSC on the same device it caches them and when you try a different profile with different fw it still shows the old ones? In real life devices very rarely change their databases.

BR, Aleksander