NUS Central Write To Peripheral RX Characteristic Very Slow

RE: NUS Central Write To Peripheral RX Characteristic Very Slow

Simonr — Mon, 22 Jul 2024 13:57:40 GMT

Hieu is now out of office, so this case has been assigned to me.

Indeed, the connection interval will impact the throughput rate. This is because the interval will set how long the connection will take, so it will leave more time for the data transmissions and less "down-time". The only real downside will indeed be current consumption increasing, as well as the chance of finding new connectable devices, as it will just keep connecting to the already existing one I believe.

Best regards,

Simon

RE: NUS Central Write To Peripheral RX Characteristic Very Slow

DB_ECD — Wed, 17 Jul 2024 10:40:39 GMT

Hello Hieu,

I tried these config values at the very beginning already. I just comiled it again using these values, but it did not significantly improve the result.

However, I kept changing and trying different things and found out that the connection interval value has a huge impact on the througput rate (as to be expected tbh).

How is this working exactly? Are all the messages as configured in the buffer related configuration values processed and buffered and then sent all at once on every connection event, i.e. channel hop?

As a related question: is there a downside besides increased currend consumption to reducing the connection interval time to a small value of a few ms?

I believe that it's really coming down to chosing just the right connection as well as configuration parameters. If there just weren't so many possibilities.. Anyway, thanks again for all your help so far!

RE: NUS Central Write To Peripheral RX Characteristic Very Slow

Hieu — Thu, 11 Jul 2024 22:18:50 GMT

I notice some of your configuration differs from that in the Throughput sample. The buffer related ones could explain the issue. Could you please add these configurations and retry?

CONFIG_BT_USER_DATA_LEN_UPDATE=y
CONFIG_BT_USER_PHY_UPDATE=y
CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=n

CONFIG_BT_BUF_ACL_RX_SIZE=502
CONFIG_BT_ATT_PREPARE_COUNT=2
CONFIG_BT_L2CAP_TX_BUF_COUNT=10
CONFIG_BT_L2CAP_TX_MTU=498
CONFIG_BT_L2CAP_DYNAMIC_CHANNEL=y
CONFIG_BT_CONN_TX_MAX=10
CONFIG_BT_BUF_ACL_TX_COUNT=10
CONFIG_BT_BUF_ACL_TX_SIZE=502

CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_CTLR_PHY_2M=y
CONFIG_BT_CTLR_PHY_CODED=y
CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT=4000000

RE: NUS Central Write To Peripheral RX Characteristic Very Slow

DB_ECD — Wed, 10 Jul 2024 09:56:43 GMT

Thanks for your reply and sorry for my delay as well, I was on a short vacation the last week.

The log and Sniffer did come from the same test.

I ran the test again, this time using 20 packets (where the first byte of every packet is used as a package counter), the data of which you'll find here:

devzone.nordicsemi.com/.../5340.2024_2D00_07_2D00_10_5F00_DataRateTest2.zip

Here, I encountered basically all the same things as before:

on the peripheral side: a 4-4-4-5-3 spread
(as seen in the Log_peripheral, Uart_peripheral and sniffer-pcap files)
on the central side: a 4-4-4-4-4 spread
(as seen in the Log_central file)

[quote userid="9456" url="~/f/nordic-q-a/111967/nus-central-write-to-peripheral-rx-characteristic-very-slow/491684"]P.s: You can also try increasing CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT. It is probably a good idea to increase it by just a little bit to experimentally verify it is working first.[/quote]

I actually already did that on the central side, increasing this number to the maximum value of 4.000.000. This was used in the test above as well. Changing this value did not seem to improve/worsen the result.

I have to admit that I am kind of lost here.

PS: here are the prj.conf files for peripheral and central, if you need them.

devzone.nordicsemi.com/.../prj_5F00_configs.zip

RE: NUS Central Write To Peripheral RX Characteristic Very Slow

Hieu — Mon, 01 Jul 2024 19:42:50 GMT

P.s: You can also try increasing CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT. It is probably a good idea to increase it by just a little bit to experimentally verify it is working first.

RE: NUS Central Write To Peripheral RX Characteristic Very Slow

Hieu — Mon, 01 Jul 2024 19:15:24 GMT

Hello DB_ECD,

I am very sorry for the delay.

The sniffer log show that the transfer was done over three connection events. 4 chunks in the first connection event at t~=7.49; 5 chunks in the next event, and 1 chunk in the last one. So overall, it matches up with your observation of that the transmission took 800ms.

It mismatches with the log a little, where the chunks are sent in a 4-4-2 spread. Do the log and the sniffer come from the same test?

This is a little important because I think this might be Connection Event Length Extension at work, where the SoftDevice Controller increase the Connection Event Length if there are more data to send, but only by one TX-RX pair at a time. See Scheduling (nordicsemi.com).

The 4-5-1 spread matches that behavior, but the 4-4-2 one doesn't.

