Max interval between BLE data send

[Ian]

Hi,

I use NRF51822 + S130 + SDK12 platform, my device work in CENTRAL mode, I want send data to peripheral every 10ms, code like this:

while (1)
{
   while (m_free_tx_packet_count == 0)
   {
         //wait free send packet
         //m_free_tx_packet_count will increase when BLE_EVT_TX_COMPLETE event received 
      
         if (timeout)
         {
                break;
         }
   }       

   if (m_free_tx_packet_count != 0)   
    {
        if（NRF_SUCCESS == ble_nus_c_string_send(...))  //send some datas
        {
            m_free_tx_packet_count--;
        }
    }
    
    nrf_delay_ms(10);
}

My system is a realtime system, the peripheral need data received at least once every 300 milliseconds, so I measure the max interval of two ble_nus_c_string_send function call, then I found sometimes i must wait free send packet more than 400ms, this will cause my system not work well.

So,is there any way to reduce the time between two BLE data send oprator? Or how can i build a real-time system use BLE?

[endnode]

Hi,

First of all it seems that you've picked wrong technology because BLE isn't real-time, you don't have direct control over timing on Link Layer and of course even if you would it's a radio so there is always a danger of interference, full-spectrum noise or simply weak signal so packets will get lost.

However if you are fine with these limitations and you still want to have "low latency" (I guess that's what you are asking for: have some minimal - or at least controlled and constant - time between two packets reliably transported over the link) then you simply must make connection interval at certain range. If you have control over GAP Central side (Master) then it's much easier because you can choose your interval and GAP Peripheral (Slave) should theoretically accept any of these. It may try to request change later or it may even terminate the connection (because it cannot/doesn't want to operate with such connection parameters) but in most cases it should be OK. So you can go as low as 7.5ms, 10ms is indeed an option as well (basic unit is 1.25ms). Anyway on higher layers (starting from L2CAP and mainly (G)ATT which is normally the main API layer all apps use for data transport) you have very little chance to tight something directly to interval and events happening on Link Layer. You simply must push to the stack whatever you want to transport on the very next possible occasion and then just wait until you get call-back with one of "TX_COMPLETE" events signalling that it passed and you can go on.

If you are not fine with this "prepare for send and wait until it transparently happens on lower layer" model then I'm afraid BLE is not what you are looking for and you should go with some proprietary technology like ESB (but there you need custom radio stack on both sides indeed).

Last remark: for the God's sake never use nrf_delay_xxx function in production application (except some dead-end debugging code) because that's blocking call and you basically kill the MCU for given time! Use proper non-blocking timers based on RTC (like app_timer library) which will just give you callback to the handler once expiring (and you can go on in your main process thread).

[endnode]

Sorry but this doesn't make sense. We all use Nordic Soft Device with similar connection parameters and we are achieving bandwidths of >kbps and latency <50ms even with iPhones. It more indicates bug in your code (or rather misunderstanding of how SD API works?)