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

Stopping the nRF52832 uart sample.

Hi,

If the app keeps sending data at a certain rate, the numbers will skip and the software will stop.

I tried to see how much data I could communicate and at what speed. So, I made it possible to increment and send numbers at regular intervals from my own serial monitor and Android app(Android-nRF-UART).

I experimented in the following way.

  1. The sample "ble_app_uart" of SDKv16.00 was written in nRF52832. 
  2.  I installed "Android-nRF-UART (slightly edited)" on my Android tablet (Android 7.0) using Android studio.
  3. Windows PC via uart and monitor it with a serial monitor of my own making.

First, we tested the communication from the serial monitor to the Android app.(serial monitor -> Android app)

The results were as follows.

loop count interval(ms) result Notes
10 0 failure "ble_app_uart" stopped
10 5 success
100 5 failure "ble_app_uart" stopped
100 10 success
1000 10 failure "ble_app_uart" stopped

Next, we tested the communication from the Android app to the serial monitor.(Android app -> serial monitor)

The results were as follows.

loop count interval(ms) result Notes
10 0 success There's more time lag than a serial monitor.(?)
100 0 failure 40 failures occurred.
100 5 success
1000 5 failure The data does not reach around 250 times.
1000 10 failure

Around 350 times, the data is skipped until about 600 times.

And it doesn't reach the end.

However, it does not stop "ble_app_uart".

The sender has completed the loop to the end.

1000 40 success

10000 40 failure

Around 1350 times, the data is skipped until about 1500 times. 

And it doesn't reach the end.

However, it does not stop "ble_app_uart".

The sender has completed the loop to the end.

Question

  1. What are some possible causes of why apps(ble_app_uart) stop?
  2. What could be the cause of the skipped numbers on the receiving end?
  3. How much throughput is allowed in nRF52832?

Thank you.

Parents
  • Hi,

    1. You may get the "overrun error" (see ERRORSRC) if the UART transfer speed exceeds the transfer speed of your BLE link. The reason for this is that the send loop will become blocking while waiting for the NRF_ERROR_RESOURCES error to clear and thus prevent the UARTE buffer from being read.

    To confirm that this is indeed the problem, try to comment out the code shown below from your UART event handler and see if it still stops:

            /* Handle UARTE communications errors. Comment APP_ERROR_HANDLER() to ignore lost packets */
            case APP_UART_COMMUNICATION_ERROR:
                APP_ERROR_HANDLER(p_event->data.error_communication);
                break;

    This will make the FW ignore any communication errors on the UART interface.

    2. Have you done any customizations to the original ble_app_uart example? Packets will get sent as long as ble_nus_data_send() returns NRF_SUCCESS (ie link will be terminated if not)

    3. Throughput is likely going to be limited by the tablet in this case. Particularly if you are testing with an older Model running Android 7. Throughput numbers with nRF52's on both sides of the link can be found in the Softdevice specification here: Bluetooth Low Energy data throughput

    Note that the UART v.2.0 mobile app has replaced by the UART app in nRF Toolbox. 

  • Hi, Vidar Berg

    Thank you for your quick reply.

    1. Commenting out as you answered did not result in an error. In addition, when I checked "p_event->data.error_communication", I found it to be "1", indicating that it was a buffer overrun.

    2. This was due to the fact that the Android application did not check for sending errors.

    I have one more new question.

    I changed the Android application to "Android nRF Toolbox" and made a few changes to it as a testing tool in the same way.
    When sending data from the serial monitor to the Android application side at high speed, the missing data occurred. As a trial, I made the function immediately after receiving the data to output the received data to the log.

    // UARTService.java for Android-nRF-ToolBox
    public class UARTService extends BleProfileService implements UARTManagerCallbacks {
        ...
        @Override
        public void onDataReceived(@NonNull final BluetoothDevice device, final String data) {
            Log.d(TAG, data);
            ...
        }
        ...
    }

    However, at this point I found it to be missing. This problem did not occur when using "Android-nRF-UART".
    What do you think is the cause?

  • Hi,

    Some missing bytes may be expected as you are ignoring UART communications errors. To narrow down the problem, are you able to get debug logs from the FW app that shows if the data gets successfully sent from the nRF52?

  • Hi, Vidar Berg

    I apologize for the delay in replying.

    Once I created my own test tool using Android-BLE-Library, the missing numbers were gone.
    In addition, in order to speed up throughput, we changed the interrupt processing for receiving UART in ble_app_uart to just adding it to the ring buffer. In doing so, we were able to send 10 packets with a data size of 6~7 bytes with an interval of 1 ms. I can get about 28 kbps at maximum.

    1. Is it possible to make it faster?

    2. In addition, NRF_ERROR_RESOURCES is raised in the bleep_nus_data_send function, which causes a delay in transmission. I think the way to deal with this is to increase ble_cfg.conn_cfg.params.gatts_conn_cfg.hvn_tx_queue_size, but is there any other way?

    3. I have a bug (status=133) that doesn't connect with my own Android test application for the first time, but it always connects with Android-nRF-ToolBox. It doesn't make much difference in connection processing, but is there something special that needs to be done?

  • Hi,

    1. Would it make sense to put more data in each packet rather than having several small packets? That will lower the overhead and increase the throughput significantly. Each notification packet can be 'm_ble_nus_max_data_len' bytes long.

    2. It would allow you to queue more packets without getting the NRF_ERROR_RESOURCES  error, but it won't prevent the error if you send data fast enough. 

    3. This is a generic and common error from Android that can mean a lot of things. It's often related to sudden disconnects. I'd suggest to debug the FW side to see if any error or disconnect events occur.

Reply
  • Hi,

    1. Would it make sense to put more data in each packet rather than having several small packets? That will lower the overhead and increase the throughput significantly. Each notification packet can be 'm_ble_nus_max_data_len' bytes long.

    2. It would allow you to queue more packets without getting the NRF_ERROR_RESOURCES  error, but it won't prevent the error if you send data fast enough. 

    3. This is a generic and common error from Android that can mean a lot of things. It's often related to sudden disconnects. I'd suggest to debug the FW side to see if any error or disconnect events occur.

Children
Related