Unexpected empty PDU

RE: Unexpected empty PDU

ovrebekk — Fri, 03 May 2024 08:16:44 GMT

Glad I could help Mustafa 🙂

RE: Unexpected empty PDU

Mustafa — Thu, 02 May 2024 15:39:37 GMT

Great! thanks Torbjørn for your time!

RE: Unexpected empty PDU

ovrebekk — Thu, 02 May 2024 10:02:04 GMT

Hi Mustafa

I think what you are seeing here is just the end of the connection event. Typically the SoftDevice controller will reserve around 2ms at the end of each event for post processing etc.

If you try with a longer connection interval (try somewhere around 15-30ms for instance) you might get longer bursts of packets without delay.

Please note that if the link quality is poor, and you drop one of the packets in the sequence, the rest of the connection event will be lost and you won't be able to transmit anything else until the next connection event. So in poor RF conditions a shorter connection interval might be better.

And if high throughput is the overall goal I would recommend combining multiple packets into one, in order to more efficiently use the radio. The ideal situation is to negotiate 251 byte data length and send 244 byte packets (leaving 7 bytes for the ATT and L2CAP headers).

Best regards
Torbjørn

RE: Unexpected empty PDU

Mustafa — Mon, 29 Apr 2024 20:39:13 GMT

Thank Torbjørn for your reply.

Indeed the delay is not the best way to get a very accurate delay but this is only for demonstration purpose. I don't think that those empty PDUs occur bc of this delay, this delay is only in microseconds and I have max connection event extension of 4 ms and a connection interval of 7.5 ms, so theoretically the PDU should be applied only if there is no communication within 4 ms right? but now the empty pdu is transmitted by Master each 150us right after the notify events by the slave and each 8 empty pdu packets a big delay of around 1736us appears. This delay happens consistently (not randomly seems like).

Anyway I implemented your advice by using a timer and semaphore where 16 packets are sent without delay and after that wait 50ms again before sending the next 16 packets without any delay but unfortunately, the problem is still there.

static void connected(struct bt_conn *conn, uint8_t err)
{
	char addr[BT_ADDR_LE_STR_LEN];

	if (err) {
		LOG_ERR("Connection failed (err %u)", err);
		return;
	}

	bt_addr_le_to_str(bt_conn_get_dst(conn), addr, sizeof(addr));
	LOG_INF("Connected %s", addr);

	current_conn = bt_conn_ref(conn);

	dk_set_led_on(CON_STATUS_LED);
	printk("Resuming measure thread.\n");
	k_timer_start(&sensor_timer, K_MSEC(50), K_MSEC(50));
}

static void disconnected(struct bt_conn *conn, uint8_t reason)
{
	char addr[BT_ADDR_LE_STR_LEN];

	bt_addr_le_to_str(bt_conn_get_dst(conn), addr, sizeof(addr));

	LOG_INF("Disconnected: %s (reason %u)", addr, reason);

	if (auth_conn) {
		bt_conn_unref(auth_conn);
		auth_conn = NULL;
	}

	if (current_conn) {
		bt_conn_unref(current_conn);
		current_conn = NULL;
		dk_set_led_off(CON_STATUS_LED);
		k_timer_stop(&sensor_timer);
	}

}
void send_sensor_data(struct k_timer *timer_id) {
	k_sem_give(&sensor_sema);
}

static void measure() {
        for (int i = 0; i < SAMPLES_PER_CYCLE; i++) {
            double sample = sin(theta);
            theta += theta_increment;

            // Scale the sample to fit within the range of 0 to 255
            int scaled_sample = (int)(sample * AMPLITUDE) + AMPLITUDE;

            // Ensure the sample is within the valid range
            if (scaled_sample < 0) 
                scaled_sample = 0;
            else if (scaled_sample > 255)
                scaled_sample = 255;
			for (uint8_t i = 0 ; i < CHUNK_NUMBER ; i++) {
				chunks[i].detial.sensor.data = (uint8_t)scaled_sample;

				if (i == 2) {// check chunk 3 (counting from 0)
					chunks[i].detial.reserved1.data += 1;
				}
				if (bt_nus_send(NULL, &chunks[i].data, sizeof(chunks[i].data))) {
					 LOG_WRN("Failed to send data over BLE connection");
				}
			}

        }
}

static void sensor_simulated_thread_fn(void)
{
	printk("initialize measure thread.\n");
	k_sem_init(&sensor_sema, 0, 1);
	while (true) {
		if (k_sem_take(&sensor_sema, K_FOREVER) == 0) {
			measure();
		}
	}
}

Thanks again for your time!

RE: Unexpected empty PDU

ovrebekk — Mon, 29 Apr 2024 13:01:39 GMT

Hi Mustafa

I don't think adding a delay like this is the best way to achieve a consistent rate, since the delay doesn't take into account the time spent by the bt_nus_send(..) function itself.

Could you try to run a Zephyr timer instead, set (give) a semaphore in the timer callback, and wait for this semaphore (take) in the transmit loop?

Then the timer will run at a consistent 450us, independent of how long the bt_nus_send(..) function might take.

Best regards
Torbjørn