Do you mind repeating this experiment with more chunks?

Also, it might be a little helpful with reading the sniffer log to add some manner of ASCII counter in the payload.

RE: NUS Central Write To Peripheral RX Characteristic Very Slow

DB_ECD — Wed, 26 Jun 2024 12:16:15 GMT

Hello Hieu,

do you have any updates for me?

RE: NUS Central Write To Peripheral RX Characteristic Very Slow

DB_ECD — Fri, 21 Jun 2024 09:38:39 GMT

Hello Hieu,

I'm sorry for my late reply, I had some urgent work issues to address.

Now I tried my communication chain again with the same outcome. The attached .zip-file contains the following:

Logs of both the central as well as the peripheral (where you can see the timestamps with the delay)
A screenshot of the uart output of the peripheral, where you can see that all 2440 bytes were received and transmitted in 820 ms
the wireshark capture of these events

devzone.nordicsemi.com/.../DataRateTest.zip

The only thing I can detect right now is that there is a change in the "Channel index" every time there is this time delay.

I hope, this will give you further information to work with. If you need anything else please let me know.

Thanks!

RE: NUS Central Write To Peripheral RX Characteristic Very Slow

DB_ECD — Tue, 11 Jun 2024 13:44:31 GMT

Hi Hieu,

[quote userid="9456" url="~/f/nordic-q-a/111967/nus-central-write-to-peripheral-rx-characteristic-very-slow/488348"]lright, but SystemView is quite valuable when trying to debug issues regarding threads and OS timing, so perhaps this need to be looked into someday.[/quote]

It sounded good to me too and I was kind of bummed out it crashed every time. I'll look into that when I have a little bit more time.

[quote userid="9456" url="~/f/nordic-q-a/111967/nus-central-write-to-peripheral-rx-characteristic-very-slow/488348"]

Your log says the MTU size is 244, and the data you are trying to send is also 244.

3 bytes are necessary for the ATT Opcode and Handle, so you only have 241 bytes for each packet. Your 244 bytes then will be split into two packets.

Each of them when write with response will take one connection interval. This means that the worst case wait time is two connection intervals. Because your interval is 320ms, the worst case is 640ms. Does this sound right?

[/quote]

Not quite right. I Set the MTU in the prj.conf file (both on central and peripheral) with CONFIG_BT_L2CAP_TX_MTU=247 while the Log you see in the original post is created using

uint16_t payload_mtu =
	bt_gatt_get_mtu(conn) - 3; // 3 bytes used for Attribute headers.
LOG_INF("New MTU: %d bytes", payload_mtu);

Therfore it should be possible to send 244 bytes in one packet, right? Also, the interval number in the Log is the value from conn.h:

/** Connection parameters for LE connections */
struct bt_le_conn_param {
	uint16_t interval_min;
	uint16_t interval_max;
	uint16_t latency;
	uint16_t timeout;
};

The actual time should be interval * 1.25ms = 320 * 1.25 = 400 ms. Is this correct? However, I just used these Connection Parameter values because they resultet in a good data rate in the Thoughput example. Is there a way to figure out optimum values based on packet length etc. (i.e. actual values from my project)?

[quote userid="9456" url="~/f/nordic-q-a/111967/nus-central-write-to-peripheral-rx-characteristic-very-slow/488348"]Can you get me a sniffer trace of all the cases that you want to analyze?[/quote]

I'll do that tomorrow!

RE: NUS Central Write To Peripheral RX Characteristic Very Slow

Hieu — Tue, 11 Jun 2024 13:14:57 GMT

Hi DB_ECD,

[quote user="DB_ECD"]Thank you for your reply. However, SystemView crashes immediately every time it is supposed to capture the data. I tried it for some time now, sorry to say that this seems like wasted time to me.[/quote]

Alright, but SystemView is quite valuable when trying to debug issues regarding threads and OS timing, so perhaps this need to be looked into someday.

But that qualifies for a dedicated case of its own. For this topic, we can try another approach.

[quote user=""]I know that the Throughput example uses bt_gatt_write_withous_response() while the nus_client uses bt_gatt_write() which, if I'm correct, has an acknowledge in the link layer included. But I don't think that this would cause this huge delay...[/quote]

Your log says the MTU size is 244, and the data you are trying to send is also 244.

3 bytes are necessary for the ATT Opcode and Handle, so you only have 241 bytes for each packet. Your 244 bytes then will be split into two packets.

If not, we might want to take a sniffer log and examine the data.

[quote user="DB_ECD"]

Simple stuff basically, no delay or sleep or anything. However, in the LOG output I notice that the sending is happening in some kind of time chunks, as you can see here:

...

Between Blocks 4/5 and 8/9, there is again a delay of 250/400ms respectively.

Now I don't really understand why this is happening. Shouldn't bt_gatt_write_without_response() send out the data as fast as possible? What is the cause of the delay here?

[/quote]

It could be that the connection event is being ended prematurely. We will need to look into the sniffer trace to see why though.

