[NRF51822][S130 V2.0.1]Customized BLE Dongle has unexpected disconnect errors 0x22 and 0x3E

[angelforest]

Hi there,

I am developing a BLE dongle, and a BLE peripheral both based on NRF51822QFAC. The BLE dongle scans, connects, and disconnects the BLE peripheral by UART commands, sent by a customized PC GUI.

My problem is I get unexpected disconnect errors occasionally when I use the dongle to connect the BLE peripheral, the unexpected disconnect error codes are 0x22 and 0x3E. 

I did pressure tests on the connection process(let BLE dongle initiated connection and disconnection to the BLE slave repeatedly), and used a Nordic official dongle to sniff the BLE packets. There are several cases when the unexpected disconnection occurs, which are as follows,

1. Disconnection Error = 0x22 (LMP RESPONSE TIMEOUT / LL RESPONSE TIMEOUT):

1) Dongle Initiated a disconnection successfully(0x16), and then the dongle scanned and reconnected to the slave. No CONNECT_REQ captured.

Sniffer only captured SCAN_REQ and SCAN_RSP, but no CONNECT_REQ captured.

The slave kept advertising, and the dongle reported a disconnection error 0x22 after a 4s connection supervision timeout.

2) Dongle Initiated a disconnection, LL_TERMINATE_IND was send many times(kept re-sending in 4s connection supervision time) but no response from the slave.

Dongle gave the disconnection error 0x22.

  

3) Dongle Initiated a disconnection successfully, and tried to scanned and reconnected the slave.

No SCAN_REQ and SCAN_RSP was captured.

2. Disconnection Error = 0x3E (CONNECTION FAILED TO BE ESTABLISHED):

1) Dongle sent CONNECT_REQ successfully, and sent 6 Empty Data PDUs, however, no response from the peripheral. After 4s timeout, the dongle got a 0x3E error.

2) Similarly to the 0x22 first case, SCAN_REQ and SCAN_RSP was sniffed, but CONNECT_REQ was not captured.

 

From the Devzone, I found the issue may be induced by clock accuracy and the boards RF performance. 

To compare with my customized dongle board, I downloaded my dongle firmware into the PCA10028 board, and let the PCA10028 board to connect and disconnect the peripheral. 0x22 and 0x3E occurred as well.

There is no external 32.768KHz crystal oscillator on my dongle board (only one external 16MHz). My LFCLK settings are as below,

 

#define NRF_CLOCK_LFCLKSRC      {.source        = NRF_CLOCK_LF_SRC_RC,            \
                                 .rc_ctiv       = 1,                                \
                                 .rc_temp_ctiv  = 1,                                \
                                 .xtal_accuracy = NRF_CLOCK_LF_XTAL_ACCURACY_20_PPM}

Do anyone know what cause the problem? The RF or the clock accuracy? 

PS: No whitelist advertising on the BLE peripheral.

Thank you very much.

  

[Kenneth]

1.

1) In environment with noise it may be that the sniffer don't receive all the packets.

2) In environments with noise, it may be that the acknowledge from the peripheral, that the disconnect packet was received, is lost. In such case only the peripheral will disconnect, while the central will repeat the disconnect packet until supervisor timeout occurs. This is according the BLE spec.

3) This may be the same case as above, but in this case the sniffer did receive the acknowledge, only the central did not receive it, thereby the sniffer don't anymore monitor that the central is still in a connection until supervisor timeout.

2.

1) In environments with noise, it may be that the connection request from the central was not received by the peripheral. In such case the central will send 6 packets after connection request, if no packet is received from the peripheral during this time, then the central will consider the link failed to establish. This is according the BLE spec.

2)This may be the same case as above, but in this case the sniffer didn't receive the connection request either. Thereby the sniffer doesn't monitor the central try to establish a link.

[angelforest]

Hi Kenneth,

Thank you for your reply.

So you think the disconnect errors 0x22 and 0x3E I met were induced by the environment noise?

I will put the dongle and peripheral in a shielded-box and re-test the disconnect problem. 

How about the LFCLK source setting mentioned above, are the parameters values OK?

Thanks.

[Kenneth]

Ideally you need to set the tolerance to 250ppm when using internal RC, however for the softdevice you are using it will default to 250ppm in any case when using internal RC.

You should be aware that USB3.0 ports can create much in-band 2.4GHz noise, so to also rule out that, make sure you are using a PC with USB2.0 port for shielded test.

[angelforest]

Hi Kenneth,

I have tested the disconnection problem again by putting the customized dongle and BLE peripheral into a shielded-box. 

I used a PC GUI to send commands to control dongle to scan, connect and disconnect the peripheral. I repeated the flow 1000 times as one round. I tested 2 rounds, both rounds has 0x3E disconnect occurs.

However, this time, the air logs at disconnection error are same. Both are that the dongle sent CONNECT_REQ and 6 empty packets, but no response from RC.

What may be the reason? Can you give me some suggestions to find it out?

Thanks. 

[Kenneth]

Hi, how many times do you experience 0x3E during 1000times tests? I expect 1-2% of lost connection request is expected due to noise. Also did you look into my comment about USB3.0?

[angelforest]

Very low probability, less than 1% with in the shielded-box.

Yes, I used USB2.0 instead of USB3.0 this time.

There is a Zigbee module on my peripheral board. I will try again later with shutdown the Zigbee part.