BLE Central disconnect after exactly 65.5 sec

[Gordon]

Hi,

I'm having a problem at the moment with code based on Espruino on nrf52.

I connect as follows:

  ble_gap_scan_params_t     m_scan_param;
  memset(&m_scan_param, 0, sizeof(m_scan_param));
  m_scan_param.active       = 1;            // Active scanning set.
  m_scan_param.interval     = MSEC_TO_UNITS(100, UNIT_0_625_MS); // Scan interval.
  m_scan_param.window       = MSEC_TO_UNITS(90, UNIT_0_625_MS); // Scan window.
  m_scan_param.timeout      = 4;            // 4 second timeout.

  ble_gap_conn_params_t   gap_conn_params;
  memset(&gap_conn_params, 0, sizeof(gap_conn_params));
  gap_conn_params.min_conn_interval = MSEC_TO_UNITS(7.5, UNIT_1_25_MS);
  gap_conn_params.max_conn_interval = MSEC_TO_UNITS(500, UNIT_1_25_MS);
  gap_conn_params.slave_latency     = 0;
  gap_conn_params.conn_sup_timeout  = MSEC_TO_UNITS(4000, UNIT_10_MS);

  ble_gap_addr_t addr;
  addr = peer_addr;

  err_code = sd_ble_gap_connect(&addr, &m_scan_param, &gap_conn_params);

Connecting from one device running Espruino to another (both nRF52832DK), and 65.5 seconds after getting a BLE_GAP_EVT_CONNECTED the DK acting as central Espruino gets a BLE_GAP_EVT_DISCONNECTED event. Every time it disconnects, and every time it takes 65.5 seconds.

This doesn't happen when a PC/Android phone acts as Central connecting to a DK, and it doesn't happen when a DK acting as central connects to something else. It's only when one DK connects to another.

Any idea what might be the problem?

If needed I can supply a hex file and the sample code to reproduce this.

thanks!

Original Sniffer trace (sniffingbroken?): nrf52dk_disconnect.pcapng

Connected, start notifications, send one notification, then it exits

These traces I just connected it and didn't do anything else:

Android nRF Connect -> DK trace (disconnected by me after 70s) : nrf52dk_android.pcapng

iOS nRF Connect -> DK trace (disconnected by me after 70s) : nrf52dk_ios_nrfconnect.pcapng

DK -> DK trace (disconnected itself after 65.5s) : nrf52dk_espruino.pcapng

[Petter Myhre]

Thx. I'm not sure what is happening here, but from the sniffer trace it doesn't seem like the peripheral is disconnecting. From the trace it seems like there is no communication after 30.5s, and then 35s later the peripheral starts to advertise again? Do you start advertising again when you get the disconnection event? It also seems like the peripheral is sending a Connection Parameter Update request, are you calling sd_ble_gap_conn_param_update() somewhere? If you are, could you try not doing that? Please add the new sniffer trace as well.

[Gordon]

Odd - actually I didn't notice the gap. I assumed it went straight from the PDUs to advertising. But yes, advertising starts again immediately on disconnection. I had been using ble-conn-params because that's what was used in one of the other examples - but have just removed that and it now works (even though disconnect_on_fail was false before). Just before I set this to answered - what am I missing by not having ble-conn-params - is it anything important?

[Petter Myhre]

Difficult to say if it is important for your application or not, without it the peripheral will not send connection parameter update requests, it will not request to update the connection parameters (connection interval, slave latency, connection supervision timeout).

[Gordon]

Ok - but those are negotiated at the start? It's only if I wanted to be able to change them 'on the fly'?

[Petter Myhre]

Not really negotiated, the central decides what connection parameters to use upon connection. Then the central can do a connection parameter update (with or without the peripheral sending a connection parameter update request first).

[Gordon]

Ahh, thanks! That explains a lot (like why the interval was much less than I was expecting). So do we have any idea how it could have been disconnecting? Or was it somehow updating the parameters such that the interval for transmissions was far too high?