Weird connection blocking behavior - NRF52

RE: Weird connection blocking behavior - NRF52

Simonr — Thu, 18 Feb 2021 08:58:19 GMT

Hi again

I have discussed this strange behavior with one of my colleagues, and we agree that changing the address type shouldn't have anything to do with auto-reconnects, but it seems to do in this case.

We can safely conclude with this issue being with the OS on the RedMi, as various scanner apps will inherit some BLE functionalities from the phone OS.

In this case, it seems like the RedMi for some reason is set to autoconnect to devices with a RANDOM_STATIC address for instance, while it will not auto reconnect with PUBLIC addresses for instance. To confirm this, you could do a sniffer trace of this occurring when you've set the RANDOM_STATIC address type, as well as one where this does not occur with the PUBLIC address set.

For this you can use the nRFSniffer for instance, and upload the sniffer traces here on DevZone so we can examine/compare them.

Best regards,

Simon

RE: Weird connection blocking behavior - NRF52

Charadhar Rddy — Wed, 17 Feb 2021 12:48:33 GMT

I had seen that post, for finding out what could be the practical difference. Still unable to figure out why that would cause this issue to happen though. Am I missing something from that article?

RE: Weird connection blocking behavior - NRF52

Simonr — Wed, 17 Feb 2021 12:36:33 GMT

Please check out this thread to learn of the differences between public and random static GAP addresses.

Best regards,

Simon

RE: Weird connection blocking behavior - NRF52

Charadhar Rddy — Wed, 17 Feb 2021 09:53:34 GMT

Hi, Simonr I was doing some testing trying to implement what you were saying. While doing that I tried the following that seems to have fixed the problem. Previously we were not setting the address specifically, but now I am just setting the same using the below logic. I Will experiment further to see if it indeed fixes the problem completely. Also, we have some cases in the field where these are happening, we will check there too if this fixes the problem

By default, the address type seems to be BLE_GAP_ADDR_TYPE_RANDOM_STATIC and now we are changing it to BLE_GAP_ADDR_TYPE_PUBLIC but still not sure why it causes the problem in the first place.

    ble_gap_addr_t       m_my_addr;                                                              
    err_code = sd_ble_gap_addr_get(&m_my_addr);
    ERROR_HANDLER_CRITICAL_CHECK(err_code, true);
    m_my_addr.addr_type = BLE_GAP_ADDR_TYPE_PUBLIC;
    err_code = sd_ble_gap_addr_set(&m_my_addr);
    ERROR_HANDLER_CRITICAL_CHECK(err_code, true);

RE: Weird connection blocking behavior - NRF52

Simonr — Tue, 16 Feb 2021 08:47:47 GMT

[quote user="Chakradhar Reddy"]Also, what we have seen is that this doesn't happen with any other BLE device even on this device. Happens with only our access control devices. This is why I strongly feel there could be something in the firmware which can help with this.[/quote]

Yes, it's strange that this only occurs when using these BLE devices. But if that's the case, it should persist in more phone models I would think. Can you show me what your BLE_GAP_EVT_DISCONNECTED event looks like?

You can try changing the local Bluetooth identity adderss sd_ble_gap_addr_set() after disconnecting, if it is changeed, the peer device should not be able to reconnect without being asked to do so by the central.

Best regards,

Simon

RE: Weird connection blocking behavior - NRF52

Charadhar Rddy — Mon, 15 Feb 2021 17:55:16 GMT

Hi Simonr no worries, thanks for getting back soon !!

Apologies for the confusion in the video. The reconnection is showcased at 0:03 itself, wherein turning on BLE in the NRF Connect app automatically initiates a connection to multiple devices automatically without me doing anything

I have not enabled autoconnect as you can see in the video at 0:07

I'll try to take one more video where it is more clear if possible. In that case I'll try to capture where the device disconnects forcible after 15-20 seconds of inactivity but the android phone reinitiates connection almost immediately.

Also, what we have seen is that this doesn't happen with any other BLE device even on this device. Happens with only our access control devices. This is why I strongly feel there could be something in the firmware which can help with this.

RE: Weird connection blocking behavior - NRF52

Simonr — Mon, 15 Feb 2021 11:40:54 GMT

For some reason your last reply didn't notify me here on DevZone, so I wasn't aware that you had an update. Very sorry about this slip-up, so thank you for pinging me/us!

From the video you shared (sharepoint link) I don't see where the "automatic reconnection" occurs. Can you try explaining what you're trying to show in the video?

Please make sure that autoConnect is not enabled in the nRFConnect (or custom app you're using)

How does your peripheral application handle the BLE_GAP_EVT_DISCONNECTED event?

Best regards,

Simon

RE: Weird connection blocking behavior - NRF52

Charadhar Rddy — Mon, 15 Feb 2021 07:59:09 GMT

Can anyone help me with this please?

Simonr

RE: Weird connection blocking behavior - NRF52

Charadhar Rddy — Tue, 02 Feb 2021 08:14:20 GMT

UPDATE:

After clearing the cache and data of the system app named "Bluetooth" in Android, the auto reconnection stopped completely

After this, I connected one device using nrfConnect once, and then that started reconnecting automatically. But only that one device itself

Then I connected one more device using nrfConnect. After that, the second device also started reconnecting automatically

At the same time, if I try to do this on other devices that are present in the office, like a different vendor's smart lock or a smart band, this doesn't happen with those devices. Could that mean, there is some issue in the device firmware's disconnection logic that is causing/indicating the Android somehow that it should reconnect post disconnection?

RE: Weird connection blocking behavior - NRF52

Charadhar Rddy — Tue, 02 Feb 2021 06:22:13 GMT

Hi @ Simonr,

Please check this link to showcase exactly what is going on

https://snglty-my.sharepoint.com/:v:/g/personal/chakradhar_singularity_services/EWnjTAbJR05Atmpb1CnFwd8B02LK5hMnq9AE5jim6wH0LA?e=MgROYm

As soon as I turn on Bluetooth, the device connects to existing devices (even more than one of them). This happened even after uninstalling our app completely

RE: Weird connection blocking behavior - NRF52

Charadhar Rddy — Mon, 01 Feb 2021 15:28:43 GMT

Hi @Simonr,

We are not using any bonding/pairing process at all. It is just an open connection and all our encryption happens post that. I did try clearing cache using NRF SDK too to see if that helps. None of that seems to have any effect.

Also, just realized one more thing today, I got one more phone of the same model, same OS, and everything same. The issue doesn't happen in that phone though for some reason

RE: Weird connection blocking behavior - NRF52

Simonr — Mon, 01 Feb 2021 14:00:05 GMT

First off, I don't see that you have tried deleting the bonding information on the Android device at all, have you? The behavior you explain seems strange though, especially since only the one phone model shows this behavior. I agree that it seems Android related, as a peripheral device doesn't have any ways to affect the central's behavior I'm afraid.

Can you explain the connection and pairing process in detail for me? I'll also check with our Android experts whether we have any explanations as to what this could mean.

Best regards,

Simon