Increasing bluetooth speed without blocking other peripherals

RE: Increasing bluetooth speed without blocking other peripherals

ryerye120 — Fri, 06 May 2022 21:04:50 GMT

Hi Simon,

In the end, I think I've figured it all out, let me summarize my issue and solution below for any other people who may come to this thread:

My main problem was that my bluetooth transfers were blocking my spi transfers from happening as often as I wanted to. This was because my bluetooth transfers were occurring in the spi_interrupt_handler with the following code:

while(ble_nus_data_send(&m_nus, ble_tx_buf, &ble_packet_length, m_conn_handle) != NRF_SUCCESS);

So I removed the while loop but then I ran into the problem that ble_nus_data_send() wouldn't actually complete properly by the next spi transaction (meaning only 1/5 calls to ble_nus_data_send() were actually successful).

In order to solve this I had to make 4 changes:

1) enable data length extension (so that multiple packets could be sent during a single connection)
2) Increase my HVN queue size to 400 (so that the notification system would queue any notifications that couldn't be sent in time - this gives me a little leeway in case there are any flukes)
3) Adjusting my ble stack settings to achieve a theoretical throughput of 1.2 Mbps (I figured these out by testing different parameters in the ble_app_mtu_throughput example)
4) I began double buffering and adding a check in the CPU to retry sending the packet if ble_nus_data_send doesn't return success.

Furthermore, to answer my earlier question - In order to send multiple packets during a single connection, all you need to do is call ble_nus_data_send() multiple times. If you have an HVN queue large enough, all of your packets will get queued and sent without you having to worry.

RE: Increasing bluetooth speed without blocking other peripherals

Simonr — Mon, 02 May 2022 13:10:46 GMT

Hi Ryan

The sample project that is used in the novelbits blog post is the ble_app_mtu_throughput example that lets you transmit longer packets (up to 247 bytes in a packet).

Best regards,

Simon

RE: Increasing bluetooth speed without blocking other peripherals

ryerye120 — Fri, 29 Apr 2022 21:37:33 GMT

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

RE: Increasing bluetooth speed without blocking other peripherals

Simonr — Fri, 29 Apr 2022 10:56:33 GMT

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

RE: Increasing bluetooth speed without blocking other peripherals

ryerye120 — Thu, 28 Apr 2022 16:45:05 GMT

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

RE: Increasing bluetooth speed without blocking other peripherals

Simonr — Thu, 28 Apr 2022 07:46:56 GMT

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

RE: Increasing bluetooth speed without blocking other peripherals

ryerye120 — Wed, 27 Apr 2022 15:50:25 GMT

Hi Simon!

1) Right now it looks like it's happening on the Bluetooth side. I probed the spi pins and the data looks good and is being transmitted at the right rate. As far as waiting for the "success" response I ran into a weird issue.

I figured things would run fastest if I put everything in the interrupt handlers so I have a timer_interrupt trigger a SPI transaction and then a SPI_interrupt handler that triggers a bluetooth transaction. My original code (where I wait for NRF_SUCCESS) is below:

void spim_event_handler(nrfx_spim_evt_t const * p_event,
                       void *                  p_context)
{
    spi_xfer_done = true;
    // Bring CS high
    nrf_gpio_pin_set(NRFX_SPIM_SS_PIN);
    
    // send 3 packets at once to take advantage of the large payload size
    if (spi_trx_counter == 3)
    {
        //NRF_LOG_INFO("READ 3 SPI PACKETS, SEND to BLE");
        spi_trx_counter = 0;
        while(ble_nus_data_send(&m_nus, ble_tx_buf, &ble_packet_length, m_conn_handle) != NRF_SUCCESS);
    }
}

This became problematic because waiting with "while(ble_nus_data_send(&m_nus, ble_tx_buf, &ble_packet_length, m_conn_handle) != NRF_SUCCESS);" in the interrupt handler prevented the SPI from operating 'while' the bluetooth was running. I confirmed this by probing my SPI pins with an oscilloscope - I'd get 3 SPI packets (all spaced <1ms apart) and then there would be a 6-7ms gap (what I assume is the connection interval) while the code hit the bluetooth transfer. In other words, the BLE was blocking the SPI

Removing the "while" fixed this blocking problem. SPI transactions are happening at the proper rate now - but I worry I'm not queueing packets properly (which is why I'm getting some dropped packets). Do you know if how the queueing is handled in the backend? Or is this something I have to implement myself? If so, does that mean I 'have' to move the BLE transfers to my main loop?

Edit: I took another look at my sdk_config and I saw the following block:

// <e> NRF_BLE_QWR_ENABLED - nrf_ble_qwr - Queued writes support module (prepare/execute write)
//==========================================================
#ifndef NRF_BLE_QWR_ENABLED
#define NRF_BLE_QWR_ENABLED 1
#endif
// <o> NRF_BLE_QWR_MAX_ATTR - Maximum number of attribute handles that can be registered. This number must be adjusted according to the number of attributes for which Queued Writes will be enabled. If it is zero, the module will reject all Queued Write requests. 
#ifndef NRF_BLE_QWR_MAX_ATTR
#define NRF_BLE_QWR_MAX_ATTR 0
#endif

I probably need to make NRF_BLE_QWR_MAX_ATTR at least 1 for the NUS notifications. Don't I? I also don't see anything in my sdk config for length extension. Do you know if I have to enable this in my SDK_config?

2) Ahh that makes alot of sense. So playing with tx power and link budget won't really help me with this blocking problem that I'm dealing with. At least that's cleared up!

Thanks so much for your help, Simon. I really appreciate it!

Kindest regards,

Ryan

RE: Increasing bluetooth speed without blocking other peripherals

Simonr — Wed, 27 Apr 2022 13:07:53 GMT

Hi Ryan

1. Have you been able to track down where exactly the packets are dropped? Does it occur from the SPI to the transmitting device, or is the data lost over the air? I think you should wait for the ble_nus_data_send() to be completed before you call it again.

2. It only helps to increase the TX power if you're having trouble with the connection in terms of range, higher TX power won't help much if the devices are right next to each other. The 2MBPS PHY does not alter the TX power.

Best regards,

Simon