Setting Class of Device

[ohtap]

Hi,

We've developed a BLE HID device with mouse and keyboard capabilities based on the nRF52832 and SDK 14.0.

We're interested in declaring the CoD as "Combo keyboard/pointing device" as part of our advertising data. We currently set the "apperance" field as BLE_APPEARANCE_GENERIC_HID.

Most operating systems are fine with only having the appearance field, but some also filter by CoD.

We've noticed that ble_advdata_encode() in ble_advdata_set() encodes the name, appearance, address, flags, power level and a few other fields, but we haven't found any encoding function for the CoD. It also doesn't appear in the advdata struct.

Has the CoD encoding been implemented anywhere? is there an alternate way to set the CoD?

Thanks!

[Kenneth]

Hi,

I am not familiar with this CoD field, I do not believe there is such flag or struct in advertisement data. If you can refer to any specification that include this in the advertisement data let me know.

You only set the appearance as you already do, and then write the HID descriptor to include multiple reports, e.g.:

https://github.com/Rallare/nrf51_ble_app_hids_kbd_consumercontrol/blob/SDK15/main.c 

Best regards,
Kenneth

[ohtap]

Thanks for the reply.

We're already successfully advertising the HID service and support multiple input reports.

Here is some documentation about CoD: https://www.bluetooth.com/specifications/assigned-numbers/baseband

Under "Minor Device Class field - Peripheral Major Class" there are options such as "Keyboard" and "Combo keyboard/pointing device".

It seems like this is information that can be added to the advertising packet, but aren't supported by the Nordic SDK.

We might try and implement it, but would appreciate if you can assist.

Thanks!

[Kenneth]

Hmm... If we understand correctly the Core Specification Supplement v8.0, the "Class of Device" Data Type is a field in the "Secure Simple Pairing OOB", which is not relevant to the context of Advertising Data as table 1.1 indicates. It only comes into play in OOB data blocks. 

Best regards,
Kenneth

[ohtap]

Could it be used in both cases?

According to BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part C] section 11 page 389 (https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=441541&_ga=2.121607560.1212259718.1552489685-1575058953.1547371943)

the general advertising and scan response structure is composed of AD types and AD Data.

Class of Device has a value of 0x0D according to https://www.bluetooth.com/specifications/assigned-numbers/generic-access-profile

And the type identifiers are listed in https://www.bluetooth.com/specifications/assigned-numbers/baseband

Using https://www.ampedrftech.com/cod.htm we get a AD Type value of 0x05C0 (Peripheral, Combo Keyboard / Pointing device). 

It seems the SDK encodes the advertising packet in a similar way in appearance_encode(). It sets the AD Data as BLE_GAP_AD_TYPE_APPEARANCE (0x19) and gets the appearance value (we set it as BLE_APPEARANCE_GENERIC_HID = 960).

So unless we're mistaken, you could add to the advertising data packet the AD Type as 0x05C0 and the AD Data as 0x0D.

Does that make sense? 

Thanks!

[Kenneth]

Hi,

It does make sense, but it is the first I have seen of it, so I doubt it is much used. The best I can do is to add it to the internal jira for potential next SDK releases, in the meantime you will need to manually edit the p_encoded_data to add this yourself.

Can you provide some more information which OS use this? (Ref your text: "Most operating systems are fine with only having the appearance field, but some also filter by CoD.").

Best regards,
Kenneth

[ohtap]

OK, thanks, we'll try and implement it in the meantime.

It's a custom OS with limited distribution. We're not familiar with it ourselves and only act using info by the developers. Since they filter based on CoD we try and adjust for compatibility.