Data rate

[Yano]

Hi,

we are trying to send data (a packet of 54 bytes) at 100Hz but our data is not always transmitting regularly.

Much of the time the TX is perfect but every so often there is a 20ms delay (see picture of trace).

Our code seems to get stuck with the error NRF_ERROR_RESOURCES for about 20ms:

do
{
debug_error_code = ble_nus_data_send(&m_nus, test_buffer, &test_buffer_len, m_conn_handle);
if ((debug_error_code != NRF_ERROR_INVALID_STATE) &&
(debug_error_code != NRF_ERROR_RESOURCES) &&
(debug_error_code != NRF_ERROR_NOT_FOUND))
{
APP_ERROR_CHECK(debug_error_code);
}
} while (debug_error_code == NRF_ERROR_RESOURCES);

The transmission is is triggered by an app timer:

err_code = app_timer_create( &m_ble_send_poll_timer_id,
APP_TIMER_MODE_REPEATED,
ble_send_timeout_handler );

And because the BLE tx timer is 10ms the 20ms delay backs up the transmissions. 

Here are our timing settings:

#define MIN_CONN_INTERVAL MSEC_TO_UNITS(10, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(20, UNIT_1_25_MS)

Our project is based on BLE_uart. 

How can we stop this 20ms delay and get it transmitting regularly?

Thanks

 

[run_ar]

Hi,

My first thought on this is that you are likely loosing some packet every now and then? Maybe you could check with a sniffer to see if there is a failed transmission or acknowledgement in the "failing" connection event? then you should see the packet being re-transmitted in the next connection event 10ms later (which will give a 20ms delay).

[Yano]

We sniffed the communications and we don't think its a radio / packet loss issue.

We have two i2c devices on two separate buses one is on the PCB (IMU) the other (senor) a clip on/off device.

Both these devices are scanned using a timer on interrupt and they work reliably without error.

Both reads are done in the background together at APP_IRQ_PRIORITY_HIGH.

The data from these devices is then transmitted.

If we remove the clip off sensor the code detects an i2c error and breaks out putting all zeros in the place for transmission. 

When we do this the delays are removed and we get a steady stream of data (see scan).

The Tx is done at the same time after the scan.

The only difference are:

1. The i2c read is cut short

2. The sensor portion of the data is all zeros.

Could the SD and/or BLE transmission service be disrupted by two rather than one background TWI events and if so is there a way around this?

Thanks

Ian