Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Changes of handling GATT Service Changed indications in SDK 15.2

Hi !

A questions to Nordic employees about the GATT Service Changed indications.

We have a peripheral with software based on SDK 12.3.
When testing using android as a client, our device worked fine.
After switching to use SDK 15.2, the android began to disconnect from our device.
The analysis of the logs showed that the disconnection occurs after the android sends a GATT Service Changed indications and after 30sec timeout for waiting a respond which does not come.
The device software does not support the response to this indication, as it is a server.

In the same time using SDK 12.3, this problem was not occur.
I decided to add the GATT Service client to device firmware and found that such an opportunity appeared in SDK 14.0.

The first question is: could something change in SDK or in SoftDevice when switching from 12.3 to 15.2 such that the firmware began to react (or not react) to the Service Changed indications?

Second question: is the possibility of adding a GATT service client to SDK 14.0 due to the fact that some clients send a Service Changed indications?

Thanks!

Parents
  • Hi,

    I want to clarify what seems to be a misunderstanding. There is no direct relationship between the GAP Central/slave roles and the GATT client server roles. Both centrals and peripherals can be GATT clients and servers, and often a single device is both a GATT client and a GATT server.

    You write that the central (GATT server in this case) sends a Service Changed indication. It should only do that if the peer has subscribed to the service changed indication (set the CCCD accordingly). Are you sure that is not the case? If not, then the central is breaking the BLE specification as it is not legal to send indications before it is enabled by the GATT client on the peer device.

    The first question is: could something change in SDK or in SoftDevice when switching from 12.3 to 15.2 such that the firmware began to react (or not react) to the Service Changed indications?

    It is correct that the GATT Service Client was added after 12.3. It is intended to properly handle Service change indications from a GATT server. We need to know more about your application and the BLE communication in order to say more specifically what is going on.

    Second question: is the possibility of adding a GATT service client to SDK 14.0 due to the fact that some clients send a Service Changed indications?

     No. A Service change indication is only sent by a GATT server. (However, a GATT server and GATT client may very well be present on the same device.)

  • Hi, Einar.
    Thanks for the answer!
    The situation is as follows: the same device is used for testing on the android platform.
    But when we use on our controller the firmware based on SDK 12.3, the android is not disconnected, but as soon as we went to SDK 15.2, the same android began to disconnect due to non-receipt of confirmation of indication from the our controller.

    If android device is the same, the question arises: why did the android suddenly become disconnected, because its firmware has not changed. It turns out that the reason for the controller firmware?

    I will leave the question that if our controller is a server, then the android should know that he is a client and should not send any indications to the server at all, since it is clearly understood, that the controller is a server and clearly does not appear in the client’s rally. And we, as server did not subscribe to indications :) 


Reply
  • Hi, Einar.
    Thanks for the answer!
    The situation is as follows: the same device is used for testing on the android platform.
    But when we use on our controller the firmware based on SDK 12.3, the android is not disconnected, but as soon as we went to SDK 15.2, the same android began to disconnect due to non-receipt of confirmation of indication from the our controller.

    If android device is the same, the question arises: why did the android suddenly become disconnected, because its firmware has not changed. It turns out that the reason for the controller firmware?

    I will leave the question that if our controller is a server, then the android should know that he is a client and should not send any indications to the server at all, since it is clearly understood, that the controller is a server and clearly does not appear in the client’s rally. And we, as server did not subscribe to indications :) 


Children
Related