nRF Desktop

[William.wei]

Hi, 

we would like to use nRF Desktop to test throughput and show we can send 20B per ms (from peripheral to central). 

The LLPM sample is not well optimized, while nRF Desktop is good application, hence we would like to do in nRF Desktop (assuming 1x nRF52840DK for gaming mouse, and one for dongle).

In the code, there is an option to spin automatically mouse cursor in circle, or for the simulated keyboard on the DK, we can send "nordic" continously... but how could we make sure that we send always 20Bytes? Is there way to modify the data sent, so that we can send randomly always 20bytes (it can still be HID data, but it must be 20bytes). 

Any suggestion?

thanks

[William.wei]

Thanks, Torbjørn. 

Regards,

William,

[William.wei]

Thanks Torbjørn,

Your demo works fine.

and my problem for llpm data rate is for below three reasons:

1. i need to stop scan from central side after connection, 

2. i need to delete Qos function on both sides

3. i need to delete uart_init api -------this does't make any sense for me;

the rest result is ,

if uart_init is open, data rate is about 14600B/S;

if uart_init is deleted, data rate is about 19600B/S;

so, without uart function the throughput is fine for me;

I could't not find out the reason, any clue on this problem?

and it is this code that blocks llpm function

uart_rx_enable(uart, rx->data, sizeof(rx->data), 50);

Regards,

William.

[William.wei]

hi Torbjørn，

1. uart_rx must be continuously enter isr interrupt i believe.

    so change uar_rx timeout to 50000, the llpm can work normally. please see below.

    uart_rx_enable(uart, rx->data, sizeof(rx->data), 50000);

    however, i  have not see how timeout works.

2.  and one more question about llpm is :

    CONFIG_BT_CONN_TX_MAX will help to buffer notification data?

Regards,

William.

[ovrebekk]

Hi William

Sorry for the slow response, I just got back from vacation. 

It is possible that the reduced throughput when enabling uart is that you are running the Bluetooth communication and the UART handling from the same thread. 

The BLE notification functions are blocking, which means they block the sender thread while the communication is ongoing, and if something else in that thread is delaying the BLE calls it will reduce the throughput. 

Running the BLE and UART handling on different threads should solve this issue.

Best regards
Torbjørn