nRF52840 random disconnection

Hi Daniel, 

If you run an SDK example on your device and doesn't have any issue with bonding (and reconnect) with multiple centrals then it must have something to do with your implementation. 

If you can flash your application on a DK and can reproduce the issue on the DK, then you can send us that application and we can test here. 

Hi Hung,

I have a DK but I'm using it as a sniffer: I have ordered a new one to make these tests.

Meanwhile, I'm doing some more testing and I have just found something important with my Xiaomi Mi 8.

Up to now, I was working with the following parameters:

#define MIN_CONN_INTERVAL                   MSEC_TO_UNITS(7.5, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL                   MSEC_TO_UNITS(100, UNIT_1_25_MS)
#define SLAVE_LATENCY                       0                              
#define CONN_SUP_TIMEOUT                    MSEC_TO_UNITS(4000, UNIT_10_MS) 

Now, I have set these parameters:

#define MIN_CONN_INTERVAL                   MSEC_TO_UNITS(7.5, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL                   MSEC_TO_UNITS(100, UNIT_1_25_MS)
#define SLAVE_LATENCY                       15                              
#define CONN_SUP_TIMEOUT                    MSEC_TO_UNITS(5000, UNIT_10_MS) 

Considering this last setting, my Xiaomi Mi8 does not disconnect after around 30": I have tested the different scenarios detailed above, and now it seems to be working perfectly. (Even, I have tested the scenario in which I was connecting my device with the Galaxy Tab and then with the Mi8, and now the Mi8 is also working). How could you explain this??

In what regards the Galaxy Tab, it continues doing the same: perfect connection the first time (when bonding) but impossible to connect next times (already bonded): GATT CONN TIMEOUT always received.

Could you explain such improvement with the Mi8? I'm now lost with this behavior...

Do you think any other setting using these parameters would make the Galaxy Tab A to work?

Regards,

Dani

Hi Dani, 

Your change is mainly about the Slave latency and it usually wouldn't affect the connection except for slower communication. 
Could you try to only change one setting at a time. In your case you change both the Slave Latency and the Conn supervision Timeout. 

As explained in the last response the GATT CONN TIMEOUT issue happened because the tablet was violating the spec. Do you experience the same issue when you test the tablet with other example ? 
Btw, the log where you captured GATT_CONN_TIMEOUT was a very good attempt of capturing sniffer trace when the connection is encrypted and re-encrypted. There were no "decrypted incorrectly" packet. 

If you can do the same with the Xiaomi Mi 8 we maybe able to figure out what's the problem. (If you are going to do it with multiple central, try to stop the sniffer before bonding with the second central, then start again when you return to test the first central)

Hi Hung,

Ok, I will save this trace.

Nevertheless, now, with these changes I have made, if I connect first to Mi8, then to tablet, and then back again to Mi8, Mi8 is always working fine, without any disconnection.

Dani.

Hi Hung,

I have taken the Mi8 (with LESC=0) and TabA (with LESC=0) and I have proceeded in the same way.

• First, with the Mi8:
  • Desinchrnozed Peripheral from Mi8
  • Bonding and Connection with Peripheral
  • Manual Disconnection
  • Connection again with the already bonded peripheral
  • Manual Disconnection

            In this case, everything is running OK (I have kept Slave_Latency to 15)

• Second, with the TabA:
  • Desinchrnozed Peripheral from TabA
  • Bonding and Connection with Peripheral: it connects perfectly
  • Manual Disconnection
  • Connection again with the already bonded peripheral: impossible to connect again

            In this case, connection is only running OK the first time, when bonding. The second time, it is impossible to connect.

Please, find attached sniffer traces in both cases.

Dani