Stopping the nRF52832 uart sample.

RE: Stopping the nRF52832 uart sample.

mamorudeta — Wed, 17 Jun 2020 09:13:43 GMT

Hi, Vidar Berg

Thank you for your quick reply.

I understand.
It was really helpful. Thank you for your long term relationship with us.

RE: Stopping the nRF52832 uart sample.

Vidar Berg — Wed, 17 Jun 2020 08:24:23 GMT

Hi,

This means that the BT chipset on your phone does not support longer data packets (ie the 244 byte payload will be split into multiple 27-byte radio packets on-air).

RE: Stopping the nRF52832 uart sample.

mamorudeta — Wed, 17 Jun 2020 03:50:38 GMT

Hi, Vidar Berg

Thank you for your quick reply.

I tried it with the attached settings. In my environment, it was about 80~100 kbps. Overall, it's now up to 72 kbps, which is much faster than before.
Let me just ask one last question.
The following log is output when bonding with Android 7.0.

<debug> nrf_ble_gatt: ATT MTU updated to 247 bytes on connection 0x0 (response).
<info> app: Data len is set to 0xF4(244)
<debug> app: ATT MTU exchange completed. central 0xF7 peripheral 0xF7
<debug> nrf_ble_gatt: Data length updated to 27 on connection 0x0.
<debug> nrf_ble_gatt: max_rx_octets: 27
<debug> nrf_ble_gatt: max_tx_octets: 27

max_tx_octets(and max_rx_octets?) is going to be 247, why is it 27?

And where can I change this setting?

RE: Stopping the nRF52832 uart sample.

Vidar Berg — Mon, 15 Jun 2020 09:25:48 GMT

Hi,

Sorry, I looked over the project again and see that I had configured NRF_SDH_BLE_GAP_DATA_LENGTH to 27 instead of 251. I had also kept the default NRF_SDH_BLE_GAP_EVENT_LENGTH setting. Both of these will have a significant impact on the transfer speed given that the phone you are connected to support the same configuration.

Please try the attached configuration and see if you can get closer to the numbers listed in the Softdevice specification.

New configuration tested with Google Pixel 2 running Android 10:

Attachment:

devzone.nordicsemi.com/.../pca10040_5F00_throughput_5F00_fix.zip

RE: Stopping the nRF52832 uart sample.

mamorudeta — Mon, 15 Jun 2020 08:06:00 GMT

Hi, Vidar Berg

Thank you for your quick reply.

I tried it with the file you attached (I only had Android).
The result was about 26~30 kbps. Android-nRF-UART, Android-nRF-ToolBox, and my own application all had similar results.

RE: Stopping the nRF52832 uart sample.

Vidar Berg — Fri, 05 Jun 2020 09:39:59 GMT

Hi, I see. Could you try the modified example attached below and see if it gives you better results? I got around 66 kbps with my iPhone 8. The transfer speed is printed out on RTT.

devzone.nordicsemi.com/.../ble_5F00_app_5F00_uart.zip

RE: Stopping the nRF52832 uart sample.

mamorudeta — Thu, 04 Jun 2020 09:00:41 GMT

Hi, Vidar Berg

Thank you for your quick reply.

I'm sorry for the confusion. We've already tried to send it in 247 bytes. As a result, it's only slightly faster.

RE: Stopping the nRF52832 uart sample.

Vidar Berg — Thu, 04 Jun 2020 08:47:16 GMT

Hi,

[quote userid="90456" url="~/f/nordic-q-a/61560/stopping-the-nrf52832-uart-sample/253189"]"m_ble_nus_max_data_len" was already set to a maximum value of 247.[/quote]

That means you could have sent the data in one 70 byte package instead of 10 7-byte packets.

1. Shorter connection intervals should be requested by the peripheral which you can do by adjusting the MIN_CONN_INTERVAL and MAX_CONN_INTERVAL settings in main.c.

For selecting connection parameters I'd suggest you follow the recommendations given in the Apple accessory design guidelines, section 35.6 (link). Phones will generally accept the connection param update requests if you follow these.

2. I'm not sure, unfortunately.

3. The throughput is limited because you are splitting the data into multiple smaller notifications packets.

RE: Stopping the nRF52832 uart sample.

mamorudeta — Thu, 04 Jun 2020 08:05:06 GMT

Hi, Vidar Berg

Thank you for your reply.

"m_ble_nus_max_data_len" was already set to a maximum value of 247.

Is there any way to shorten the connection interval for Android apps?
Do you know how to turn off "D/BluetoothGatt: onNotify()~" in Android app's log when receiving data?
Is there any other way to improve the speed on the android app side?

RE: Stopping the nRF52832 uart sample.

Vidar Berg — Wed, 03 Jun 2020 10:01:22 GMT

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.

RE: Stopping the nRF52832 uart sample.

mamorudeta — Wed, 03 Jun 2020 08:41:24 GMT

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?

RE: Stopping the nRF52832 uart sample.

Vidar Berg — Tue, 26 May 2020 06:28:35 GMT

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?

RE: Stopping the nRF52832 uart sample.

mamorudeta — Fri, 22 May 2020 09:41:48 GMT

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?

RE: Stopping the nRF52832 uart sample.

Vidar Berg — Tue, 19 May 2020 09:56:06 GMT

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.