Throughput example

[pal_722]

Hey!
 I am working with 2 nrf5340 boards(nrf5340 Audio-DK as peripheral and nrf534DK as Central) and am trying to send 12750 bytes of data at one second from Audio-DK to DK using the NUS service.

I was going through the Throughput example sample output and it shows, the server was able to send data at 1363kbps.

What were the configuration settings made to achieve this data rate?

What does "[peer] received 1242945 bytes (1213 KB) in 2511 GATT writes at 1415583 bps" mean ? Does it mean 495 bytes of data was sent 2511 times ?

For me to achieve my desirable data rate, ie 102Kbps, what change in settings am I supposed to do? Does increasing UART_BUF_SIZE help me achieve it?


Can you please help me out ?Your response will be of great help.

Regards
Thank you 

[Hung Bui]

Hi Pallavi, 
Have you tried to test with the sample ? 
My suggestion is to take a look at the code to see how it works, pay attention to the test_run() function. 

The data is sent by using GATT write without response. 

I have made a blog here on how to improve throughput , please take a look:  Building a Bluetooth application on nRF Connect SDK - Part 3 Optimizing the connection 

[pal_722]

Hey Hung Bui 

I tested the sample and, also got to know the configuration settings used in the throughput sample.

pal_722 said:

 I am working with 2 nrf5340 boards(nrf5340 Audio-DK as peripheral and nrf534DK as Central) and am trying to send 12750 bytes of data at one second from Audio-DK to DK using the NUS service.

I did some changes to the prj.conf on the peripheral side and observed that I am able to get the required no. of bytes at the central in almost 30 secs. 
What change am I supposed to make to receive the data in 1 second? If not 1 second, what shoul I do to decrease the 30 seconds?

Regards
Thank you

[Hung Bui]

Hi, 

pal_722 said:

I) In  the Sniffer page , it says i need certain boards, which I do not have. Any other way to do that ?

Please get hold of one. It will save you a lot of time debugging. 

pal_722 said:

You said about having this particular file in the sample's boards folder , I have added it, am I supposed to put all the configurations such as ATT_MTU, PHY etc be added to that file?

Sorry, I was wrong, you should look at the prj.conf in \throughput\sysbuild\ipc_radio. (if you are using SDK v2.8 and above) You should copy the same file in the same folders in your project. 

pal_722 said:

In the Throughput sample , the sample output says :
local] sent 1242945 bytes (1213 KB) in 7292 ms at 1363 kbps.
Can you say what 1213KB means? how did 1242945 become 1213KB?

It should be 1214kB. One kilo Byte is equal to 1024 bytes. 

[pal_722]

Hi Hung Bui 

I edited the ipc_radio file in the NUS sample and saw a great change in reception.
Thank you for that!!
I was able to receive almost the same data rate for the first time, BUT the reception is not stable after multiple trials.
After a point the nrf5340 Audio DK board stops blinking (what i mean is everytime the peripheral UART board is connected to a central UART board, in the peripheral board, green and yellow LEDs blink.) 
I am not able to receive any data at the Central side after that.

Can you explain to me why this is happening ?


Regards
Thank you 

[Hung Bui]

Hi Pallavi, 
If you don't provide debug information, it's not possible for me to give you advice just based on "reception is not stable" and the board stop working. 

Please check the log to see any info about the assert. Double check if you may have any issue with the data buffer, memory management. 

[pal_722]

Hi, 

I get "NUS send timeout"  at the central side. And no logs in the peripheral side. 

The peripheral board stops working, and I do not receive any data.

Does peripheral or central wait for a handshake between data transfers?

[Hung Bui]

HI Pallavi, 
I strongly suggest you to go through the academy and study more on how BLE communication work. 
NUS send timeout could be that the connection has been terminated and the command to queue data has been timed out.
Please step into the code and check where the log is printed.