Strange Connection Issue with iOS and Android

RE: Strange Connection Issue with iOS and Android

Kenneth — Mon, 22 Jun 2020 12:23:14 GMT

I think I would recommend to run some DTM tests to check if everything is as it is suppose, also if possible share schematic and layout (in a private case) so we may review if you haven't already done so.

Best regards,
Kenneth

RE: Strange Connection Issue with iOS and Android

PatrickHennig — Mon, 22 Jun 2020 11:30:30 GMT

I agree if it is not received correctly, but even at the sniffer I can only see 1-2 out of 20 failing connection requests attempts and the successfull one.

We used it together with an skywalk amplifier now, this seems to work very good.

RE: Strange Connection Issue with iOS and Android

Kenneth — Mon, 22 Jun 2020 09:33:04 GMT

It is not weird that the connection fails with 0x3E if the connection request is not received by the peer, that is the way BLE have specified handling of that case. It is however weird that the connection request packet is consistently not received for a long period of time.

Is it possible that the module is also handling other non-BLE operations at the time that it is scanning and trying to connect? For instance is is possible that the module is running any serial interfaces, blinking LEDs (PWM) and/or any other activity here? Depending on the layout such activity may interfere with the radio.

RE: Strange Connection Issue with iOS and Android

PatrickHennig — Mon, 22 Jun 2020 09:04:51 GMT

Yes, we have tried that already. Strange is that the connection immediately fails with 0x3E. If we put the sniffer antenna directly next to the ble module we even cannot see the connect request in the sniffer. We only see the successful one and maybe one failing before. But not the 20 requests that directly fail with 0x3e.

It looks like if the module is not able to sent the connection request. Can that be the case?

RE: Strange Connection Issue with iOS and Android

Kenneth — Mon, 22 Jun 2020 09:00:12 GMT

Any 2.4GHz interference (wifi, bt or other) at the time the connection request packet is sent can prevent the packet to be received correctly, this can cause the same symptoms yes (fail with 0xe3). However I would expect this noise to also affect the link when successfully established, in other words I would expect some packet loss and re-transmissions on the link layer. I can't really from the trace you sent see that happens. Have you tried to enable flight mode on the phone and only enable bt to see if that have an effect?

RE: Strange Connection Issue with iOS and Android

PatrickHennig — Sat, 20 Jun 2020 10:05:52 GMT

Unfortunately, the correct clock settings did not help a lot. For the environment we are looking at there seems to be a lot of noise.

If we checked it with the nRF Sniffer, we haven't even seen all of the Connect Requests, we only see the successful ones. The others directly fail in nrf with 0xe3. Could the noise be the reason that the chip is not able to sent out the connect requests?

We now use it together with a skywalk amplifier. This seems to help a lot as almost all connection attempts are successful and we can see them in the sniffer.

RE: Strange Connection Issue with iOS and Android

Kenneth — Wed, 17 Jun 2020 11:59:44 GMT

[quote user="PatrickHennig"]In the u-blox description we found that the crystal has a tolerance of 500ppm. Nevertheless in our config we used 20ppm from one of the dev boards. [/quote]

That will for sure have an impact on the stability of the link yes, the tolerance is sent in the connection request packet and used by the peer to calculate connection periods. If the configured tolerance exceed the actual tolerance this will have an impact.

Does your testing show that using 500pm solves the issue?

It is possible to add an external 32kHz crystal to the nRF52-series, this will typically reduce current consumption overall (you can trade-off current consumption vs. cost).

RE: Strange Connection Issue with iOS and Android

PatrickHennig — Tue, 16 Jun 2020 12:41:25 GMT

We did a capture of the sequence. But we were not able to capture all connection attempts.
Please find the capture here: https://shared-link.bdrive.cloud/shared/9b9930cd-d627-4c8d-aa86-5a759475bbd3#ca16bd6661b5ea70ad29ea41093927a44f89dd7fa7b0ca0fc37cf68cfe01983c

