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

The Queued Writes application in the SDK should give a good example on how to use the queued writes module. You will indeed have to set the NRF_BLE_QWR_MAX_ATTR define to 1 or more, depending on how many attribute handles you want to be able to register. As stated, if this is zero, all queued write requests will be rejected by the Queued Write module.

Best regards,

Simon

[ryerye120]

Hi Simon,

Thank you for the pointer! A previous post had pointed me to the ble_app_uart example but it seems like it might not actually use the queued writes module. 

Unfortunately, I may be barking up the wrong tree here - I was reading this post and they mention:

that queued writes only make sense if you want to synchronize 
writes to multiple characteristics, so that the change take 
effect simultaneously.

That's not actually what I want to do. I really just want to send a large amount of data at a fast rate without breaking my SPI. Furthermore, from looking through everything it seems that the central device is the one that actually uses the "queued writes" and peripheral devices just receive them (or am I wrong there?).

Looking back I should have stated this in the original post: my problem is that my peripheral device needs to perform SPI transactions every 500us and I need to send all this SPI data over BLE without halting the SPI operations. I know for a fact people have done this sort of thing before, but it seems I'm terrible at googling it because I only ever get my forum posts hahaha.

Is there a way to run the BLE in parallel with SPI? If so, does it involve using the SPI interrupt and CPU bound BLE_transfers? 

Do you know what would happen if I gave the (ble_nus_data_send) a packet that was larger than 256 bytes? Does the bluetooth peripheral automatically break it into the correct number of packets?

Thank you so much, Simon! I can't tell you how much I appreciate all of your help and this sort of support from Nordic.

Kindest regards,

Ryan