Stopping the nRF52832 uart sample.

[mamorudeta]

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.

[Vidar Berg]

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:

pca10040_throughput_fix.zip

[mamorudeta]

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?

[Vidar Berg]

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).

[mamorudeta]

Hi, Vidar Berg

Thank you for your quick reply.

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