LLPM connection interval and the frequency of data transmission

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?

  • 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

  • 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?

  • Hi

    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

  • Do you have two devices with the LLPM sample flashed on your end, or is it connected to something else?

    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.

    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.

    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?

  • 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

Related