This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BLE Connectivity Issue with Windows and MacOS for high speed application

Hi,

I am trying to develop a high speed application using the nRF51822 chipset. As part of my application, I need to send at least 125 HID IN reports (each 20 bytes long) to the central device. The BLE parameters on my peripheral device ( nRF51822) are as follows:

MIN_CONN_INTERVAL = 7.5 ms

MAX_CONN_INTERVAL = 15 ms

SLAVE_LATENCY = 20

I am sending custom HID IN reports using an infinite loop in the main function as follows:

for (;;)
  {              
    app_sched_execute();
    power_manage();
    
    mouse_movement_send(2000,2000);
    nrf_delay_ms(<delay_in_ms>);
    
  }

I am using the nrf_delay_ms() function to vary the delay (i.e, the number of HID IN reports per second).

On Windows 10, I am able to receive data reliably upto a delay of 50 ms (approx 20 reports a second). For a delay lesser than 50 ms, the BLE connection seems to drop at times or it shows CONNECTED on my PC but the ble_hids_inp_rep_send()  returns an error code of NRF_ERROR_INVALID_STATE . The net effect is that I am unable to receive even a single HID report on the PC.

However, with MacOS, I am able to reliably receive data upto 15ms delay ( approx 65 reports a second) after which the connection becomes unstable and it stops entirely at a delay of about 10 ms( approx 100 reports a second). 

Below is the code on my PC which I use to read input reports (using HIDAPI library):

hid_device *handle = NULL;
handle = hid_open(VENDOR_ID, PRODUCT_ID, 0, usage, 0);
int ret;
cout << "Reading data from HID device..\n";
    do
    {
        ret = hid_read(handle, read_buf, report_length);
        cout << "Reading data from HID device.. ret: "<<ret<<" \n";
    }while(ret == 0);

Could anyone explain the reason of such behavior? And how can I achieve higher speeds on both the platforms ?

Regards

Mustafa

Parents
  • Hi,

    It looks like the bottleneck is on the PC side, as you get a higher throughput on MacOS than on Windows. (If on the nRF side I would expect the throughput to be the same.)

    From the nRF side, since this is 20 byte long notifications, there should be no problem sending one report per connection interval. (Provided that the computation needed for each report is small enough that the application is not cpu bound. Which it probably is not.)

    What are the actual connection intervals that you get, on MacOS and on Windows?

    I am afraid it is limited how much we can help with regards to the PC side and the HIDAPI library. I am sure there are web resources, forums, chat channels, etc., where you can get more information and/or ask questions about throughput and behavior for the HIDAPI?

    Regards,
    Terje

Reply
  • Hi,

    It looks like the bottleneck is on the PC side, as you get a higher throughput on MacOS than on Windows. (If on the nRF side I would expect the throughput to be the same.)

    From the nRF side, since this is 20 byte long notifications, there should be no problem sending one report per connection interval. (Provided that the computation needed for each report is small enough that the application is not cpu bound. Which it probably is not.)

    What are the actual connection intervals that you get, on MacOS and on Windows?

    I am afraid it is limited how much we can help with regards to the PC side and the HIDAPI library. I am sure there are web resources, forums, chat channels, etc., where you can get more information and/or ask questions about throughput and behavior for the HIDAPI?

    Regards,
    Terje

Children
No Data
Related