RE: Data Loss With Nordic Uart Service

Vidar Berg — Fri, 08 Mar 2024 13:15:55 GMT

Hello,

The BLE link is considered reliable. That is, if a packet fails to reach the receiver after a specified number of retransmissions, the link will be considered lost, and a disconnect event will be triggered. Therefore, it is much more likely that data loss is occurring somewhere in the UART data handling before the data is passed to your sender thread.

[quote user=""]Are there known data loss issues with the peripheral UART driver?[/quote]

Please try to enable UART byte counting in HW for both projects by adding CONFIG_UART_0_NRF_HW_ASYNC=y and CONFIG_UART_0_NRF_HW_ASYNC_TIMER=1 to your prj.conf files.(https://github.com/nrfconnect/sdk-zephyr/blob/26fd55e0a750305fbd5d9db750225d7e707458ae/drivers/serial/Kconfig.nrfx_uart_instance#L45)

[quote user=""]Do I need to increase buffers somewhere else in order to send 250 byte data; presumably I should to increase the MTU, please provide a link on how to do that.[/quote]

To support longer att MTUs, you can add these kconfig symbols to your prj.conf file (copied from throughput sample):

CONFIG_BT_BUF_ACL_TX_SIZE=502

CONFIG_BT_BUF_ACL_RX_SIZE=502

CONFIG_BT_L2CAP_TX_MTU=498

Effective data payload is att MTU - 3. You can add the following code to your project to get a callback after the MTU has been negotiated:

void att_mtu_updated(struct bt_conn *conn, uint16_t tx, uint16_t rx)
{
	LOG_INF("MTU Updated: tx %d, rx %d", tx, rx);
}

static struct bt_gatt_cb gatt_cb = {
	.att_mtu_updated = att_mtu_updated,
};

int main(void)
{
    ...
    err = bt_enable(NULL);
	if (err) {
		LOG_INF("Bluetooth init failed (err %d)", err);
		return 0;
	}
	
	/* Register att MTU updated callback. Must be done after bt_enable() */
	bt_gatt_cb_register(&gatt_cb);
    ...

Alternatively, you can check the att MTU size during the connection using bt_gatt_get_mtu():

uint16_t max_pkt_len = bt_gatt_get_mtu(current_conn) - 3;

In addition, you may add CONFIG_BT_CTLR_DATA_LENGTH_MAX=251 if you want to support longer radio packet lengths (is 27 by default).

[quote user=""]Should I switch to indications? If I use indications I understand I cannot send more data until I get the peer acknowledgement. But what happens if that acknowledgment never comes? Should I resend after a timeout?[/quote]

Notifications are still acknowledged by the receiver, but by the link layer and not by the application. The Bluetooth stack will not send the next notification packet until a previous notification has been received.

Best regards,

Vidar

EDIT: The application should also request the HFXO oscillator when the UART is enabled to ensure a stable clock source for the baud rate generator. Otherwise, the baud rate generator will run off the less accurate internal RC oscillator (HFINT).

The HFXO can be requested with this code snippet:

https://github.com/nrfconnect/sdk-nrf/blob/5e0199b154f9e457d5ec091734c517916f0be9b5/samples/peripheral/radio_test/src/main.c#L11