Strange behavior of Android mobiles after Connection parameters update request

[Hust]

Hi guys,

I have very strange problem with the Android phone when connect with nrf51822. 

After connection, I used update parameters to set the parameters on the phone side to be like what I want.

My connection paramters are: min_interval: 6 ms, max_interval 10 ms, conn_supp_timeout: 1s.

The first or default from phone is min_interval: 39 ms, max_interval: 39 ms, and conn_suppp_timeout is 20 s. 

After request, the all the Android phone returns response to my request with the values: min_interval: 9 ms, max_interval: 9 ms, conn_supp_timeout: 1s. 

The sniffer also showed that the update request was accepted by phone side.

The strange thing is:

+> with Samsung and IPhone, I have no problem, after disconnect from nrf51822 ( I just turned off the power), after 1 s, it did appear on phone that the device have been disconnected. This is what I expected.  

+. with Oppo and Xiaomi, while in first 20 second when the connection establish, if I turned off the power of nrf51822 after 6 or 7 second after connection, the phone did not disconnect after 1 second, but after 14 or 13 second, which is 20 minus 6 or 7. If it is 16 second after connection then the supp_timeout will be 4 second. After 20 second, it worked like Sumsung or IPhone, which will disconnect after 1 second sup_conn_timeout.

Is there anything I can do to make all the Android phone do exactly what it told to do, which is conn_timeout is 1 second?

Thank you guys very much,

[awneil]

Hust said:

Is there anything I can do to make all the Android phone do exactly what it told to do

No.

The Central - whether it's Android or anything else - is not obliged to give you what you request in a Connection Parameters Update.

Android & iOS certainly do impose their own limits on what they accept - and it can vary from phone to phone. It may even vary from connection to connection.

[Hust]

Hi Awneil, 

This is what I got when I used sniffer to see what happened, Samsung, Xiaomi and Oppo, all of them response to request in Connection Parameters Update in the very same way, but they acted differently. This confuse me a lot. Samsung worked fine but others are not.

I guess maybe this is because of different in specification of each phones?

[Edvin]

Hello,

Can you send me two sniffer traces? One with a phone acting like you want it to, and another with one of the phones not acting like you want to. I would like to see what's going on over the air.

Best regards,

Edvin

[Hust]

Hello,

This is the sniffer traces of them, the samsung is the one worked fine and oppo is not.

oppo_log.pcapng

samsung_log.pcapng

Thank you for your time.

[Edvin]

Hello,

I can't see any issues with the sniffer trace. The connection is updated to use 1 second timeout in both traces. The only difference is that in the oppo_log.pcapng trace, the master continues to send Empty PDU packets for a lot longer than 1 second. I am not sure whether it is actually against the BLE specification, and from the nRFs point of view, it isn't really a problem. The problem is that if the devices comes out of range, the nRF will disconnect (and start advertising) after one second, while the phone will try to resume a connection that the nRF considers lost. 

To me, it sounds like a bug in the phone's OS. 

Best regards,

Edvin