How to use service change characteristic

[jfDEVmoto]

There are several use cases where we want a bonded peripheral to indicate the service changed characteristic to the central. The main case is when developping and adding new services. It is cumbersome to unbond the device and bond again. I am sure all ble developpers would agree. I have set up my gatt server to have the service changed characteristic. My client is able to see it and to activate indications.

I understand the following SD API call can then send the indication, so that my android phone should refresh its cache so that a service discovery will show or remove the services that have changed since last bond or indication.

sd_ble_gatts_service_changed (m_conn_handle,0x000C,0xFFFF);

My concern is : when do I have to send it ?

• If I send it on connection event, my device has not setup indications yet, so that it seems that the indication has no effect on my device side.

• If I send it upon the cccd write event, that I receive when central activates indication, how can I filter the event : I don't know the handle for this characteristic cccd because it is created internally with some soft device init options. Is the handle defined in the doc or how can I retrieve it ?

• Is there something that I did wrong or did not understand about this event ?

• is my call above not correct ? I have copied it from device manager gatts context apply, I don't know how device manager module uses this and I think I will have to switch to peer manager sooner or later. will it change the behavior ?

• I guess the handles values in this call as above would trigger a refresh of the entire gatts table, do I have to restrict to service and characteristic handles ? is there a distinction between service handles and char handles in this API call ?

Thanks, for your help.

[run_ar]

Just call this after reconnecting and rebonding to a known peer. The state of the CCCD should be remembered across connection for bonded peer's so you do not have to wait for the CCCD write when reconnecting, if you get an invalid state error you will have to resend the indication after it has been reenabled (in case the peer doesn't follow the spec and remember the cccd state). The handle of the service change charateristic will not change so you can connect with a "test master" to see what handle it is using.

It's ok, and simplest, to trigger a refresh of the entire attribute table. The drawback is a slightly higher power consumption during the discovery procedure.

[Jordan Archer]

Can you enumerate on this:

1) How do I resend the indication? (An simple code example would be nice).

2) How do I trigger a refresh of the entire attributes table?  (Again a simple code example would be nice).

[run_ar]

1. As a server, Service changed indications are managed by the peer manager. See: Architecture.

2. As a client we have the GATT Service Client