Central to peripheral data transfer time

[prodey]

We are developing a BLE device that will act as a central and send data to a peripheral. To begin with, I have used the uart central example code from SDK to set up a central device on PCA10040 and using the uart peripheral code from SDK on our custom board that has BL652. I am using NRF52832 with SDK 15.3.0, softdevice S132.
In the central code, I commented out the uart_init() so that there are no UART events.
I created a timer and am sending a 8-byte packet to the periperal:
void timer_led_event_handler(nrf_timer_event_t event_type, void* p_context)
{
static uint32_t i;
uint8_t dummyData[8] = { 0x52, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58, 0x59 };

nrf_gpio_pin_toggle(24);

send_ble_data(dummyData, sizeof(dummyData));
}

void send_ble_data(uint8_t * p_data, uint16_t length)
{
static uint8_t data_array[BLE_NUS_MAX_DATA_LEN];
memcpy(data_array, p_data, length);
ble_nus_c_string_send(&m_ble_nus_c, data_array, length);
}

On the peripheral side, I am using the nus_data_handler() service to receive the data and modified the function from the uart peripheral example thus:

static void nus_data_handler(ble_nus_evt_t * p_evt)
{

if (p_evt->type == BLE_NUS_EVT_RX_DATA)
{
uint32_t err_code;

NRF_LOG_DEBUG("Received data from BLE NUS. Writing data on UART.");
NRF_LOG_HEXDUMP_DEBUG(p_evt->params.rx_data.p_data, p_evt->params.rx_data.length);

if (p_evt->params.rx_data.p_data[0] == 0x52)
{
nrf_gpio_pin_toggle(24);
}

nrf_drv_spis_buffers_set(&spis_handle, //The SPI part is specific to our application
(uint8_t*)p_evt->params.rx_data.p_data,
p_evt->params.rx_data.length,
m_rx_buf,
m_length);
}
}

All configurations in sdk_config.h are default from the SDK examples for central and peripheral.
When I set the timer in central to 100 ms, if I watch GPIO24 on oscilloscope simultaneously on central and peripheral boards, I can see that there is a delay of ~30 ms between send from central and receive on peripheral. When I reduce the timer interval further to say 10 ms, I can see that the central pin toggles consistently at 10 ms while the peripheral pin toggles erratically, most of the times at 30 ms, indicating data is getting 'missed'.
I read about connection interval and according to Infocenter, "The connection interval defines how often the devices must listen on the radio.". This is set to min 7.5 and max 30 default from the example.
Our product needs the central device to transfer 8 byte data reliably to peripheral at 1 ms interval. How can we achieve this? Does the connection interval parameter set a limit on the max transfer rate?

[ovrebekk]

Hi

The connection interval determines how often you can send packets from the central to the peripheral, or vice versa. 

You can send multiple packets per connection event, but as soon as the buffers are empty and the connection event ends you have to wait for the next connection event before you can send any more data. 

This is the way that a Bluetooth LE connection can reach really low average currents, by keeping the radio disabled as much as possible. 

If you see a delay of ~30ms then this is probably the connection interval the central has selected. If you set min and max connection interval to 7.5ms you should get a shorter connection interval, but you can't go any lower than this unfortunately. 

If you are using Nordic devices in both ends of the link you could implement a proprietary protocol, and send packets at a fixed rate of 1ms, but then you wouldn't be compliant with other BLE devices. 

Best regards
Torbjørn

[prodey]

Hello,

Thanks for the reply and the insight. I will experiment further with the settings of the connection interval.

Can you please elaborate on the last statement "If you are using Nordic devices in both ends of the link you could implement a proprietary protocol, and send packets at a fixed rate of 1ms, but then you wouldn't be compliant with other BLE devices."

As I understand, the fastest data transfer rate between the BLE central and peripheral devices is limited by the connection interval and that can not be less than 7.5 ms in any case. When you say 'proprietary protocol', do you mean an application protocol with a 'wired' connection (like UART/SPI)? Or is there a way to be 'wireless' and still achieve the fixed rate of 1ms between the devices?

[ovrebekk]

Hi

What I mean is that you remove the BLE stack altogether, and use the nRF52 radio in a non standard way. If you access the radio on a register level you have a lot more flexibility than what the BLE stack gives you, but you will no longer be BLE compliant and will need to have Nordic devices on both sides of the link. 

We typically refer to this as proprietary 2.4GHz protocols, and provide some examples in the SDK through the ESB and Gazell implementations. 

These protocols are primarily included to provide backwards compatibility with older Nordic devices (introduced before BLE was even a thing), but can also be used when having very particular protocol requirements. 

Best regards
Torbjørn