Advertised characteristics do not update on iOS NRFConnect 2.3.2

[daubsi]

I am using nRF Connect 2.3.2 on iOS 13.6 on an iPhone 11 Pro Max. I can scan and find my  nRF52-DK with the flashed application and the service is correctly advertised (e.g. Heart Rate Service). As soon as I connect and view the characteristics the tool seems to show outdated data e.g. from a former CSCS flash. The problem persists even when erasing the chip and reflashing with different example application. Problem does not occur with other BLE tools only with nRF Connect. This behavior started some time ago. I am sure it was working correctly when I started using the tool.  Is this a known issue? Is there a local cache I could clear or force a rescan of the characteristics?

[Vidar Berg]

Hello,

The iPhone is likely doing what's known as attributes caching. It's a BT feature that allows it to skip service discovery every time it connects to your device. For a complete summary of this feature I recommend you take a look at the following section in the Bluetooth core spec: vol3, part g, section 2.5.2. Anyway, in order to clear the cache and force a new service discovery, first, make sure it's not in the list of bonded devices in settings->bluetooth, then toggle flight mode enable (or reboot the phone). The cache should be cleared after this.

You may also consider building the app with NRF_SDH_BLE_SERVICE_CHANGED enabled. This adds the service changed characteristic to the attribute table, which effectively disables attribute caching for non-secure connections.

[daubsi]

I had partly success. On the one hand when building a new project from scratch using the template project it did not occur so far that I saw "old" characteristics that look like remainder from previous projects in the nRFConnect tool despite the project does not even include those characteristics. As such I cannot say if NRF_SDH_BLE_SERVICE_CHANGED would actually help here.

I also have an old Android tablet running Android v5.1.1 and what I can say in direct comparison is that the Android variant of nRFconnect seems to be much more responsive and stable than the iOS pendant. In the Android app I can tab on a characteristic and the desired action is executed immediately. In the iOS it constanly seems as if the app is hanging or frozen, like the Read/Write icons change state but don't reactivate or seem to do any action. I need to tap 3 or 4 times on "Notify" until the request is finally received at the DK etc. I can confirm that it is not an issue with my code as it works perfectly and reactive using nRFconnect for Android. As I am a beginner with nRF tools and products I cannot say if it is this particular version of the nRFConnect tool which is buggy or whether it is a problem on iOS in general due to the different BLE implementation layer in the OS. I hope a later update can remedy most of the problems. Other tools like LightBlue seem to be more responsive to user interaction here as well.

[Vidar Berg]

daubsi said:

I had partly success. On the one hand when building a new project from scratch using the template project it did not occur so far that I saw "old" characteristics that look like remainder from previous projects in the nRFConnect tool despite the project does not even include those characteristics. As such I cannot say if NRF_SDH_BLE_SERVICE_CHANGED would actually help here.

 It's important that the cache is cleared before you add NRF_SDH_BLE_SERVICE_CHANGED, else it will not have any effect (iOS will not know that it has been added).

daubsi said:

iOS in general due to the different BLE implementation layer in the OS. I hope a later update can remedy most of the problems.

 It should feel fairly responsive. I just tested this on an iPhone 8 with nRF connect version v2.3.2 and it took one press and approx. 1 second to enable notifications on the hrs characteristic. This is with a relatively slow connection interval (400-500ms). You may try to reduce the connection interval to see if that helps (iOS will accept 15 ms intervals if you request MIN_CONN_INTERVAL=MAX_CONN_INTERVAL=15ms).