This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nrf connect app problem

Dear friend,

I am doing a test like this:
1. Connect the Bluetooth device with the nrf conncet app of the Android phone.
2. The notify (CCCD) is enabled.
3. Click "disconnect" on the nrf connect APP to disconnect.
4. Click "connect" again to reconnect.
Result: I see that the notification of nrf connect app is still in the enabled state (in fact, the notification of the Bluetooth terminal is in the disabled state).
And repeat the above steps 1-4 with the nrf connect app of the ios phone, there is no such phenomenon.
The operation video of the nrf connect app on Android phones is as follows:


Why is the nrf connect app phenomenon of Android phones and ios phones different? What is the difference between them? Is nrf connect app a normal phenomenon?

Parents
  • Hello,

    This is not a "phenomenon". Your device is bonded, which means both client and server can store the value of Client Characteristic Configuration Descriptor (CCCD), so that after reconnection enabling notifications/indications is not required. nRF Connect for Android does it. It cannot verify whether the other side in fact also has stored CCCD value (without reading CCCD value), but with Nordic SDKs it should be true. You may always read the value of CCCD to update the value.

    Had your device not been bonded, you would not have had this "phenomenon".

    Also, another fun fact, if nRF Connect receives a notification/indication from a characteristic which had the value set to "disabled", is assumes they were actually enabled, and changes the CCCD state accordingly. For that, nRF Connect calls setCharacteristicNotification with value true for each characteristic with NOTIFY/INDICATE properties (you can see it in the log). This does not enable notifications remotely, but notifies Android system, that the local client is interested in receiving updates on those attributes.

Reply
  • Hello,

    This is not a "phenomenon". Your device is bonded, which means both client and server can store the value of Client Characteristic Configuration Descriptor (CCCD), so that after reconnection enabling notifications/indications is not required. nRF Connect for Android does it. It cannot verify whether the other side in fact also has stored CCCD value (without reading CCCD value), but with Nordic SDKs it should be true. You may always read the value of CCCD to update the value.

    Had your device not been bonded, you would not have had this "phenomenon".

    Also, another fun fact, if nRF Connect receives a notification/indication from a characteristic which had the value set to "disabled", is assumes they were actually enabled, and changes the CCCD state accordingly. For that, nRF Connect calls setCharacteristicNotification with value true for each characteristic with NOTIFY/INDICATE properties (you can see it in the log). This does not enable notifications remotely, but notifies Android system, that the local client is interested in receiving updates on those attributes.

Children
  • Hi,

    Can you analyze why ios and Android are different? Or is there any article about the different descriptions of Bluetooth connection between ios and Android?

  • This is not about Android and iOS being different. Saving state of CCCD for bonded devices is a feature of nRF Connect for Android, it's a feature we implemented to be more "complaint with spec". In nRF Connect for iOS it is not possible to implement, as the API does not expose the bonding state to the connected device. So the app does not know whether the device is bonded, or not. And the system does not cache CCCD for remote characteristics, as far as I know.

  • Hi,

    Create a private service. There are two features under this service: "Characteristic A" and "Characteristic B" (the configuration of the two Characteristic on the device is the same)
    The following tests were carried out in nRF Connect for Android:
    1. Open the notify of "Characteristic A" and the notify of "Characteristic B".
    2. Send data to "Characteristic A" and "Characteristic B", and nRF Connect for Android can receive the data.
    3. Disconnect and reconnect the device.
    4. The connected device does not perform the enable operation of notify, and the device sends data to "Characteristic A" and "Characteristic B"
    Result: "Characteristic A" can receive data, "Characteristic B" cannot receive data
    Question: Why can't for "Characteristic B" receive data ?

  • Hi, 

    Sorry for the delay. I cannot reproduce the issue on nRF52832DK. Here is my test project ble_app_template_267175.zip. If you want to test on nRF52832DK, you can place it under nRF5_SDK_17.0.2_d674dde\examples\ble_peripheral. After disconnection, both two "Characteristic A" and "Characteristic B" can receive data. 

    -Amanda H. 

Related