bt_nus_send execution time

[Alexf]

hello,

on our bm833 dev board, I scope (using a PIO) the time it takes for the bt_nus_send function to send 146 BYTES. The PIO goes to 0 after the callback nus_sent_cb has been fired to ensure that the data has actually been transmitted.

What we see on the scope are times of around 450us which are not logical based on the bm833 configuration: primary PHY LE 1M, connection interval range between 12,5ms and 15ms.

We expect a few milliseconds in order for the bt833 to send the original data before it accepts new data to send again.

here's what my 'send over ble' function does:  

int32_t bt_send_data(const void *data, uint16_t len)
{
	nus_sent_cb_done = false;

	volatile int32_t ret;


	ret = bt_nus_send(current_conn, data, len);

	if (ret == -EBUSY) {
		LOG_INF("BLETX%d]: File d’attente pleine", bt_nus_tx_send_ix);
		set_pin_state_connected(0);
		//	remove me
		nrf_gpio_pin_set((uint32_t)PIO_BT_ERROR);
		//error();
		return ret;
    }
	else
	if (ret) 
	{
		LOG_INF("[BLETX%d]: ERROR: %d\n", bt_nus_tx_send_ix, ret);
		set_pin_state_connected(0);
		//	remove me
		nrf_gpio_pin_set((uint32_t)PIO_BT_ERROR);
		//error();
		return ret;

    } else {
		LOG_INF("[BLETX%d]: accepté", bt_nus_tx_send_ix);
    }

	//	wait here to take the semaphore
	//	to considerate packet as fully sent over ble
	ret = k_sem_take(&ble_packet_sent, K_MSEC(1));
	k_sem_reset(&ble_packet_sent);
	if(ret==0)
		LOG_INF("[BLETX%d]: OK", bt_nus_tx_send_ix);
	else
		LOG_INF("[BLETX%d]: NOK", bt_nus_tx_send_ix);


	bt_nus_tx_send_ix++;
	return ret;
}

the semaphore ble_packet_sent is set in the nus_sent_cb cb;

static void nus_sent_cb(struct bt_conn *conn)
{
    /* Ici, le paquet est considéré comme envoyé au niveau ATT */
	nus_sent_cb_done = true;
	k_sem_give(&ble_packet_sent);
}

is there a better callback to use to ensure proper availability of the tx characteristic ?

best regards,

Alex

[Susheel Nuguru]

Hmm, wait a minute, not sure If I am understanding your question or setup correctly.

146 bytes over LE 1 M should not take milliseconds once the event starts. A single notification maps to one LL data PDU that spends around 200µs on the air (1 Mbit/s + preamble/header/CRC). The peripheral immediately receives the ACK in the same connection event, and the controller reports completion to Zephyr callbacks when there is no higher priority thread running, assuming that you have a simple system with not so many high priority threads running,  your callback executes a few hundred microseconds after you queued the packet. The 12.5–15 ms connection interval only determines how often the link layer is allowed to start a radio event; it does not stretch each event to match the interval. That is why your scope sees a ∼450 µs pulse: the link wakes up, bursts the data, and goes back to sleep long before the next interval boundary.

is there a better callback to use to ensure proper availability of the tx characteristic ?

Do not think so. But then, I am not sure if i understood your requirements correctly.

[Alexf]

hello Susheel,

thanks for the answer. I fixed the timeout value in my original code and changed it to 100ms (to be safe). Using 1ms timeout was clearly wrong. What we see now when sending 146bytes is a very steady 6.8ms delay between the execution of the bt_nus_send function and the execution of the 'sent' callback. My zephir system is fairly simple, his only job is to receive data over uart and send them over ble, so not that many threads. Does that 6.8ms time look reasonable to you based on your previous explanation ?

best regards,

Alex

[Susheel Nuguru]

6-7ms seems to make sense with the Math. If you call bt_nus_send() just after an event ended (for example), the PDU waits ~1 interval; on average it waits about half an interval

Try to tighten the interval a bit and request latency of 0 maybe use 2M PHY?