LLPM connection interval and the frequency of data transmission

RE: LLPM connection interval and the frequency of data transmission

LandyWang — Fri, 27 Sep 2024 01:32:37 GMT

Thank you for your explanation.
Now I understand the definition of connection interval and transmission delay.

RE: LLPM connection interval and the frequency of data transmission

Susheel Nuguru — Thu, 26 Sep 2024 07:34:07 GMT

[quote user="LandyWang"]So does it mean that the connection interval = transmission latency = Central -> Peripheral -> Central time divided by 2?[/quote]

Yes, You are right, we calculate this based on the round trip packet exchange. So to get the latency of one packet transfer is averaged by dividing the round trip time by 2.

Connection interval = time between start packet transfer in one direction.
Latency = Ideally is same as connection interval, but we measure it with write response (two way trip time divided by 2)

RE: LLPM connection interval and the frequency of data transmission

LandyWang — Fri, 20 Sep 2024 07:59:17 GMT

The distance between the two DKs is about 3 cm.

When running the LLPM sample without any modification to the code, the printed transmission latency is about 1ms, which is consistent with the Sample output in README.rst.

But according to the description on README.rst, transmission latency is the time of Central -> Peripheral -> Central divided by 2.

According to the information printed out by the LLPM sample, when the connection interval switches to 1ms, the transmission latency is about 1ms. When the connection interval switches to 7.5ms, the transmission latency is about 7.5ms.

So does it mean that the connection interval = transmission latency = Central -> Peripheral -> Central time divided by 2?

However, in my understanding, the connection interval refers to the shortest interval between transmitting one data packet and then transmitting the second data packet.

This is the conclusion I got by adjusting CONFIG_BT_PERIPHERAL_PREF_MIN_INT when using non-LLPM ble code.

I'm sorry that I didn't describe it clearly before. What I am confused about is which definition of connection interval is.

RE: LLPM connection interval and the frequency of data transmission

Simonr — Fri, 20 Sep 2024 07:23:26 GMT

Okay, thank you for explaining. Can you try running just the LLPM samples as is on your end to see if the printed transmission latency is able to report down to 1ms? Also, what kind of environment are you testing in here, and how far apart are the two DKs you're running tests on exactly?

Best regards,

Simon

RE: LLPM connection interval and the frequency of data transmission

LandyWang — Wed, 18 Sep 2024 02:10:50 GMT

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.

RE: LLPM connection interval and the frequency of data transmission

Simonr — Mon, 16 Sep 2024 11:14:12 GMT

[quote user="LandyWang"]k_cycle_get_32[/quote]

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

RE: LLPM connection interval and the frequency of data transmission

LandyWang — Fri, 13 Sep 2024 05:56:51 GMT

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.

RE: LLPM connection interval and the frequency of data transmission

Simonr — Thu, 12 Sep 2024 11:45:45 GMT

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

RE: LLPM connection interval and the frequency of data transmission

LandyWang — Wed, 11 Sep 2024 07:03:03 GMT

[quote userid="75734" url="~/f/nordic-q-a/114577/llpm-connection-interval-and-the-frequency-of-data-transmission/502026"]Do you have two devices with the LLPM sample flashed on your end, or is it connected to something else?[/quote]

I burned the llpm code on both nrf52840 DKs.

In order to obtain the time point when the receiving end received the data, I made the following modifications:

(1)Add receive data callback. When data is received, latency_request will be entered.

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;
	}
	...
}

(2)Read the current time in latency_requst and print it out.

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));
}

(3)When transmitting data, remove the default k_sleep so that it can transmit data uninterrupted.

static void test_run(void)
{
    ...
    /* Start sending the timestamp to its peer */
	while (default_conn) {
	    ...
	    //k_sleep(K_MSEC(200)); /* Don't wait */
	    ...
	}
}

After making the above modifications, I burned the modified code onto two nrf52840 DKs.

After burning, one nrf52840 DK will be used as central and the other nrf52840 DK will be used as peripheral.

After Central and Peripheral are connected, send a UART command to let central start sending data to peripheral.

central log:

