BLE UART data loss at speed

RE: BLE UART data loss at speed

user2111 — Wed, 01 Jun 2022 11:21:09 GMT

There is a nice tutorial here on how to improve throughput:
https://www.novelbits.io/bluetooth-5-speed-maximum-throughput/

Longer range typically means using coded phy instead of 2Mbps, since coded phy have better sensitivity, but drawback is use 8times longer on-air (=higher risk for interference, higher power consumpion and lower throughput). Using higher output power can also increase range.

You can call ble_nus_data_send() from anywhere below interrupt priorty 4:
https://infocenter.nordicsemi.com/topic/sds_s132/SDS/s1xx/processor_avail_interrupt_latency/exception_mgmt_sd.html

The important is that you call it sufficiently often that it's called between BLE connection intervals. How you implement this is entirely up to you.

Kenneth

RE: BLE UART data loss at speed

user4482 — Mon, 30 May 2022 10:17:09 GMT

Hi Kenneth,

I guess the more data bit is not being set because we only have 120 Kbit/s even at 4ms, thats 6% of the max 2 Mbit/s capacity.

We added a (32 for now) deep buffer and it seems to work at 4ms without error.

Our strategy is to sent the data every 4ms, if we get NRF_ERROR_RESOURCES we wait till we get BLE_GATTS_EVT_HVN_TX_COMPLETE.

Depending on the length of the error/s our buffer will fill up in the background.

So once BLE_GATTS_EVT_HVN_TX_COMPLETE clears we will start sending packets in quick succession (as you suggested) till our buffer is empty.

Only if our buffer is blown will we lose data.

Below is our code (with some debug) our sdk_config.h is attached. Could you sanity check it?

Two questions....

1. How do we set BLE to longer distance/lower speed?

2. Is there a better way to call ble_nus_data_send() rather than a look in main()?

Thanks

