Bluetooth cannot send data packets within the connection interval.

RE: Bluetooth cannot send data packets within the connection interval.

HHJ — Sat, 11 Oct 2025 05:44:34 GMT

Thanks bro

Our problem has been solved.

kevin

RE: Bluetooth cannot send data packets within the connection interval.

Edvin — Mon, 29 Sep 2025 08:44:22 GMT

Can you please zip and upload your peripheral and central application, so that I can have a look?

[quote user="HHJ"]approximately 2 out of every 5 packets are queued[/quote]

When you list numbers like this. Does 3 out of every 5 packets return -12 when you try to queue them?

BR,
Edvin

RE: Bluetooth cannot send data packets within the connection interval.

HHJ — Sat, 27 Sep 2025 06:43:32 GMT

I have checked the prj.conf of my ipc_radio, and all the key configurations from the file at v3.1.0\nrf\samples\bluetooth\throughput\sysbuild\ipc_radio\prj.conf have been included in mine.

Interestingly, when my timer K_MSEC() is set to 4 and the connection interval is set to 7.5ms, data packets do not queue (-12), but the rate is 3.8ms, which does not meet our target of 3ms. When K_MSEC() is set to 4 and the connection interval is 15ms, data packets start to queue (approximately 2 out of every 5 packets are queued). When K_MSEC() is set to 3 and the connection interval is 7.5ms, data packets also queue (roughly 1 out of every 3 packets is queued). If K_MSEC() is set to 3 and the connection interval is 15ms, even more data packets will queue.

This seems very much like a blockage at the TX (transmit) end. Regrettably, however, adjusting the value of CONFIG_BT_BUF_ACL_TX_COUNT does not result in any observable changes.

RE: Bluetooth cannot send data packets within the connection interval.

HHJ — Sat, 27 Sep 2025 01:17:59 GMT

Thanks bro

Sorry, I forgot to send you the prj.conf for ipc_radio. I might be missing key configurations in the prj.conf of ipc_radio, so could you please help me check it? I will send it to you right away. You don't need any other hardware; a central device and peripheral devices are sufficient.devzone.nordicsemi.com/.../81441.prj.conf

RE: Bluetooth cannot send data packets within the connection interval.

Edvin — Fri, 26 Sep 2025 10:19:25 GMT

Sorry, I forgot this was the nRF5340. You need to add this config to the sysbuild\ipc_radio\prj.conf. Is that the one that you sent me?

Will I be able to reproduce the behavior that you are seeing if you zip the applications (peripheral and central)? Do I need any external HW, other than a couple of DKs?

Best regards,

Edvin

RE: Bluetooth cannot send data packets within the connection interval.

HHJ — Fri, 26 Sep 2025 09:44:48 GMT

Thanks bro

We have already been using the 2MBPS PHY, and the screenshot from the nRF Sniffer can also serve as evidence. We have adjusted CONFIG_BT_BUF_ACL_TX_COUNT to 30, but the experimental results remain consistent with those before (no changes occurred). Could it be that this configuration is not being implemented? Do we need to add some code in the main function to make it take effect?

In particular, regarding the connection interval: when we increase the connection interval, the number of data packets with the -12 error increases—which corresponds to the increased number of queued data packets you mentioned. The more we extend the interval, the more queued data packets there are, showing a proportional relationship. This has been a point that has confused us.

Attached are all our configurations and the code for the main function, for your reference.devzone.nordicsemi.com/.../0020.prj.conf devzone.nordicsemi.com/.../5700.main.c

RE: Bluetooth cannot send data packets within the connection interval.

Edvin — Fri, 26 Sep 2025 08:23:01 GMT

Right. -12 means ENOMEM (see NCS\zephyr\lib\libc\minimal\include\errno.h)

So -12 is not actually packet loss. It is packet that are never sent/queued. (packet loss is when a packet is sent, but not received and acked by the receiver. This will result in a retransmission from the transmitter, until it is acked).

Every 3ms you are generating a new packet of 242 bytes. That means 333 packets of 242 * 8bits = 644kbps. If you are using 1MBPS PHY, the theoretical limit is roughly 700kbps, so you are pushing the limit.

