CONNECT_REQ missing

[Jake Yun]

Hello, I have a question regarding BLE Connection.

Test Condition:

    - SDK: nRF5_SDK_15.3.0

    - Softdevice: s140_nrf52_6.1.1

    - Target hardware: PCA10040(nRF52832), custom board(nRF52840)

Problem:

    - Connection from Android phone fails from time to time

Notes:

    - Only some phones show the problem

    - nRF52832 shows more error than nRF52840 ( for example 10% in 52832(10 fails on 100 trial),  while 1% in 52840 )

    - I captured the failing and success case but failed to identify difference.

Following capture shows normal case.

nRF5 stops advertising(Orange) as soon as it gets CONNECT_REQ(Purple).

And master and slave meet later when CONNECT_REQ specified. ( Green and Blue packet )

Following 2 captures show failing case.

IFS between orange(ADV_IND) and purple(CONNECT_REQ) is 152us both normal and failing case.

nRF5 keeps adverting and does not respond to master's packet.

I don't think it's from interference because of the first failing case.

Here is the zoomed-in picture of the first failing case.

nRF5 has definitely received the purple packet and we know it from the fact that the third ADV_IND is deferred ( 528us + 652 us ).

Usually, the third ADV packet is sent around 874us after the beginning of second ADV packet.

I hope it is not an inherent problem of nRF5.

Please give me some measure to get around this problem.

I think it may help if the gap between ADV packets in one event can be widen.

Thank you.

Best regards,

Jake

[Einar Thorsrud]

Hi Jake,

Please give me some measure to get around this problem

The fact that the next advertising packet in the same advertising event is delayed indicate that the nRF has at least partially received the CONNECT_REQ, but ignores it. This can happen for a couple of reasons:

• CRC failure in the received packet (caused by low RSSI or noise/interference).
• Whitelisting is used, and a non-whitelisted peer attempts to connect.
• Directed advertising is used and another peer attempts to connect - do you by any chance set p_peer_addr in the ble_gap_adv_params_t?

I think it may help if the gap between ADV packets in one event can be widen.

The CONNECT_REQ should always be transmitted 150 μs (T_IFS) after the end of the advertising packet, which there is plenty of room for, so I do not think this is related.

[Jake Yun]

whitelisting nor directed advertising is used in my case.

No other master is trying to connect to my device.

And "p_peer_addr" is explicitly set to "NULL".

RSSI is not low because they are very close.

The only remaining suspect is CRC failure caused by noise/interference.

I may try it in RF anechoic chamber later.

Thank you, Einar.

[Einar Thorsrud]

Hi Jake,

You only mentioned the s140_nrf52_6.1.1 SoftDevice, which I assume you use on the nRF52840. Can you confirm which exact SoftDevice version you are using on the nRF52832?

I have discussed this with a few of the SoftDevice developers, and they have not seen any issues related to this earlier. One could think that the late CONNECT_IND packet could be the problem as it is right on the edge of the Bluetooth specification (150 μs + 2 μs margin), but the SoftDevice adds a few extra μs margin, so that should not be the case. Therefor it just looks like the nRF lost the packet(s) for some reason, as already mentioned. It will be interesting to hear if you get a better result when testing in an RF chamber.

[Jake Yun]

It's s132_nrf52_6.1.1_softdevice for nRF52832.

By the way, I got a call from Prochild, one of Nordic distributor yesterday.

I will try testing with them next week because I have to rent the phone(LG Q7) again.

Thank you.

[Jake Yun]

Hi Einar,
I've tested it again with LG Q7 in shielded area and it did not happen.
I repeated it in shielded area and in my office.
I must agree that it's from outside anyway.
It might be SCAN_REQ from other phones.
As far as I know, there is no way for connectable device to advertise itself as not scannable, isn't it?

[Einar Thorsrud]

Hi Jake,

Thank you for reporting back. That makes sense.

Jake Yun said:

As far as I know, there is no way for connectable device to advertise itself as not scannable, isn't it?

Yes and no. You cannot do nonscannable connectable undirected advertising unless you use extended advertising. However, you can use an empty scan response packet, which is used in many SDK examples.

[Jake Yun]

Thank you for the confirmation, Einar.