Increasing bluetooth speed without blocking other peripherals

[ryerye120]

Hi,

I'm putting together some firmware that takes packets received over SPI and then streams them over BLE. I'm trying to run the BLE at close to 1Mb/s (which is still within spec from my understanding) but I'm getting some inconsistent packet dropping. After some debugging, I have come to some roadblocks.

1) Is there a way to confirm that I'm properly queueing BLE packets? I've instantiated the queued write module and enabled the length extension with the following code:

NRF_BLE_QWR_DEF(m_qwr);   

...
...

err_code = nrf_ble_qwr_init(&m_qwr, &qwr_init);

...
...

bool conn_evt_len_ext_enabled;
ble_opt_t  opt;

conn_evt_len_ext_enabled = true;

memset(&opt, 0x00, sizeof(opt));
opt.common_opt.conn_evt_ext.enable = conn_evt_len_ext_enabled ? 1 : 0;

err_code = sd_ble_opt_set(BLE_COMMON_OPT_CONN_EVT_EXT, &opt);
APP_ERROR_CHECK(err_code);

and when I want to send bluetooth packets I just use: 

ble_nus_data_send(&m_nus, ble_tx_buf, &ble_packet_length, m_conn_handle);

My understanding is that with my current setup, I can keep running 'ble_nus_data_send' and the microcontroller will just queue whatever I want to send to be sent later. Is that correct? Do I have to wait to receive NRF_SUCCESS?

2) I was reading this blog post: https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/throughput-and-long-range-demo and went through the demo code and it seems like I can increase BLE transfer speeds by boosting my tx power. Is it recommended to change the tx power and link budget or should I not touch those? During run-time I set my PHY to 2M - does that automatically alter my tx power and link budget?

I should note that I'm building my peripheral FW off of the ble_app_uart example and my central FW off a ble_app_uart_c example - but I've added USB functionality. I'm more than happy to provide any/all code if there are any questions.

Thank you so much!

Ryan

[Simonr]

Hi

It seems like you're on the right track. You're using the SPI example for SPI communication I presume, and the ble_app_uart example to see how we get data from a serial device and send that data over BLE? If you're struggling with the buffer being taken by the radio peripheral, hindering the SPI from transmitting data, you can do double buffering. Good discussion on that here.

Trying to transmit more than 251 bytes in one BLE packet would result in an error as that would be outide of the BLE specification. This is very well explained in this Novelbits blog post. It also explains how BLE packets are built up.

Best regards,

Simon

[ryerye120]

Hi Simon,

I built the SPI functions off of the nrfx_spim example, yes! And exactly, right - I used ble_app_uart to get data from a serial device and send that over BLE. Double buffering makes a lot of sense - I'll implement a double buffer scheme.

I read through the novelbits blog post (thanks for the link!) and it mentions sending multiple packets within a single connection interval. That's ultimately what I'm trying to do but I don't know how to do it haha. How can I go about sending multiple packets in a single connection interval? Is there a way to feed a larger packet and have a subfunction break it up? Or do I just need to call ble_nus_data_send() over and over again and trust that it will handle it?

Kindest regards,

Ryan