*** Booting nRF Connect SDK v3.5.99-ncs1 ***
Starting Bluetooth LLPM example
I: SoftDevice Controller build revision: 
I: 36 f0 e5 0e 87 68 48 fb |6....hH.
I: 02 fd 9f 82 cc 32 e5 7b |.....2.{
I: 91 b1 5c ed             |..\.    
I: HW Platform: Nordic Semiconductor (0x0002)
I: HW Variant: nRF52x (0x0002)
I: Firmware: Standard Bluetooth controller (0x00) Version 54.58864 Build 1214809870
I: Identity: C3:1B:EF:44:AA:E6 (random)
I: HCI: version 5.4 (0x0d) revision 0x118f, manufacturer 0x0059
I: LMP: version 5.4 (0x0d) subver 0x118f
Bluetooth initialized
LLPM mode enabled
Choose device role - type c (central) or p (peripheral): 
Central. Starting scanning
Scanning successfully started
Connection event reports enabled
Filter does not match. Address: 71:2F:D9:01:48:D6 (random) connectable: 1
Filter does not match. Address: 4B:63:ED:0E:66:FC (random) connectable: 1
Filter does not match. Address: 67:E4:6F:8C:76:CA (random) connectable: 0
Filters matched. Address: C2:59:EE:EE:B9:10 (random) connectable: 1
Filter does not match. Address: 45:98:C2:98:66:E5 (random) connectable: 0
Connected as central
Conn. interval is 3329 units (1.25 ms/unit)
Security changed: level 2, err: 0
Service discovery completed
Press any key to start measuring transmission latency
Did not receive a latency response
Did not receive a latency response
Did not receive a latency response
Did not receive a latency response
Did not receive a latency response
Did not receive a latency response
Did not receive a latency response
Did not receive a latency response
Did not receive a latency response
Did not receive a latency response
Did not receive a latency response
Did not receive a latency response

peripheral log:

*** Booting nRF Connect SDK v3.5.99-ncs1 ***
Starting Bluetooth LLPM example
I: SoftDevice Controller build revision: 
I: 36 f0 e5 0e 87 68 48 fb |6....hH.
I: 02 fd 9f 82 cc 32 e5 7b |.....2.{
I: 91 b1 5c ed             |..\.    
I: HW Platform: Nordic Semiconductor (0x0002)
I: HW Variant: nRF52x (0x0002)
I: Firmware: Standard Bluetooth controller (0x00) Version 54.58864 Build 1214809870
I: Identity: C2:59:EE:EE:B9:10 (random)
I: HCI: version 5.4 (0x0d) revision 0x118f, manufacturer 0x0059
I: LMP: version 5.4 (0x0d) subver 0x118f
Bluetooth initialized
LLPM mode enabled
Choose device role - type c (central) or p (peripheral): 
Peripheral. Starting advertising
Advertising successfully started
Connection event reports enabled
W: opcode 0x200a status 0x0d
Connected as peripheral
Conn. interval is 3329 units (1.25 ms/unit)
W: opcode 0x2032 status 0x3a
E: Failed LE Set PHY (-5)
Security changed: level 2, err: 0
Service discovery completed
Press any key to start measuring transmission latency
Recived Data time:2522 ms
Recived Data time:2528 ms
Recived Data time:2534 ms
Recived Data time:2539 ms
Recived Data time:2545 ms
Recived Data time:2551 ms
Recived Data time:2557 ms
Recived Data time:2563 ms
Recived Data time:2568 ms
Recived Data time:2574 ms
Recived Data time:2580 ms
Recived Data time:2586 ms
Recived Data time:2592 ms
Recived Data time:2597 ms
Recived Data time:2603 ms
Recived Data time:2609 ms
Recived Data time:2615 ms
Recived Data time:2621 ms
Recived Data time:2626 ms
Recived Data time:2632 ms
Recived Data time:2638 ms
Recived Data time:2644 ms
Recived Data time:2650 ms
Recived Data time:2656 ms
Recived Data time:2662 ms
Recived Data time:2667 ms
Recived Data time:2673 ms
Recived Data time:2679 ms
Connection interval updated: 7.5 ms
Recived Data time:2692 ms
Recived Data time:2707 ms
Recived Data time:2722 ms
Recived Data time:2744 ms
Recived Data time:2759 ms
Recived Data time:2774 ms
Connection interval updated: LLPM (1 ms)
Recived Data time:2787 ms
Recived Data time:2792 ms
Recived Data time:2798 ms
Recived Data time:2804 ms
Recived Data time:2810 ms
Recived Data time:2817 ms
Recived Data time:2827 ms
Recived Data time:2833 ms
Recived Data time:2839 ms
Recived Data time:2844 ms
Recived Data time:2850 ms
Recived Data time:2856 ms
Connection interval updated: 7.5 ms
Recived Data time:2868 ms
Recived Data time:2883 ms
Recived Data time:2898 ms
Recived Data time:2921 ms
Recived Data time:2936 ms
Recived Data time:2951 ms
Connection interval updated: LLPM (1 ms)
Recived Data time:2962 ms
Recived Data time:2968 ms
Recived Data time:2974 ms
Recived Data time:2980 ms
Recived Data time:2986 ms
Recived Data time:2993 ms
Recived Data time:3003 ms
Recived Data time:3009 ms
Recived Data time:3015 ms
Recived Data time:3020 ms
Recived Data time:3026 ms
Recived Data time:3032 ms

Judging from the peripheral log, when the connection interval is updated to 1ms, the time interval between receiving two sets of data is 5ms to 8ms, and when the connection interval is updated to 7.5ms, the time interval between receiving two sets of data will be 15ms.

[quote userid="121867" url="~/f/nordic-q-a/114577/llpm-connection-interval-and-the-frequency-of-data-transmission"]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.[/quote]

According to the description here, when the connection interval is 1ms, after sending one set of data, the next set of data can be sent at an interval of 1ms. Then the time to receive the two sets of data should also be 1ms,as shown in the picture. But the actual measurement is 5 to 8ms, is there something wrong with my understanding?

RE: LLPM connection interval and the frequency of data transmission

Simonr — Wed, 11 Sep 2024 05:50:43 GMT

Yes, sorry. In LLPM the connection interval can be as low as 1 ms. Do you have two devices with the LLPM sample flashed on your end, or is it connected to something else? If not, I'm guessing the device you're connecting to does not support LLPM which is why the connection interval jumps up to 7.5ms.

Please share some details on what exactly you're testing on your end.

Best regards,

Simon

RE: LLPM connection interval and the frequency of data transmission

LandyWang — Tue, 10 Sep 2024 07:44:50 GMT

Thank you for your reply.

Referring to this post, LLPM supports connection interval values of 1ms to 6ms. Does this mean that LLPM's data transmission interval can reach 1ms to 6ms?

RE: LLPM connection interval and the frequency of data transmission

Simonr — Tue, 10 Sep 2024 07:37:43 GMT

Short and to the point, the connection interval is the interval at which two devices in a connection wake up to exchange data. The valid connection intervals for a Bluetooth LE connection is 7.5ms to 4s, which is why you don't see it go down to 1ms as that is not a valid connection interval for a BLE connection.

Best regards,

Simon