This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

send packets continuously in ble_app_uart example

I have to send packages continuously; How can I get feedback on the success of transmission before sending the next package? Which event should I use? and in what callback function?

I'm using SDK 15 and softdevice 6.0. The event BLE_EVT_TX_COMPLETE is missing in ble.h

Thanks

  • Hello, I changed the function void SendData(void) as follows:

    void SendData(void)
    {
    
        static uint8_t data_array[BLE_NUS_MAX_DATA_LEN];
        static uint8_t index = 0;
        uint32_t       err_code;
        uint16_t length;
    
        for (index=0; index<18; index++)
        {
          data_array[index] =  (unsigned char)tempo_IC1;//index+1;
        }
    
        length = 18;
    
        err_code = ble_nus_data_send(&m_nus, data_array, &length, m_conn_handle);
        
    
        if ((err_code != NRF_ERROR_RESOURCES)&&(err_code != NRF_ERROR_INVALID_STATE) && (err_code != NRF_ERROR_BUSY) && (err_code != NRF_ERROR_NOT_FOUND))// (or anything else you want to filter out...)
        {
            APP_ERROR_CHECK(err_code);
        }
    
    }
    

    and now I have not the NRF_ERROR_RESOURCES. Pratically I send a packet of 18 bytes only if I sure that is set the flag BLE_GATTS_EVT_HVN_TX_COMPLETE. However I have the same timing transmission on the oscilloscope. That is the transmission of 7 packets of 18 bytes every connection interval that I set to 15 ms. This behaviour "freezes" the app on IOS ( I use IOS 11.4). How I can send one packet of 18 bytes every connection interva continuously?

    best regards

    Mario

  • Oh, so you want to lower the transmission rate, is that correct?

     

    Unfortunately, you can't read out how many packets you have queued up, but there are some viable workarounds if you want to only send one packet per connection interval:

     

    1: Not the best solution, but maybe the easiest. You can use a timer, and send a packet in the timeout handler. This may not be synced up with the connection interval, but if that is ok for your application, that is fine.

     

    2: You can keep track of the number of packets that you have queued. That is, every time ble_nus_data_send, increment the counter, and everytime you get the tx complete event, decrement the counter. And then you only queue a packet when the counter is 0. This is basically what you did with the flag_transmitted implementation.

     

    3: If you want to queue a packet every connection interval, this might be the most reliable solution. You can enable the radio notification. Please see this guide.  That way you can get an interrupt on a given time before the connection interval event. In that interrupt you can queue one packet. 

     

    I am a bit confused. The description from Einar is suited if you want to queue several packets, which is the correct way of doing it. But do you want to only queue one packet at the time? Do you want to increase the throughput? If the phone freezes it's probably because the app can't handle the incoming packets fast enough.

     

    Best regards,

    Edvin

  • If the flag is only set to 1 in the tx complete event, but the app still queues several packets, there is probably something wrong in the way that the flag is read. Where did you define the flag, and what type is it?

     

    Can you try to decrare it as:

    volatile uint8_t transmission_flag = 0;

    and see if that helps? Volatile should tell the compiler that this variable may be changed outside the current application. If not, the compiler may assume that transmission_flag is not changed, since it didn't change it itself.

     

    BR,

    Edvin

  • Hello,

    Even I'm a bit confused.
    I believed that only in BLE 5.0 I can send more packets in a connection interval. It's true?
    With our current device that is CSR1010, with iOS we always have one packet per connection interval. While using the Nordic with a connection interval set at 15 ms we have the following behaviors:

    1) iOS 9.0.1 -> 6 contiguous packets every 30 ms (with the freeze of app);
    2) iOS 11.4 -> 7 contiguous packets every 15 ms (with the freeze of app);
    3) Android 6.0.1 -> 1 packet every 15 ms (which is what I expected from configuration) (with no freeze of app).

    The iOS / Android devices used are all BLE <5.0.

    Please, could you clarify?

    Best regards,

    Mario

  • Good morning,

    I declared the flag as volatile, but the behaviour is the same. I have more information for you:

    If I send only 1000 packets witn the same code the app on iOS does not freeze, but If I disconnect the Nordic and I connect again I have the following error in the function "app_error_weak.c" of chip:

    app: ERROR 13313 [Unknown error code]

    Please see the following screenshot; the line number is always "APP_ERROR_CHECK(err_code);" in SendData(void).

    Best regards

    Mario

Related