Random disconnect -> timeout 0x08

RE: Random disconnect -> timeout 0x08

schef — Fri, 03 Feb 2017 14:26:39 GMT

Now it starts. I have to check it more out too see if it is improved. Thanks.

RE: Random disconnect -> timeout 0x08

Petter Myhre — Fri, 03 Feb 2017 13:35:07 GMT

Ok. Seems to be a bug in the documentation, please try:

nrf_clock_lf_cfg_t rc_cfg = {
    .source = NRF_CLOCK_LF_SRC_RC,
    .rc_ctiv = 16, // check every 4 * 250ms
    .rc_temp_ctiv = 2, // only calibrate if temperature has changed.
};

instead.

RE: Random disconnect -> timeout 0x08

schef — Fri, 03 Feb 2017 07:12:06 GMT

When i add the code you suggested it compiles and flash-es but device seems like dead. I added you code, commented nrf_clock_lf_cfg_t clock_lf_cfg = NRF_CLOCK_LFCLKSRC; and replaced SOFTDEVICE_HANDLER_INIT(&clock_lf_cfg, NULL); with SOFTDEVICE_HANDLER_INIT(&rc_cfg, NULL);

RE: Random disconnect -> timeout 0x08

Petter Myhre — Thu, 02 Feb 2017 19:54:20 GMT

What do you mean?

RE: Random disconnect -> timeout 0x08

schef — Thu, 02 Feb 2017 10:52:58 GMT

It does not start at all if i make this changes.

RE: Random disconnect -> timeout 0x08

Petter Myhre — Thu, 02 Feb 2017 10:27:12 GMT

However, you can try to use the internal RC oscillator to see if that changes anything:

nrf_clock_lf_cfg_t rc_cfg = {
   .source = NRF_CLOCK_LF_SRC_RC,
   .rc_ctiv = 4, // check every 4 * 250ms
   .rc_temp_ctiv = 1, // only calibrate if temperature has changed.
};

Change it inside ble_stack_init().

RE: Random disconnect -> timeout 0x08

Petter Myhre — Thu, 02 Feb 2017 10:24:16 GMT

Ok. That's good. It is actually the central device that dictates the supervision timeout. You can check it when you get the BLE_GAP_EVT_CONNECTED event:

p_ble_evt->evt.gap_evt.params.connected.conn_params.conn_sup_timeout

You should also check it when you get the BLE_GAP_EVT_CONN_PARAM_UPDATE event.

But if you have tested with several central devices I believe this is a dead end, you could check it to be sure of course.

Ohh, I thought you were using one of our DKs, the PCA10040, not a module. Then it could be a crystal issue. The PCA100040 has a LF crystal with 20 ppm, and this is what the examples assume is used. If the ppm of the crystal used in Nina-B1 is higher than 20 ppm you can see issues like this. I had a look at the datasheet, but I was able to find the and ppm value for the crystal used.

RE: Random disconnect -> timeout 0x08

schef — Thu, 02 Feb 2017 09:54:57 GMT

I have #define CONN_SUP_TIMEOUT MSEC_TO_UNITS(4000, UNIT_10_MS). Is it possible that the Master changes the supervision timeout? I saw that i have in conn_params_init() function cp_init.p_conn_params = NULL; which means that the Master can change the parameters? I have tried with few devices (android/linux) and 2 nrf52832 (evk-nina-b1) boards.

RE: Random disconnect -> timeout 0x08

Petter Myhre — Thu, 02 Feb 2017 09:43:36 GMT

I see. The BLE_HCI_CONNECTION_TIMEOUT disconnect reason means that the connection timed out, no packets were received from the peer and the supervision timer expired.

If you haven't changed the supervision timeout or the output power, this is typically because of hardware issues (assuming the distance between the devices are small). For example that the antenna is not working properly, that the crystal isn't working properly and so on.

The problem could be with the PCA10040, or the device you are connecting to. Do you have any other devices to test with?

RE: Random disconnect -> timeout 0x08

schef — Thu, 02 Feb 2017 08:57:31 GMT

This is a separate problem. Not related to 30s timeout. It happens randomly evan if i don't do anything. Sometimes instantly, sometimes after 3 seconds, sometime after 2 minutes. It is not related to write/read response.

RE: Random disconnect -> timeout 0x08

Petter Myhre — Thu, 02 Feb 2017 08:31:33 GMT

Why didn't you just edit your question and add the this information there?