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

NRF UART Error at Higher Baud Rate

My requirement is to send from Controller Device to NRF Ble Device through UART of 40Bytes at the rate of less than 1ms. Currently I am using ble_app_uart example as a reference.  

According to Nordic forum UART/UARTE Not able to handle data well at higher Baud Rate. The Overrun Error occurs because of the Byte by Byte data receiving mechanism.

Nordic SDK: 17.0.2

So My question as follows:

1. By using UART/UARTE Can i achieve 921600 or higher baud rate.  

2. If not why? Please send me a reason.

3. If Yes. Please send me a reference.

By Referring the Nordic Forum i get to know by using libuarte-advanced UARTE driver I can achieve higher baud rate. Is this Correct.

So My question as follows:

1. Is 921600 baud rate achievable.

2.  Please send me a Integration Guide with BLE Peripheral Examples(eg,. ble_app_uart).

 3. If there send me a ble peripheral example with libuarte for my refernce.

Parents
  • Hi Susheel,

    First thanks for immediate response.

    UART Configuration:

    app_uart_comm_params_t const comm_params =
    {
    .rx_pin_no = RX_PIN_NUMBER,
    .tx_pin_no = TX_PIN_NUMBER,
    .rts_pin_no = RTS_PIN_NUMBER,
    .cts_pin_no = CTS_PIN_NUMBER,
    .flow_control = APP_UART_FLOW_CONTROL_ENABLED,
    .use_parity = false,
    .baud_rate = NRF_UART_BAUDRATE_921600 //NRF_UART_BAUDRATE_115200
    };

    FiFO Priority: APP_IRQ_PRIORITY_LOWEST

    My Application Used Softdevice to transfer the received data to Windows Application.

    Our Main Intention is to receive the data from Controller through UART to BLE and update to Windows APP using Services.

    This process need to done in less than 1ms. At every 1ms i am sending data from Controller and Update to APP continuously. 

    At 115200 Works good on thing is for 40bytes transfer uart consumes around 3-4ms.

    At 921600 we can transmit 40bytes within 200-400us.

    But Our Application is based on real time. We have to transmit data from controller to BLE in less than 1 milli sec.

    By using app_uart FIFO Mechanism it is not possible. As i mention earlier UART overflow occurs or data loss. As i seen this while testing.

    But By go through Nordic Forum i get to know UART higher speed we can achieve using libuarte. Because it gives Chunk of data instead of byte by byte. 

    I think implementing (libuarte)  in our application we can achieve Higher Speed.

    If  by using app_uart FIFO mechanism if we can achieve Higher Speed it will be good to go. Please Specify if there are any settings.

    Because i am facing a problem integrating or merge "libuarte" with "ble_app_uart". As i tested libuarte standalone with our controller it look works fine based on our requirement. 

    Our Application Main Intension is to achieve UART High Speed. 

    I would appreciate any suggestions to achieve fast result.

    Thanks,

    Pavan

  • Pavan Kote said:
    This process need to done in less than 1ms. At every 1ms i am sending data from Controller and Update to APP continuously. 

    The minimum connection interval you can achieve on BLE is 7.5ms on a connection. So when you say that you are sending UART data from a controller through UART, i am assuming that you are assembling the data received into one packet before sending the data on the BLE connection?

    .  

    Pavan Kote said:
    By using app_uart FIFO Mechanism it is not possible. As i mention earlier UART overflow occurs or data loss. As i seen this while testing.

     Your BLE throughput depends a lot on 

    1. connection interval
    2. MTU size
    3. and your application pre and post-processing latencies of each packet. If you do a lot of pre and post processing of each packet you receive, you would eventually make the buffers full (since your application takes more time to process each packet) making the BLE controller to wait until application pulls data and frees the buffer.

    I do not think we have done any benchmarks on which library (app_fifo or libuarte) has less latency per transaction transfer. app_fifo might add more latency as it uses an addition fifo library to operate on the buffer.

    In the end, i think your throughput goals are a bit ambitious, if you really want to attain them you need to do a lot of architectural considerations on how you can minimize per uart transaction latencies. You need to decide if maybe using NRFX_UART driver directly instead of using a library makes it better in terms of reducing pre and post processing of  uart transaction..

Reply
  • Pavan Kote said:
    This process need to done in less than 1ms. At every 1ms i am sending data from Controller and Update to APP continuously. 

    The minimum connection interval you can achieve on BLE is 7.5ms on a connection. So when you say that you are sending UART data from a controller through UART, i am assuming that you are assembling the data received into one packet before sending the data on the BLE connection?

    .  

    Pavan Kote said:
    By using app_uart FIFO Mechanism it is not possible. As i mention earlier UART overflow occurs or data loss. As i seen this while testing.

     Your BLE throughput depends a lot on 

    1. connection interval
    2. MTU size
    3. and your application pre and post-processing latencies of each packet. If you do a lot of pre and post processing of each packet you receive, you would eventually make the buffers full (since your application takes more time to process each packet) making the BLE controller to wait until application pulls data and frees the buffer.

    I do not think we have done any benchmarks on which library (app_fifo or libuarte) has less latency per transaction transfer. app_fifo might add more latency as it uses an addition fifo library to operate on the buffer.

    In the end, i think your throughput goals are a bit ambitious, if you really want to attain them you need to do a lot of architectural considerations on how you can minimize per uart transaction latencies. You need to decide if maybe using NRFX_UART driver directly instead of using a library makes it better in terms of reducing pre and post processing of  uart transaction..

Children
Related