Missing data samples at reasonable connection intervals.

[la-ble]

I have a test set up using the ble_app_hrs example where I increment a dummy uint16_t periodically and then send that value up to the nRF Toolbox iOS app to plot. I want to do this as fast as possible to stream debug data, ideally every 25ms, but get a repeating sample and a skipped sample periodically, even when my max connection interval is 45ms!

#define MIN_CONN_INTERVAL                    (MSEC_TO_UNITS(10, UNIT_1_25_MS))
#define MAX_CONN_INTERVAL                    (MSEC_TO_UNITS(40, UNIT_1_25_MS))

The Flow

I'm using app_timer to periodically call app_sched_event_put to execute my simple callback in the main loop/context, right now every 50ms.

static uint16_t dummy = 0;
err_code = ble_hrs_heart_rate_measurement_send(&hrs, dummy++);

I'm reading online that I should be able to connect as fast as ~18ms, but just found a failure (repeated number occasionally) with a 40ms max connection interval. Is there anything else that goes into figuring out what my minimum connection interval can be besides these constants?

• timer interval = 50ms
• min conn interval =10ms
• max conn interval = 40ms
• environmental noise?

Is there a function in code to toggle a gpio to check what my connection interval really turns out to be?

[la-ble]

This post seems to show a way to confirm the chosen connection interval: devzone.nordicsemi.com/.../

[Stefan Birnir Sverrisson]

Hi

I saw you already found this thread about what the actual connection interval is. This thread also discusses a little about IOS connection intervals.

I would assume that if the connection interval is smaller than the sampling interval, then the data should go through. An interference will cause some problems though if some packets need to be retransmitted. Also if you have something else running on your chip that may delay the execution of your task, that might be a problem. What if you execute your task and deliver your data to the softdevice from the app_timer handler, i.e. without calling the scheduler, do you get better results.

One way to debug is to toggle a GPIO pin every time you deliver your data to the softdevice, and then monitor that pin with a logical analyzer or scope, to see if at any time the time interval between two toggles is shorter than the BLE connection interval. If so, then it has something to do with priorities of your task, and you would need to consider executing your task in the app_timer handler, which has higher priority than the main context.

[la-ble]

This is helpful thank you. Nothing else is really happening on the chip. Last I looked it took ~77us from when the app_timer begins to when the code is executed in the main loop via the scheduler.

[Stefan Birnir Sverrisson]

I think the only thing to do is to debug this in order to know what is going on. As mentioned before, try to have a smaller max connection interval or try to execute your task in the interrupt handler, to see if that changes anything.