void nus_data_send(uint8_t * message, uint16_t length)
{
static uint32_t err_code;
// If the message is too long set it to max
if ( length > BLE_NUS_MAX_DATA_LEN )
{
length = BLE_NUS_MAX_DATA_LEN;
}
b_ready_to_tx = false;
err_code = ble_nus_data_send(&m_nus, (uint8_t *)message, &length, m_conn_handle);

if ( err_code == NRF_ERROR_INVALID_STATE )
{
err_invalid_state_count++;
}
else if ( err_code == NRF_ERROR_RESOURCES )
{
err_resources_count++;
debug_tx [debug_tx_ctr][0] = packet_ctr;
debug_tx [debug_tx_ctr][1] = buffer_read_idx;
debug_tx [debug_tx_ctr][2] = buffer_write_idx;

if( debug_tx_ctr < 1000 )
{
debug_tx_ctr++;
}

while( ! b_ready_to_tx )
{
}
err_code = ble_nus_data_send(&m_nus, (uint8_t *)message, &length, m_conn_handle);
}
else if ( err_code == NRF_ERROR_NOT_FOUND )
{
err_not_found_count++;
}
else
{
APP_ERROR_CHECK(err_code);

}

test-devzone.nordicsemi.com/.../0285.sdk_5F00_config.h

RE: BLE UART data loss at speed

user2111 — Mon, 30 May 2022 09:51:42 GMT

I can see from the log that the More Data bit is not set as frequently as I would expect it to be set, the More Data bit should be set if the peripheral have more data to be sent. If it's not set this indicate to the central that there is no more data to be fetched.

The problem based on this I believe is that you are not calling ble_nus_data_send() as frequently as you should be able to, you can call ble_nus_data_send() several times until NRF_ERROR_RESOURCES, in which case you can wait for BLE_GATTS_EVT_HVN_TX_COMPLETE event (as you do) and then you can call ble_nus_data_send() several times again. Alternatively instead (and possibly the easiest) may just be to call ble_nus_data_send() several times from a 10ms app_timer timeout handler, and call it until NRF_ERROR_RESOURCES, in which case you try again in 10ms. As long as the app_timer timeout handle is shorter than the connection interval that should work well and keep the softdevice buffer full.

If changing the implementation as suggested above doesn't help, can you share your sdk_config.h file?

Edit, you can find these two links useful in general (though I think the biggest problem at the moment is that the More Data bit is not set as expected):
https://developer.apple.com/accessories/Accessory-Design-Guidelines.pdf
https://www.novelbits.io/bluetooth-5-speed-maximum-throughput/

Best regards,
Kenneth

RE: BLE UART data loss at speed

user4482 — Wed, 25 May 2022 20:51:19 GMT

Hi Kenneth,

Below is our updated code.

If the API returns NRF_ERROR_RESOURCES it simply waits for BLE_GATTS_EVT_HVN_TX_COMPLETE in the form of a flag b_ready_to_tx to set and just re-sends the message. The packet data is created in another thread so could be modified by the time it is re-sent, but we will implement a buffer to ensure no data is lost, if needed.

We did tests at 16, 20 and 24ms.

The packet loss seen in each test are as follows:

56 Packets Lost when IMU_READ_RATE = 24ms
1264 Packets Lost when IMU_READ_RATE = 20ms
5204 Packets Lost when IMU_READ_RATE = 16ms

Attached are the wire shark sniffs for each, can you please have a look and let me know what we can do to improve?

Some questions:

1. Can we increase the SD buffer?

2. How can we change the connection interval?

Thanks

BTW for this data here are our connection inteval settings:

#define MIN_CONN_INTERVAL MSEC_TO_UNITS(20, UNIT_1_25_MS) /**< Minimum acceptable connection interval (20 ms), Connection interval uses 1.25 ms units. */

#define MAX_CONN_INTERVAL MSEC_TO_UNITS(75, UNIT_1_25_MS) /**< Maximum acceptable connection interval (75 ms), Connection interval uses 1.25 ms units. */

Are this limited by the iPad?

test-devzone.nordicsemi.com/.../IMU_5F00_READ_5F00_RATE_5F00_20ms.pcapng test-devzone.nordicsemi.com/.../IMU_5F00_READ_5F00_RATE_5F00_24ms.pcapng test-devzone.nordicsemi.com/.../IMU_5F00_READ_5F00_RATE_5F00_16ms.pcapng

void nus_data_send(uint8_t * message, uint16_t length)
{
static uint32_t err_code;
// If the message is too long set it to max
if ( length > BLE_NUS_MAX_DATA_LEN )
{
length = BLE_NUS_MAX_DATA_LEN;
}

b_ready_to_tx = false;
err_code = ble_nus_data_send(&m_nus, (uint8_t *)message, &length, m_conn_handle);

if ( err_code == NRF_ERROR_INVALID_STATE )
{
err_invalid_state_count++;
}
else if ( err_code == NRF_ERROR_RESOURCES )
{
err_resources_count++;

while( ! b_ready_to_tx )
{
}
err_code = ble_nus_data_send(&m_nus, (uint8_t *)message, &length, m_conn_handle);
}
else if ( err_code == NRF_ERROR_NOT_FOUND )
{
err_not_found_count++;
}
else
{
APP_ERROR_CHECK(err_code);
}
}

RE: BLE UART data loss at speed

user2111 — Wed, 25 May 2022 14:10:06 GMT

[quote user="Ian Mellor"]If you send a packet ( call: ble_nus_data_send() ) and it returns NRF_ERROR_RESOURCES does that mean that that packet has been accepted[/quote]

No, that is the whole point of the return error, to tell the application that the packet was not buffered. If you want me to look at your throughput, then please provide an on-air sniffer log (e.g. using nrf sniffer for ble).

Kenneth

RE: BLE UART data loss at speed

user4482 — Wed, 25 May 2022 13:58:52 GMT

Hi Kenneth,

If you send a packet ( call: ble_nus_data_send() ) and it returns NRF_ERROR_RESOURCES does that mean that that packet has been accepted and will be sent. i.e. does it indicate packet accepted send no more?

Can the BLE SD buffer be increased?

If we need our own FIFO buffer is there a library for that (or do we just write our own)?

How do we change the connection interval?

BTW we are sending 232 bytes per packet so it's reasonably efficient.

Thanks

Ian

RE: BLE UART data loss at speed

user2111 — Wed, 25 May 2022 13:44:42 GMT

The NRF_ERROR_RESOURCES simply means that the softdevice buffer is full, and the application should wait for BLE_GATTS_EVT_HVN_TX_COMPLETE event before trying again. So I suggest to change your code a bit, either ignore NRF_ERROR_RESOURCES (which means packet will be lost) or the application need to buffer the packet on NRF_ERROR_RESOURCES event, and try again on BLE_GATTS_EVT_HVN_TX_COMPLETE event. You may also consider changing the connection interval (make it shorter) to allow more throughput in general. I am not sure how large packets you are sending for every notification, but typically combining more data into each notification is a good idea to increase throughput.

Best regards,
Kenneth

RE: BLE UART data loss at speed

user4482 — Tue, 24 May 2022 16:33:53 GMT

Hi Kenneth,

Just to clarify we are not using the UART we just adapted the example code.

Data is simply sent from and received by the application.

Most of the data is sent as a stream of packets from the IMU plus other peripherals (using PPI).

Below is our TX code with some debug error counters.

The only error we are getting is: NRF_ERROR_RESOURCES

At 140 PDUs/s we are loosing about 8 packets per minute.

At 250 PDUs/s we are loosing about 800 packets per minute.

What does NRF_ERROR_RESOURCES mean and what can we do to fix this problem?

Also if we add the (commented out) do - while loop we get re-transmissions of PDUs, why would this be?

Thanks

void nus_data_send(uint8_t * message, uint16_t length)
{
static uint32_t err_code;
// If the message is too long set it to max
if ( length > BLE_NUS_MAX_DATA_LEN )
{
length = BLE_NUS_MAX_DATA_LEN;
}

// do
// {
err_code = ble_nus_data_send(&m_nus, (uint8_t *)message, &length, m_conn_handle);

if ( err_code == NRF_ERROR_INVALID_STATE )
{
err_invalid_state_count++;
}
else if ( err_code == NRF_ERROR_RESOURCES )
{
err_resources_count++;
}
else if ( err_code == NRF_ERROR_NOT_FOUND )
{
err_not_found_count++;
}
else
{
APP_ERROR_CHECK(err_code);
}

// } while (err_code == NRF_ERROR_RESOURCES);

}

RE: BLE UART data loss at speed

user2111 — Tue, 24 May 2022 14:05:27 GMT

Hello,

This is kind of classic development problem, meaning that something works until it doesn't work. So you need to try to narrow it down a bit, data should not be lost or corrupted by itself, so you need to look into whether any of the api call return an error code, and possible also look into adding additional buffers in both transmit and receive to handle the potential "overlap" due the increased throughput between BLE and UART occuring at the same time.

Kenneth