ADV_IND
CONNECT_REQ
Sent Exchange MTU Request, Client Rx MTU: 184
Sent Exchange MTU Request, Client Rx MTU: 184
Sent Exchange MTU Request, Client Rx MTU: 184
Sent Exchange MTU Request, Client Rx MTU: 184
Sent Exchange MTU Request, Client Rx MTU: 184
Sent Exchange MTU Request, Client Rx MTU: 184
ADV_IND
ADV_IND
ADV_IND
ADV_IND
ADV_IND
SCAN_REQ
SCAN_RSP
ADV_IND
SCAN_REQ
ADV_IND
ADV_IND
ADV_IND
ADV_IND
SCAN_REQ
ADV_IND
CONNECT_REQ
Sent Exchange MTU Request, Client Rx MTU: 184
Sent Exchange MTU Request, Client Rx MTU: 184
Empty PDU
Control Opcode: LL_LENGTH_REQ
Empty PDU
Empty PDU
Control Opcode: LL_LENGTH_RSP
Empty PDU
Rcvd Exchange MTU Response, Server Rx MTU: 184
Sent Find By Type Value Request, GATT Primary Service Declaration, Handles: 0x0001..0xffff
Control Opcode: LL_VERSION_IND
Control Opcode: LL_VERSION_IND
Rcvd Find By Type Value Response
Sent Read By Type Request, GATT Characteristic Declaration, Handles: 0x0039..0x0050
Control Opcode: LL_SLAVE_FEATURE_REQ
Control Opcode: LL_UNKNOWN_RSP
Rcvd Read By Type Response, Attribute List Length: 8, Unknown, Unknown, Unknown, Unknown, Unknown, Unknown, Unknown, Unknown
Sent Read By Type Request, GATT Characteristic Declaration, Handles: 0x0050..0x0050
Rcvd Read By Type Request, GATT Characteristic Declaration, Handles: 0x000a..0xffff
Sent Error Response - Attribute Not Found, Handle: 0x000a (Unknown)
Rcvd Error Response - Attribute Not Found, Handle: 0x0050 (Unknown)
Sent Find Information Request, Handles: 0x003c..0x003c
Empty PDU
Empty PDU
Rcvd Find Information Response, Handle: 0x003c (Unknown: Unknown: Characteristic Extended Properties)
Sent Find Information Request, Handles: 0x003f..0x003f
Empty PDU
Empty PDU
Rcvd Find Information Response, Handle: 0x003f (Unknown: Unknown: Client Characteristic Configuration)
Sent Find Information Request, Handles: 0x0042..0x0042
Empty PDU
Empty PDU
Rcvd Find Information Response, Handle: 0x0042 (Unknown: Unknown: Client Characteristic Configuration)
Sent Find Information Request, Handles: 0x0045..0x0045
Empty PDU
Empty PDU
Rcvd Find Information Response, Handle: 0x0045 (Unknown: Unknown: Characteristic Extended Properties)
Sent Find Information Request, Handles: 0x0048..0x0048
Empty PDU
Empty PDU
Rcvd Find Information Response, Handle: 0x0048 (Unknown: Unknown: Client Characteristic Configuration)
Sent Find Information Request, Handles: 0x004d..0x004d
Empty PDU
Empty PDU
Rcvd Find Information Response, Handle: 0x004d (Unknown: Unknown: Characteristic Extended Properties)
Sent Find Information Request, Handles: 0x0050..0x0050
Empty PDU
Empty PDU
Rcvd Find Information Response, Handle: 0x0050 (Unknown: Unknown: Characteristic Extended Properties)
Sent Find By Type Value Request, GATT Primary Service Declaration, Handles: 0x0001..0xffff
Empty PDU
Empty PDU
Rcvd Error Response - Attribute Not Found, Handle: 0x0001 (Unknown)
Empty PDU
Empty PDU
Sent Write Request, Handle: 0x003b (Unknown: Unknown)
Empty PDU
Empty PDU
Rcvd Write Response, Handle: 0x003b (Unknown: Unknown)
Sent Write Request, Handle: 0x0048 (Unknown: Unknown: Client Characteristic Configuration)
Empty PDU
Empty PDU
Rcvd Write Response, Handle: 0x0048 (Unknown: Unknown: Client Characteristic Configuration)
Sent Read Request, Handle: 0x004a (Unknown: Unknown)
Empty PDU
Empty PDU
Rcvd Read Response, Handle: 0x004a (Unknown: Unknown)
Sent Write Request, Handle: 0x004c (Unknown: Unknown)
Empty PDU
Control Opcode: LL_TERMINATE_IND
Rcvd Write Response, Handle: 0x004c (Unknown: Unknown)

We are using a u-blox module right now. Can it be due to a miss-configured clock setting?
In the u-blox description we found that the crystal has a tolerance of 500ppm. Nevertheless in our config we used 20ppm from one of the dev boards.

From our feeling it looks much better now. Is this a suitable reason? And do you think it will be much better if we use a more accurate crystal for the radio?

RE: Strange Connection Issue with iOS and Android

Kenneth — Tue, 16 Jun 2020 09:37:51 GMT

Not that familiar with how to setup a phone in peripheral mode and if there are any "gotchas", but if you have an on-air sniffer log maybe we can take a look at the advertisement and connection request packet for anything in specific:
https://www.nordicsemi.com/Software-and-tools/Development-Tools/nRF-Sniffer-for-Bluetooth-LE

RE: Strange Connection Issue with iOS and Android

PatrickHennig — Tue, 16 Jun 2020 09:15:53 GMT

Thanks, but the nrf chip is in the central role and we want to connect to the phones from the nrf chip. The android and iphones are in peripheral role and on the phone we don't have the option to disable a whitelist, right?

RE: Strange Connection Issue with iOS and Android

Kenneth — Tue, 16 Jun 2020 09:10:36 GMT

Seems to be consistent for quite some time, this leads me to believe that the peripheral may be advertising with whitelist enabled, and that the specific phone is not in the whitelist. Typically after a while the peripheral will disable whitelist by default. As a quick test to confirm you may try to call ble_advertising_restart_without_whitelist() instead of ble_advertising_start() on the peripheral.