To maximize the throughput, you could try a bit longer connection interval, perhaps 30ms, and also set your connection event length to the same. Then keep using long packets (242 is fine), and queue up as many as you can.

The issue may be that you need to increase your CONFIG_BT_BUF_ACL_TX_COUNT in prj.conf. I see that by default this is set to 3, meaning you can only have 3 packets in your queue. Try increasing it to 10, or perhaps 20. At least large enough that you have time to transmit the number of packets you intend to send every connection interval. And a little more, to catch up in case of packet loss -> retransmits.

Also, if you are still not able to transmit the data fast enough, consider changing to 2MBPS PHY. For details on how to do this, please read through Lesson 3 Exercise 2 in DevAcademy's Bluetooth Low Energy Fundamentals course. Particularly steps 7-9.

Best regards,

Edvin

RE: Bluetooth cannot send data packets within the connection interval.

HHJ — Fri, 26 Sep 2025 02:31:02 GMT

Thanks bro

These data are 242-byte data generated by me, and they are part of the data package I received at the central end. If there is indeed a backlog on the TX end, there are numerous configurations related to the TX end in the settings. Could you please provide me with a few key configurations to resolve the backlog on the TX transmission end? What I use is peripheral_uart, and the API is also bt_nus_send. Regarding the return value, I already have the return value (-12) for data package loss, just as shown in my first picture. Could you inform Nordic about the -12 error value returned by bt_nus_send, and clarify what kind of error this -12 error value is? What is its complete and precise definition? Thank you very much, Edvin.

RE: Bluetooth cannot send data packets within the connection interval.

Edvin — Thu, 25 Sep 2025 08:57:55 GMT

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

[quote user="HHJ"]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?[/quote]

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

RE: Bluetooth cannot send data packets within the connection interval.

HHJ — Thu, 25 Sep 2025 02:48:20 GMT

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?

RE: Bluetooth cannot send data packets within the connection interval.

Edvin — Wed, 24 Sep 2025 11:30:55 GMT

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.

[quote user="HHJ"]At 4843 23.404347, Bluetooth sends a data packet to the host computer, which replies at 4854 23.405538 – this 1ms+ interval is normal.[/quote]

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.

[quote user="HHJ"]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.[/quote]

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.

[quote user="HHJ"]This is abnormal because it prevents 4 sets of newly generated data from being sent during those 12ms[/quote]

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

RE: Bluetooth cannot send data packets within the connection interval.

HHJ — Wed, 24 Sep 2025 09:36:08 GMT

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.

RE: Bluetooth cannot send data packets within the connection interval.

Edvin — Wed, 24 Sep 2025 08:52:36 GMT

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).

[quote user="HHJ"]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[/quote]

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

BR,

Edvin

RE: Bluetooth cannot send data packets within the connection interval.

HHJ — Wed, 24 Sep 2025 06:38:41 GMT

I sent the wrong file for the 15ms connection interval earlier. This one is the correct file for the 15ms connection interval.devzone.nordicsemi.com/.../7167.15MS_5F00_2.pcapng

RE: Bluetooth cannot send data packets within the connection interval.

HHJ — Wed, 24 Sep 2025 03:44:18 GMT

I'm sorry, I think I didn't express myself clearly earlier. My timer generates and sends a set of data every 3ms. However, 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. Especially with the 15ms connection interval, Bluetooth will reply after more than 10ms. I believe this situation is abnormal and does not conform to our Bluetooth logic. Currently, we are not sure where the problem lies. These are the pcapng files captured by nrf niffer for the 7.5ms and 15ms connection intervals respectively. We look forward to your reply.devzone.nordicsemi.com/.../15ms.pcapng devzone.nordicsemi.com/.../7.5ms.pcapng

RE: Bluetooth cannot send data packets within the connection interval.

Edvin — Tue, 23 Sep 2025 19:57:17 GMT

Hello,

I am not sure I understand exactly what you mean, but I'll try to explain, and please correct me if I misunderstood. Also, if you capture a sniffer trace of the connection, showing these packets being sent, feel free to upload it here, as it may shed some light on what is actually going on. You can use the nRF Sniffer for Bluetooth LE, and upload the .pcapng file here. Remember to select the advertising device from the drop-down menu on the top before entering the connection, so that the sniffer will follow that peripheral into the connection.

