Increasing number of bytes in HID descriptor

[bscdb]

Hi,

I'm working on hid keyboard example. How can I check whether multiple bytes are received & transmitted after I increase the assigned no. of bytes in input/output report? From the code I understood that nrf device can send 64 bytes to host device. So how do I append bytes in one packet of 64 bytes when sending to host? How does it work from host side? Does nrf read 1 byte at a time sent from host?

[Hakon]

So how do I append bytes in one packet of 64 bytes when sending to host?

 What do you mean by that? Do you want to increase the packet size so you can send more than 64 bytes?

[bscdb]

I read somewhere that Windows machine accepts 64 bytes from BLE device. So accordingly I should make changes in HID descriptor which are - REPORT_COUNT = 64, REPORT_SIZE = 8. In the current situation, the below image demonstrates how many no. of bytes are sent/received in nrfConnect.

If I make the changes for 64 bytes, do I need to take care of any header bytes getting added to the packet or can all 64 bytes be data bytes? I know for sure that the first byte to be sent from nrf to pc should be report ID.

Also in the code, in which locations are the packet size actually being checked for input & output report?

I would like maximum size possible for input & output report for Windows OS & Mac OS.

[bscdb]

Please take this on priority.

[Hakon]

Yeah I'm looking at it. I have confirmed that sending 8 bytes works and sending more does not. I haven't found the cause yet.

[bscdb]

Ohh Okay. Let me know. Thanks.

[bscdb]

Any update?

[bscdb]

Any progress?

[Hakon]

Yeah, I was able to send 20 bytes. Changed the value of INPUT_REPORT_KEYS_MAX_LEN.

[bscdb]

I changed

#define INPUT_REPORT_KEYS_MAX_LEN           20

STATIC_ASSERT((INPUT_REPORT_KEYS_MAX_LEN - 2) == 18);

ble_hids_inp_rep_send(&m_hids, 0, INPUT_REPORT_KEYS_MAX_LEN, (unsigned char*)&arr_data, m_conn_handle);

I see 20 bytes in nrfConnect but how can it receive 20 bytes without making changes to report descriptor for input report???

After I make changes to input report in descriptor

0x75, 0x08,				// REPORT_SIZE(8)
0x95, 0x14,				// REPORT_COUNT(20)

and in SimpleHIDWrite, I get

Why only 2 bytes are received? 

What needs to be done to increase no. of bytes for output report?

What is the maximum size possible for output reports for Windows & MAC OS?

Is IN/OUT endpoint configured to send/receive data on receiving an IN/OUT token packet?

[bscdb]

Ping..

[Hakon]

bscdb said:

I see 20 bytes in nrfConnect but how can it receive 20 bytes without making changes to report descriptor for input report???

 As far as I know it's impossible without changes to the report descriptor.

 

bscdb said:

Why only 2 bytes are received? 

 Do you get this with other applications too, or is it just the SimpleHIDWrite that is able to receive two bytes?

 

bscdb said:

What needs to be done to increase no. of bytes for output report?

 I think you need to change this in the report descriptor.

 

bscdb said:

Is IN/OUT endpoint configured to send/receive data on receiving an IN/OUT token packet?

 I'm not sure. This has little to do with BLE and more to do with low level USB implementation.

 

bscdb said:

What is the maximum size possible for output reports for Windows & MAC OS?

 I believe it's 64 bytes.

[bscdb]

I see 20 bytes in nrfConnect even if I dont make changes to report_map_data[].

In applications other than SimpleHIDWrite, I am able to read only 2 bytes.

What is missing?

I observed that if I use 

err_code = ble_hids_inp_rep_send(&m_hids, 0, 8, (unsigned char*)&BTN_data, m_conn_handle);

then I see 3 bytes 

but if I use 

err_code = ble_hids_inp_rep_send(&m_hids, 0, INPUT_REPORT_KEYS_MAX_LEN, (unsigned char*)&BTN_data, m_conn_handle);

where INPUT_REPORT_KEYS_MAX_LEN = 20

then either I dont see any data or just see 2 bytes!!

This is inside send_BTN_values() function in my code.

I also tried with gamepad report descriptor and tried increasing no. of bytes on report id 2 but I get driver error while connecting Bluetooth.

Please reply at the earliest.