nRF Desktop

RE: nRF Desktop

ovrebekk — Mon, 25 Apr 2022 12:23:44 GMT

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

RE: nRF Desktop

William.wei — Fri, 15 Apr 2022 08:05:47 GMT

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.

RE: nRF Desktop

William.wei — Thu, 14 Apr 2022 04:59:03 GMT

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.

RE: nRF Desktop

William.wei — Mon, 11 Apr 2022 07:03:23 GMT

Thanks, Torbjørn.

Regards,

William,

RE: nRF Desktop

ovrebekk — Sat, 09 Apr 2022 07:50:02 GMT

Hi William

I spent some more time with the example yesterday, and got the base functionality implemented. It adds the NUS client and server to the LLPM sample, and sets up the peripheral device to send 20 byte payloads as fast as possible.

The central device will do nothing other than count the incoming bytes, and display the number of received bytes every second. It's probably not the most compelling demo, but at least it demonstrates that 20 bytes every millisecond is possible, and it's possible to build on the example to make the demo a bit more interesting.

The demo needs to be used in a similar fashion to the LLPM sample:

1) Press 'm' on kit 1 to make it the central

2) Press 's' on kit 2 to make it peripheral

3) Press any key on kit 1 to enable 1ms connection interval

4) Press any key on kit 1 to start the test

5) Press any key on kit 2 to start sending dummy packets

Once everything is running you should see the central device reporting a number close to 20000 every second.

Code included below. It includes a local git repository, if you want to check the changes from the original LLPM sample:

devzone.nordicsemi.com/.../286757_5F00_llpm_5F00_20b_5F00_test_5F00_working.zip

Best regards
Torbjørn

RE: nRF Desktop

William.wei — Thu, 07 Apr 2022 08:37:05 GMT

Yes, Torbjørn,

understand. thanks.

RE: nRF Desktop

ovrebekk — Wed, 06 Apr 2022 12:01:34 GMT

Hi William

I started some work trying to integrate the NUS service in the LLPM example, in order to send data updates more easily, but I wasn't able to complete it today.

I will set aside some more time to try and provide an updated example. I can't guarantee that I will be able to complete it before Easter, but I will do my best. I will get you a status update tomorrow or Friday.

Best regards
Torbjørn

RE: nRF Desktop

William.wei — Wed, 06 Apr 2022 06:30:57 GMT

Yes，Torbjørn,

i am not able to achieve that objective for 20B/ms, if it is possible, please help to deliver your demo when you are free.

i have tried for many times and many ways, seems it is really difficult.

Thanks,

WIlliam.

RE: nRF Desktop

Lorenzo Amicucci — Tue, 05 Apr 2022 06:35:22 GMT

Hi Torbjørn,

yes, we tried, and that example is really poor to demonstrate performances (in terms of stability):
https://devzone.nordicsemi.com/f/nordic-q-a/86226/llpm-work-flow

See above ticket.

That is why I was more interested in nRF Desktop, as it is much better example (optimized application)

Thanks

BR
LA

RE: nRF Desktop

ovrebekk — Mon, 04 Apr 2022 14:36:00 GMT

According to the developers it should be possible to send 20 bytes at 1ms intervals.

Have you tried to use the LLPM sample in NCS?
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/bluetooth/llpm/README.html

Unfortunately I am home today with sick child, but I will try to set up a test on my own as soon as I have the time (and equipment needed).

Regards
Torbjørn

RE: nRF Desktop

Lorenzo Amicucci — Fri, 01 Apr 2022 06:28:05 GMT

On top of this: we have also the HID feature report and HID config channel which are used to send data.
- How do they work? are they also limited to 8-10B?
- we show only downlink to the device, but can this be used also uplink? I think so, because our DFU transport protocol using config channel has some ack mechanisml

Thanks

BR
LA

RE: nRF Desktop

Lorenzo Amicucci — Thu, 31 Mar 2022 09:58:39 GMT

Hi Torbjørn,

can you check with the developers of nRF Desktop if there is any way to do it? I know that the nRF desktop application has been optimized to solve the issue mentioned by Kenneth in the other ticket.
Maybe working on buttons_sim.c, and the hid_forward module, maybe we can show 20B?
Once data arrive to dongle, the dongle can push it out as UART instead of HID USB... so no need to respect the HID frame

BR
LA

RE: nRF Desktop

William.wei — Thu, 31 Mar 2022 09:25:26 GMT

i can upload my nus service with llpm feature, and please help us on this.

i set buffer to 6, so first in the callback, i can nus_send for 6 times, but after that.

1.this callback can not return, everything is stopped, there must be something wrong.

2. there is still delay to get the callback, as below:

I guess i am not correct in using llpm.

This demo is based on ncs1.9.1. Press button 1 to start nus notification please. Thanks!

devzone.nordicsemi.com/.../Zmulti_2D00_NUS_2D00_master_5F00_llpm.7z devzone.nordicsemi.com/.../Zperipheral_5F00_uart_5F00_llpm.7z

Regards,

William.

RE: nRF Desktop

William.wei — Thu, 31 Mar 2022 08:39:44 GMT

Yes, Torbjorn,

For those customers transferring voice like voice mouse, and gaming pad, like VR and XR;

my objective is to transfer 20B / ms, not actually using write request, i also tried on notification, but find out that notification callback is still delayed;

Regards,

William.

RE: nRF Desktop

ovrebekk — Thu, 31 Mar 2022 08:19:22 GMT

Hi William

Why do you need to use write request?

If throughput is important then requests are generally not the best option.

Best regards
Torbjørn

RE: nRF Desktop

ovrebekk — Thu, 31 Mar 2022 08:18:08 GMT

What is the use case for this that the customer is interested in?

What are they going to use the 20 bytes for?

RE: nRF Desktop

Lorenzo Amicucci — Thu, 31 Mar 2022 07:38:50 GMT

And so the question is: if LLPM sample is not stable/consistent, and nRF Desktop is not good for showing 20B... how can we demonstrating 20B/ms in simple way?

RE: nRF Desktop

William.wei — Thu, 31 Mar 2022 07:34:37 GMT

hi Torbjorn，

please see my ticket:https://devzone.nordicsemi.com/f/nordic-q-a/86226/llpm-work-flow;

as i tested ncs llpm example, sending 14 bytes data with write request will receive ack from next empty packet, however when i send 15 bytes with write request, it will need extra connection event (+1ms in this case), you can see the sniffer log;

and with this feature, customer may not achieve 20bytes / 1ms datarate for customer user case.

Regards,

William.

RE: nRF Desktop

ovrebekk — Thu, 31 Mar 2022 07:22:29 GMT

Hi Lorenzo

The difference between 1 byte and 20 is not very large on the overall radio time, the main overhead is in starting the radio, getting an ACK and so forth.

For HID the packet length and format is set by the HID descriptor, and the keyboard and mouse descriptors are usually around 8-10 bytes long. In order to change this it is possible to modify the HID descriptor, and add some dummy bytes at the end to make the packet 20 bytes long, but you also need to change the code that sends the HID report to make sure you are actually sending the full 20 bytes.

It won't be a very clear demonstration though. It will look exactly the same to the user, since the additional bytes would just be ignored on the receiving end.

Best regards
Torbjørn