LLPM connection interval and the frequency of data transmission

[LandyWang]

Hello,

I'm using the llpm sample code on nrf52840.

I'm confused about the connection interval.

From this post, I thought that the connection interval is equivalent to the shortest time interval for transmitting data, that is, after the first data packet is transmitted, the second data packet can be transmitted after waiting for the connection interval time.

Also, when I use non-llpm ble code, I can also change the minimum interval for transmitting data by modifying CONFIG_BT_PERIPHERAL_PREF_MIN_INT, and the description of CONFIG_BT_PERIPHERAL_PREF_MIN_INT is also related to the connection interval.

But I modified the following part in the llpm code to detect the time interval for receiving data, and found that when the connection interval is 1ms, the shortest interval for receiving data is still 7.5ms.

static void test_run(void)
{
    ...
    /* Start sending the timestamp to its peer */
	while (default_conn) {
	    ...
	    //k_sleep(K_MSEC(200)); /* Don't wait */
	    ...
	}
}
void latency_request(const void *buf, uint16_t len)
{
	uint32_t time = k_cycle_get_32();
	uint8_t value[len];
	memcpy(value,buf,len);
	printk("Recived Data time:%u ms\n",(k_cyc_to_ns_near32(time)/1000000));
}

int main(void)
{
	int err;
	...
	static const struct bt_latency_cb data_callbacks =
    {
        .latency_request = latency_request,
    };

	//err = bt_latency_init(&latency, NULL);
	err = bt_latency_init(&latency, &data_callbacks);
	if (err) {
		printk("Latency service initialization failed (err %d)\n", err);
		return 0;
	}
	...
}

Now I am confused about what the connection interval means? Is it related to the interval of transmitting data?

[Simonr]

Hi

Where do you measure this time taken exactly? If you measure the time between received data sets on the VCOM terminal on your computer there is likely a delay between the nRF and the COM port as there is some overhead handling and printing the data too. If you have a Bluetooth Sniffer or another DK to use the nRF Sniffer and see the actual delta time between data packets sent. 

Best regards,

Simon

[LandyWang]

I use k_cycle_get_32 to directly obtain the time when data is received.

void latency_request(const void *buf, uint16_t len)
{
	uint32_t time = k_cycle_get_32();
	uint8_t value[len];
	memcpy(value,buf,len);
	printk("Recived Data time:%u ms\n",(k_cyc_to_ns_near32(time)/1000000));
}

I think using this method to obtain the time should not be affected by the printed data.

[Simonr]

LandyWang said:

k_cycle_get_32

You're right, k_cycle_get_32 should give the cycle count of the RTC at the time the function is executed. This is still using RTC though, which leans on the LF clock, so if you want nano second accuracy this probably wouldn't be sufficient with k_cyc_to_ns_near32.

If you want higher precision timing, then getting it from the RTOS is not a good option, you should initialize a timer instance of your own using HFCLK. 

Best regards,

Simon

[LandyWang]

That's okay, I don't need more precise timing. I just want the timing to be unaffected by printing delays or delays between the nRF and COM ports. It seems that the one currently in use will not be affected.

I still want to focus on the connection interval of LLPM.

According to my expectation, as shown in this picture:

LLPM supports a Connection interval of 1ms, so I should see in the peripheral log that the time interval for each data reception is 1ms.

But in fact, when the connection interval is set to 1ms, the time interval for peripheral to receive data is 7.5ms.

That's why I wonder if my understanding of llpm's connection interval is wrong.