Why waking up every conn_interval even with slave latency?

[Primož Kralj]

I have a min connection interval of 200ms and max of 250ms. I have set slave latency to 10. These parameters are set both on peripheral and on central. Still, after connecting peripheral nRF to oscilloscope I can see that it wakes up every connection interval (~250ms). I expected it to wake up every 2500ms. Is this expected (why?) or do I have some other thing going on in the code?

[Ole Bauck]

Are you sure that all the connection parameters are accepted at the central? Some devices may not accept this combination of connection interval and slave latency (e.g. iphone).

What are the current measurements at this intervals? Can it be something else like a repeating task started by app_timer? If you are using RC LFCLK, the clock will be started regulary for calibration. Are you using NRF_CLOCK_LFCLKSRC_RC_250_PPM_250MS_CALIBRATION?

[Primož Kralj]

I have played a bit more and found out that slave latency param has no effect. I am setting the connection parameters on both devices (both nRF51) with ble_gap_conn_params_t; on central with sd_ble_gap_connect() and on peripheral with sd_ble_gap_ppcp_set(). For clock I am using NRF_CLOCK_LFCLKSRC_RC_250_PPM_4000MS_CALIBRATION and I can see it triggering properly.

But these spikes (wakeups) are the same as connection interval, always. Is it possible that central device discards the latency setting and sets it to 0 internally in softdevice? Do you have any other idea? Thanks!

[Ole Bauck]

Are you running any example? Could you check what is done in BLE_GAP_EVT_CONN_PARAM_UPDATE_REQUEST event on the central? Or even better if you manage to sniff the connect request packet, see sniffer.

[Primož Kralj]

I am running heavily modified omnipresent UART example (I can upload it though). I have sniffed the link though, pcap log is here. I am not very keen with reading the packets yet, though.

The only thing happening on central in BLE_GAP_EVT_CONN_PARAM_UPDATE_REQUEST event is:

err_code = sd_ble_gap_conn_param_update(p_gap_evt->conn_handle, &p_gap_evt->params.conn_param_update_request.conn_params);

[Ole Bauck]

ok, then the central is accepting every connection parameter update requests. The sniffer log you gave me was too short, connection parameter update request usually happens some time after the connection. If you are using the ble_conn_params library, it happens FIRST_CONN_PARAMS_UPDATE_DELAY after the connection.