Can you get me a sniffer trace of all the cases that you want to analyze?

Hieu

RE: NUS Central Write To Peripheral RX Characteristic Very Slow

DB_ECD — Tue, 11 Jun 2024 08:19:07 GMT

Hello again,

I changed some things around that I'd like to let you know:

within the central_uart.c main() function, bt_nus_client_send() is called
this function in turn (within nus_client.c) calls bt_gatt_write() (which than again should promt the callback that causes the above mentioned delay)
I now changed the bt_gatt_write() to bt_gatt_write_without_response(), as this is used withing the Throughput example.

Now, within the main() of central_uart.c I call the bt_nus_client_send() in a loop like so:

int main(void)
{
    // ...
    // INITIALIZATIONS
    // ...

	for (int i = 0; i < 10; i++) 
	{
		uint8_t pucBuf[UART_BUF_SIZE] = 
		{
			// DUMMY DATA; e.g.:
			0x00, 0x01, 0x02, 0x03
		};

		LOG_DBG("Sending data block no %d", i + 1);

		err = bt_nus_client_send(&nus_client, pucBuf, sizeof(pucBuf));
		if (err) 
		{
			LOG_WRN("Failed to send data over BLE connection"
				"(err %d)", err);
		}
	}
}

with the changed bt_nus_client_send() in nus_client.c

int bt_nus_client_send(struct bt_nus_client *nus_c, const uint8_t *data,
		       uint16_t len)
{
	int err;

	if (!nus_c->conn) {
		return -ENOTCONN;
	}
    
    // COMMENT THIS OUT IN ORDER TO RUN THIS SEND FUNCTION MULTIPLE TIMES
	// LOG_INF("Trying to set atomic bit for NUS_C_RX_WRITE_PENDING");
	// if (atomic_test_and_set_bit(&nus_c->state, NUS_C_RX_WRITE_PENDING)) {
	// 	return -EALREADY;
	// }
	// LOG_INF("Atomic Bit set for NUS_C_RX_WRITE_PENDING, value: %d", atomic_test_bit(&nus_c->state, NUS_C_RX_WRITE_PENDING));

	nus_c->rx_write_params.func = on_sent;
	nus_c->rx_write_params.handle = nus_c->handles.rx;
	nus_c->rx_write_params.offset = 0;
	nus_c->rx_write_params.data = data;
	nus_c->rx_write_params.length = len;

    // INITIALLY THIS BLOCK IS CALLED
	// err = bt_gatt_write(nus_c->conn, &nus_c->rx_write_params);
	// if (err) {
	// 	atomic_clear_bit(&nus_c->state, NUS_C_RX_WRITE_PENDING);
	// }

    // --> CHANGED THIS TO TEST THROUGHPUT INCREASE
	err = bt_gatt_write_without_response(nus_c->conn, nus_c->handles.rx, data, len, false);


	return err;
}

Simple stuff basically, no delay or sleep or anything. However, in the LOG output I notice that the sending is happening in some kind of time chunks, as you can see here:

[00:00:11.731,994] <dbg> central_uart: main: Sending data block no 1
[00:00:11.732,635] <dbg> central_uart: main: Sending data block no 2
[00:00:11.733,276] <dbg> central_uart: main: Sending data block no 3
[00:00:11.733,947] <dbg> central_uart: main: Sending data block no 4
[00:00:11.984,008] <dbg> central_uart: main: Sending data block no 5
[00:00:11.985,565] <dbg> central_uart: main: Sending data block no 6
[00:00:11.987,213] <dbg> central_uart: main: Sending data block no 7
[00:00:11.987,854] <dbg> central_uart: main: Sending data block no 8
[00:00:12.384,002] <dbg> central_uart: main: Sending data block no 9
[00:00:12.385,559] <dbg> central_uart: main: Sending data block no 10

Between Blocks 4/5 and 8/9, there is again a delay of 250/400ms respectively.

Now I don't really understand why this is happening. Shouldn't bt_gatt_write_without_response() send out the data as fast as possible? What is the cause of the delay here?

RE: NUS Central Write To Peripheral RX Characteristic Very Slow

DB_ECD — Mon, 10 Jun 2024 14:06:35 GMT

Thank you for your reply. However, SystemView crashes immediately every time it is supposed to capture the data. I tried it for some time now, sorry to say that this seems like wasted time to me.

Still, it seems to me that the 800ms delay that I am encountering is way too high to be normal behaviour. Is there no general idea what could be the cause/solution of/for this?

RE: NUS Central Write To Peripheral RX Characteristic Very Slow

Susheel Nuguru — Mon, 10 Jun 2024 13:13:06 GMT

Haven't tried those configurations myself, but you can try SystemView and get a better idea on the context where that ~800ms delay (wait) is happening. After getting the context of that delay, we would have more info to calibrate on reducing that delay. SystemView is free to try on Nordic products, so please give it a try.