service changed behavior for non-bonded server

[jgarnica]

with regards to nrfconnect ios v2.2, has anything changed with respect to service changed characteristic or service and characteristic discovery?

(behaviors described seen on nRF52832, s132v3, sdk v12.3.0 and nRF52840, s140v6, sdk v15.2.0)

I observe the following behavior pre-2.2:

- Connect to a device and verify that all expected services are present, no bonding

- Disconnect, add additional services programmatically on the embedded device

- Connect to the same device with new services, all new services are missing

- In this state, if bluetooth is disabled then re-enabled from system settings, and I connect again, the services are present

This seems to be some sort of caching issue, and I have seen multiple references to the service changed characteristic in solving this.  It was enabled, but I added a call to sd_ble_gatts_service_changed() in a ble event handler similarly to how it is called in peer manager.

Now on connect, the services are present, but they have no associated characteristics.  I have confirmed that the BLE_GATTS_EVT_SC_CONFRIM event is generated.

If I disconnect and reconnect, I do now see all expected services with their characteristics.

Forward to today, I updated nrfconnect to v2.2 for ios.  With the call to sd_ble_gatts_service_changed() still in place, I still see a list of services without characteristics when services change.

But, if I remove the call to sd_ble_gatts_service_changed(), I can now reliably add and remove services while disconnected and see the correct set upon connection.  This is the behavior I'm expecting.

SO, has anything changed in v2.2 of nrfconnect in relation to service/characteristic discovery, the service changed characteristic, or anything similar?

[Dinesh Harjani]

Hi jgarnica,

Thank you for being so watchful. Yes, as you've noticed, BLE behaviour in nRF Connect 2.2 has changed in comparison to previous versions. The build number if I remember correctly is 205, so many changes went into it, and off-the-top of my head I can't remember all the changes we made to the BLE subsystem, but we did make some.

One change that I think might be related to the behaviour you're mentioning is that in previous 2.x versions, nRF Connect, would automatically disconnect from all connected devices the instant it lost foreground status on iOS. This was done for the initial release to speed-up development as well as keeping things as tidy as possible. For 2.2, we altered this behaviour since it caused problems, like disconnecting from devices upon bonding requests on iOS, so now nRF Connect 2.2 remains BLE-active, listening to events, while on the background of iOS. Not always, just as long as iOS allows us before shutting us.

This is what we think relates to the behaviour you mention. In any case, we're constantly listening to any changes/improvements you can suggest for us :)

Some of these detailed changes are mentioned in our "What's New?" screen, which you can check again if you go to Settings and tap on the "Application Version" cell.