Bluetooth cannot send data packets within the connection interval.

[HHJ]

Our company has previously used the NRF52840, and we know that by modifying the GAP event length (NRF_SDH_BLE_GAP_EVENT_LENGTH), we can enable Bluetooth to transmit multiple data packets within one connection interval. Currently, our NRF5340 is encountering a similar issue: when its transmission speed is greater than the connection interval, it can send normally, but when its transmission speed is less than the connection interval, there will be cases where data packets fail to send (just like packet loss). We want to know what parameters can be configured in NRF5340 with nrf connect v3.1.0 to achieve the effect of GAP event length. We hope you can help us

[Edvin]

Did you do something to your sniffer traces before uploading them? There are a lot of packets with the exact same timestamp in both your traces (which is not the case for the first 15ms.pcapng that you uploaded).

HHJ said:

regardless of whether the connection interval is 7.5ms or 15ms, Bluetooth will reply in the next connection interval after receiving the second data packet

What do you mean by this? Which device will reply? The one sending (peripheral) or the one receiving (central)?

BR,

Edvin

[HHJ]

Thanks bro

I haven't modified the sniffer traces in any way. It's normal for some data packets to have identical timestamps because the responses occur at the 150µs level. Your sniffer might only be configured to display at the millisecond level, which makes the timestamps appear the same.

Please ignore 15ms.pcapng as it's the incorrect file. Instead, focus on 7ms.pcapng and the 15ms_2.pcapng I'll send later.

Here's my transmission logic: The NRF5340 continuously sends data packets to the host computer, which sends a reply upon receipt. Let me explain with a detailed example from 15ms_2.pcapng. At 4843 23.404347, Bluetooth sends a data packet to the host computer, which replies at 4854 23.405538 – this 1ms+ interval is normal. The next set is also normal. However, in the following set, Bluetooth sends a data packet to the host computer at 4857 23.407117, but the host computer doesn't reply until 4854 23.419153, resulting in a 12ms+ interval. This is abnormal because it prevents 4 sets of newly generated data from being sent during those 12ms.

[Edvin]

I am just saying that if you look at the sniffer trace that I should ignore (15ms.pcapng) then no packets have the same timestamp. 

But, I see that the packets around 4843 have a more granular timestamp, so never mind.

HHJ said:

At 4843 23.404347, Bluetooth sends a data packet to the host computer, which replies at 4854 23.405538 – this 1ms+ interval is normal.

I don't understand:

Did you mean that the host computer replied in 4844 23.374151? That makes sense. If so, we see that the central started a connection event in 4840. Setting this as a time reference, we can see that 4844 is 15.001ms later. 

HHJ said:

The next set is also normal. However, in the following set, Bluetooth sends a data packet to the host computer at 4857 23.407117, but the host computer doesn't reply until 4854 23.419153, resulting in a 12ms+ interval.

Here I assume that you mean packet 4857 and 4858. Let us investigate:

Setting a time reference at packet 4852, which is the start of the previous connection event. As you can see, all the packets from the peripheral in the 4852 connection event have the "more data" flag set to true, except for in 4857. So this means that 4857 is the 3rd packet from the peripheral in the previous event, and since this takes some time, when this packet is transmitted, there is no longer 15ms until the next connection event, but it is 12.036ms left until the next connection event starts.

HHJ said:

This is abnormal because it prevents 4 sets of newly generated data from being sent during those 12ms

As I tried to explain in one of my earlier replies, the data was not already queued in the peripheral at the time when packet 4852 was aired. Therefore, from the softdevices perspective, it didn't have any more data to send after packet 4857, and therefore it set the "more data" flag to false in this packet. 

If you continue to queue up then these will all be sent in the next connection event.

Best regards,

Edvin

[HHJ]

Thanks bro

I understand what you mean. When the "more data" signal is false, the central device must respond in the next connection interval. However, I believe there is data loss within a single time interval. As shown in my picture, I marked the packet header sequence numbers for the data generated every 3ms, and the result shows discontinuous sequence numbers due to packet loss.

As indicated in our picture, within the 30ms time interval from 10:26:37.514 to 10:26:37.544, we generated 10 data packets, but the packet sequence numbers from 65 to 74 are discontinuous. If your conclusion is that there is accumulation in the TX (transmitter) side, is there a way for me to expand the capacity of the TX side?

[Edvin]

Where are these numbers coming from? Are these the packets you receive on the central? 

HHJ said:

If your conclusion is that there is accumulation in the TX (transmitter) side, is there a way for me to expand the capacity of the TX side?

That is my theory, but you can confirm this on your end. What API do you use to transmit the data? 

Using the peripheral_uart as an example (NCS\nrf\samples\bluetooth\peripheral_uart), this uses the API bt_nus_send() to send data. This again uses bt_gatt_notify_cb() to send the notification. You probably have a similar funtion calling bt_gatt_notify_cb() or bt_gatt_notify()

This function, bt_gatt_notify_cb() has a return value. It returns 0 on success, and a negative value otherwise. in the peripheral_uart sample, this return value is forwarded to bt_nus_send(), so and this return value is checked after it has been called. 

Do you have a similar return value? Does it return 0 on the values that you claim are missing?

Best regards,

Edvin