Every connection interval (7.5ms) there is a connection event. At this event, the central will start sending a packet to the peripheral. If it has any data to send, it will send it. If not, it will send an "empty" packet, only containing some headers. This is used for timekeeping between the devices.

The peripheral will then respond to the packet. If it has any data to send, that will be sent, but if not, then it will just be another "empty" packet, being used to keep the connection alive.

Both of these packets have a bit in it's headers saying whether or not it has additional data (in addition to the data being sent in that very packet). We call it the "more-data flag"

Let us say that the central doesn't have any data to send, but the peripheral has enough data for two packets. This is how it will look on air:

1: central -> peripheral: empty packet (more data = false)

2: peripheral -> central: data packet (more data = true)

3: central -> peripheral: empty packet (more data = false)

4: peripheral -> central: data packet (more data = false)

Then there is radio silence until the next connection event.

If the peripheral now receives more data from one of it's sensors, it needs to wait for the central to send the next packet in the next connection event. The central's radio is off until that event.

But what happens if the peripheral receives more data to transmit while the connection event is ongoing, let us say after the first packet is sent from the central, but before the peripheral has sent any data, so that would be between step 1 and 2 above. In this case, the softdevice will schedule this data for the next connection event, as the CPU is busy handling the connection event at this point in time. Therefore, the more-data flag will still be false in packet 4, and instead, it will be added to the first packet from the peripheral to the central in the next connection event.

So even if your connection event length is set to 7.5ms, the same as the connection interval, as soon as the more data flag from the peripheral is set to false, the central's radio will be turned off until the next connection event. And even if you decide to add the new packet while there is still communication between the two devices, the SoftDevice controller doesn't have time to change the already scheduled packets before they are aired.

I believe this covers what you are seeing, but if I misunderstood anything, pleaese feel free to correct me.

Best regards,

Edvin

RE: Bluetooth cannot send data packets within the connection interval.

HHJ — Tue, 23 Sep 2025 09:47:14 GMT

Thanks bro

According to your suggestions, our performance has been improved.

We have set the connection interval to 7.5ms and the transmission timing to 3ms. We found that Bluetooth can send data packets normally within the 7.5ms interval. However, after sending the second data packet, Bluetooth will force the next transmission to wait until the end of the 7.5ms connection interval, which causes blockage on the transmitting end.

Currently, we have configured the connection event extension with CONFIG_BT_USER_DATA_LEN_UPDATE=y, CONFIG_BT_CTLR_DATA_LENGTH_MAX=251, and the GAP event interval with CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT=7500.

Are we missing any key configurations such as the "Connection event length extension" in nRF52840, like setting opt.common_opt.conn_evt_evt.enable=true; err_code=sd_ble_opt_set(BLE_COMMON_OPT_CONN_EVT_EVT,&opt);? Or are there any existing configurations that need to be enabled in the main function?

RE: Bluetooth cannot send data packets within the connection interval.

Edvin — Mon, 22 Sep 2025 12:00:29 GMT

Hello,

So when you are saying that you are seeing packets are being failed to send, you mean that you are not able to queue them properly? If a packet is queued, it will be sent, however many retries it uses. This is according to the Bluetooth specification.

So you should see it in the API that you are using to send packets. At some point, it should stop returning 0, and it will start returning an error value.

But the root problem here is that the bluetooth connection doesn't have enough throughput, I guess. You are queuing up packets faster than the device is able to send them, and eventually, you will have packets that are not able to be queued properly.

I can recommend that you check the sample:

v3.1.0\nrf\samples\bluetooth\throughput

Relevant for the nRF5340 are the files:

boards\nrf5340dk_nrf5340_cpuapp.conf
prj.conf
Kconfig.sysbuild
sysbuild\ipc_radio\prj.conf

Note that it is in the last file, sysbuild\ipc_radio\prj.conf that the parameters for connection event length and increased MTU is set. All the parameters that belongs to the radio core on the nRF5340.

This is also described in our DevAcademy Bluetooth Low Energy Fundamentals course. Particularly Lesson 3 is describing how to change the connection parameters.

Best regards,

Edvin