Long connection delay with Android, iOS superfast

[blungreen]

Hello,

i have the following setup: nrf52 as peripheral, smartphone as central. Peripheral's purpose is to be an interface between appliance and smartphone. It has no pairing/bonding feature and it advertises with 22ms interval and public static address.

While iOS always performs connection in about 200ms, Android is very inconsistent. Sometimes it connects as fast as iOS, but most of the times it takes 4-5 seconds to get connected.

The peripheral has no low power restriction so it is setup to perform at its maximum, with connection interval, slave latency and supervisor timeout configured as low as possible, as defined in iOS Design Guidelines.

I have tried to analyze sniffer trace but there is no suitable information, the delay is seen between the connect action on Android, and the CONNECT_REQ on the sniffer.

I moved to HCI dump on Android side and i could see the delay, which looks like this:

    No.     Time                Prot.   Len  Info
    38272	1511777537.552557	HCI_CMD	 29	 Sent LE Create Connection
    38273	1511777537.556675	HCI_EVT	 7	 Rcvd Command Status (LE Create Connection) 
    38274	1511777537.591402	HCI_EVT	 22	 Rcvd LE Meta (LE Connection Complete) //300ms, GOOD!
    ...
    ...
    74093   1511781742.368168	HCI_CMD	 29	 Sent LE Create Connection
    74094   1511781742.371541	HCI_EVT	 7	 Rcvd Command Status (LE Create Connection)
    74095   1511781746.930870	HCI_EVT	 22	 Rcvd LE Meta (LE Connection Complete)  //4.5s, BAD!

It can be seen that between frame 38273 and 38274 the delay is 0.3 seconds, while between 74093 and 74094 there is a 4.5 seconds time delay.

Android is connecting with autoConnect=false, so no backgound connection is performed.

This is the nordic sniffer trace, on a long connection delay case:

5430	49.623224000	Test_device	        <broadcast>		  54	ADV_IND
5431	49.692073000	Test_device	        <broadcast>		  54	ADV_IND
5432	49.698782000	6a:15:34:0b:f7:e0	dc:2c:8c:aa:c3:f7 60	CONNECT_REQ
5433	49.704162000	Master	            Slave		      26	Empty Data PDU
5434	49.708205000	Slave	            Master		      26	Empty Data PDU
5435	49.712125000	Master	            Slave		      35	LL Control PDU: LL_FEATURE_REQ
5436	49.743382000	Master	            Slave		      35	LL Control PDU: LL_FEATURE_REQ

Between the last ADV packet (5431) and the CONNECT_REQ (5432) there is only a 6ms delay, which should mean that the delay is all at the Android side.

Can anyone explain why is this happening? Is there any margin of improvement?

Thank you

[blungreen]

UPDATE: i might have found a possible cause, Google's NearbyMessageService

I was trying to figure out why not being able to connect with Huawei P8 Lite smartphone to any BLE peripheral, so after searching the net i came across with someone saying that on some smarphones if there is a background service doing BLE scan, connection will always fail with error 133.

Looking at the logcat of the Huawei it showed that there was a fast scan on background always present with Bluetooth enabled.

Killing NearbyMessageService from Google Play Services stopped the background scan and i was able to get the phone to connect to BLE peripherals.

On my LG G6 i don't see any backgound scan, but i tried to stop the service to see if it could help with my long delay issue. And it did, now i can connect as fast as iOS.

Disabling Nearby notification on Google settings doesn't stop the scan on Huawei phone, neither helps on my LG.

I will investigate further to understand how this service works

[Aleksander Nowakowski]

Interesting. Very interesting. Thanks for sharing.

[Roshan Rajaratnam]

This is quite interesting. Have you tried disabling not just Nearby Notifications but the whole Nearby service from google settings to see if this helps in your case?

[blungreen]

Yes i did, without luck. Tried to disable pretty much everything from Google settings. On Samsung S7 there is also a specific setting for Nearby under Connections menu. But haven't tried.

Bluetooth Classic still works, on Huawei P8 Lite it seems that only BLE is compromised. There is also a highly chance that Samsung A5 is affected by same problem (same BT chip maybe?), i have a customer that is experiencing the same problem but didn't have a chance to verify.

I have tried to post issue on Google Play Help forum and they said my best luck is to ask Huawei. Nice answer. Looking at Google Play app review there are really lots of complains about battery drain and i believe that.

[ketil]

Regarding Huawei P8/P9 Lite it is not possible to use the Fitbit Charge HR with these devices. I suspect your problem might be related. It might actually be a good idea to contact Huawei.

[mon2]

@blungreen - just saw this thread. Ditch the P8 Lite - it is a pure lemon of a design. Would love to chat with the "engineer" group / individual that created this poor excuse of a phone. We have days of wasted time invested in attempting to use the same phone with Cypress (Psoc6), Silabs (assorted), Nordic (832 & 840 kits) and Samsung (Artik 053) - each failed. Samsung is reviewing to purchase this krapware to investigate further. We too saw the Error 133 which is Android related. Fast forward after months of toying with this Huawei garbage and picked up a Moto G5 Plus with 32 GB from Costco (Michigan) - on sale @ $199 USD (unlocked). The small regret is that the US model of this Moto phone is NOT included the NFC feature - oh why oh why. Anyways, ironically, the NFC feature works fine on the P8 Lite. So did the WIFI when we used it in HK and at local wifi access hot spots. Just non of the apps work as they should with WIFI nor BLE.

The Moto is being used as of this week and all apps tested so far are working as they should.

We have hours of complaints lodged with Huaweu and they claim they will either fix it or refund our money. Please consider to file a complaint as well. We have detailed logs on this forum and also Samsung and Cypress regarding this phone. Each developer reported the fault is the phone.

Keep your sanity and ditch this P8 Lite phone!!