Connection alive by empty data pdu instead of notifications

RE: Connection alive by empty data pdu instead of notifications

Nivetha — Mon, 23 Oct 2017 08:09:12 GMT

Yes, indeed when I restart the central sometimes it can receive the notifications and sometimes, the service discovery fails and hence there are no notifications received. I have not tested just with the ble_app_hrs. I will try it and let you know. Thanks!

RE: Connection alive by empty data pdu instead of notifications

Hung Bui — Mon, 23 Oct 2017 07:40:53 GMT

Hi Nivetha,

We need to debug why service discovery wasn't started. We need to check if it's actually called on the central or not. If you restart the central instead of restarting the peripheral, do you see the same problem ?

Could you confirm you can reproduce the issue using the ble_app_hrs_c and ble_app_hrs (with no modification) ?

RE: Connection alive by empty data pdu instead of notifications

Nivetha — Thu, 19 Oct 2017 15:34:51 GMT

In those times, BLE DB Discovery is failed as well. I am not sure why!

RE: Connection alive by empty data pdu instead of notifications

Nivetha — Thu, 19 Oct 2017 15:26:43 GMT

Yeah, I understand. Although I am able to connect after disconnection, the discovery of services is successful only at times. Rest, it follows the empty data pdu.

RE: Connection alive by empty data pdu instead of notifications

Hung Bui — Thu, 19 Oct 2017 14:41:44 GMT

When one device reset, the connection will be disconnected. There is no way to re-establish connection without doing advertising.

It's depends on your application, most application will just advertising after the connection is lost (on the peripheral side)

RE: Connection alive by empty data pdu instead of notifications

Nivetha — Thu, 19 Oct 2017 14:13:41 GMT

@Hung Bui. When there is a power cycle, how does the peer device handle it? Does it consider as disconnection and adv every time or does it continue with the data transmission?

RE: Connection alive by empty data pdu instead of notifications

Hung Bui — Thu, 19 Oct 2017 13:21:40 GMT

Could you confirm you can reproduce the issue with the unmodified ble_hrs_c and ble_app_hrs examples in the SDK ? How many time you need to reset the board for the problem to appear ?

RE: Connection alive by empty data pdu instead of notifications

Nivetha — Thu, 19 Oct 2017 11:57:13 GMT

I have just tested with the battery and temperature service too. The same problem appears.

RE: Connection alive by empty data pdu instead of notifications

Nivetha — Thu, 19 Oct 2017 11:05:54 GMT

Thanks a lot. I am using SDK 13. However, I looked at the ble_hrs_c example of SDK 14 and added retry for the ble_discovery. I'm puzzled as to sometimes, it connects and receives the notifications and sometimes it does not.

RE: Connection alive by empty data pdu instead of notifications

Hung Bui — Thu, 19 Oct 2017 10:47:58 GMT

Hi Nivetha, Thanks for the trace, it has quite good information.

What I'm seeing in the trace is that on the first 2 connection everything is fine. The link is not encrypted, and the central do service discovery and then enable notification as normal. But on the last connection, the service discovery didn't start properly. There is a Find by type value request sent from the master and then there is a response from slave. But then after that there was no characteristic discovery. This result in what you observer, the two device just stayed in idle, sending empty packet.

We need to debug how the service discovery is executed on the central side in your code.

Which SDK did you use ? Do you base you code on any example ? Do you use ble_db_discovery.c library ? Do you modify anything related to it ?

RE: Connection alive by empty data pdu instead of notifications

Nivetha — Thu, 19 Oct 2017 08:37:16 GMT

@Hung Bui I have attached the new sniffer trace with all the above requirements satisfied. Please have a look at it. sniffer_log

RE: Connection alive by empty data pdu instead of notifications

Hung Bui — Tue, 17 Oct 2017 15:42:15 GMT

Please try to capture a full sniffer trace, including when the connection is established, (advertising packet, then connect request) after that notifications are sent. Then central/peripheral reset, and connection re-established and no notification just empty packet.

The sniffer above didn't tell much about the situation.

RE: Connection alive by empty data pdu instead of notifications

Nivetha — Tue, 17 Oct 2017 15:24:15 GMT

please find the sniffer trace here

RE: Connection alive by empty data pdu instead of notifications

Hung Bui — Tue, 17 Oct 2017 13:40:37 GMT

Then bonding is required. If not peer manager won't be able to re-establish CCCD. I would suggest you to capture a sniffer trace.

RE: Connection alive by empty data pdu instead of notifications

Nivetha — Tue, 17 Oct 2017 13:02:28 GMT

Yeah, sure. I have implemented the peer manager at the central device.

RE: Connection alive by empty data pdu instead of notifications

Hung Bui — Tue, 17 Oct 2017 10:44:16 GMT

Hi Nivetha,

It's not very clear what you meant by " I want the notifications to continue by advertising and scanning etc."

I assume your question is , why in some cases the connection was re-established and the notification started automatically when in some other cases there were no notification, just empty packets.

We need to look into how the notification be sent. You can only send notification when the CCCD (Client Characteristic Configuration Descriptor) is enabled by writing 1 to the CCCD characteristic. If there was nothing written or initialized in CCCD when you call hvx command, you will receive BLE_ERROR_GATTS_SYS_ATTR_MISSING (0x3401). This is described in the documentation of the sd_ble_gatts_hvx command.

If your 2 devices are bonded, the CCCD should be enabled automatically when they re-connect. But it's up to the application code (or the peer manager if you use peer manager)

Or, the central should set the CCCD right away after the connection re-established. This should be implemented in the central code.