drowning in numbers

[paul]

Hi,

      we are late stage development on NRF52840 with sdk 15.0 and softdevice 6.0. The mind turns to certification. It all seems very complex and confusing

1) Do we need to be members of the bluetooth sig?

2) Do we need to qualify our products?

3) Do we need a company bluetooth Community ID and if so where would we use it?

4) We have a device information service on our product, do we need an IEEE OUI? Can we just take the current random mac and format the system id according to the standard?

5) Can we use a CUI instead of an OUI?

Cheers Paul

[run_ar]

1. Yes. But it's enough to be an adopter member: https://www.bluetooth.com/develop-with-bluetooth/join/membership-benefits/

2. You need to create an end product listing: But you can reference the nordic qualified design. Which covers qualification for LL and HOST. You can also reference our profile subsystem if you are using any Bluetooth defined profiles. e.g. device information service. We usually recommend that you do an RF-PHY test unless you are using a module. Note that if you follow our reference design and layout you might be able to claim similarity to our RF-PHY component that is part of the qualified design, thus avoiding this test.

3. Maybe. Some services requires a company id.

4. Have you checked the profile specification? Seems most/all characteristics are optional. But might be required by another profile.

5. Not sure I know these acronyms, sorry.

[paul]

thanks Run_ar,

Apparently we are a member of the bluetooth sig. OUI and CUI are Organisation Unique Identifier and Company Unique identifier - both from IEEE. The device information service profile requires an OUI in the system id struct and there is some indication that the CUI can be used instead.

Currently we have:

1) our main service which is unknown - uses 128bit uuids

2) Device information service which has a bodged up system id because we don't have an OUI

3) battery service

4) DFU service which has three extra characteristics listing hardware, firmware and protocol revisions.

The issues I am concerned with are:

1) our main service - do we need to do the kind of registration Nordic did for all their services.

2) our dis using a bodgy system id but:

One interesting thing about the spec for the system id in DIS is that you are supposed to be able to take the mac address, add some numbers, slice and dice to use as the system id. However I am not sure whether they envisaged the random mac addresses like the nordic chips use.

The SYSTEM ID characteristic consists of a structure with two fields. The 
first field are the LSOs and the second field contains the MSOs. 
This is a 64-bit structure which consists of a 40-bit manufacturer-defined identifier 
concatenated with a 24 bit unique Organizationally Unique Identifier (OUI). 
The OUI is issued by the IEEE Registration Authority 
(http://standards.ieee.org/regauth/index.html) and is required to be used 
in accordance with IEEE Standard 802-2001.6 while the least significant 40 
bits are manufacturer defined.

If System ID generated based on a Bluetooth Device Address, it is required to be done 
as follows. System ID and the Bluetooth Device Address have a very similar structure: 
a Bluetooth Device Address is 48 bits in length and consists of a 24 bit Company Assigned 
Identifier (manufacturer defined identifier) concatenated with a 24 bit Company 
Identifier (OUI). In order to encapsulate a Bluetooth Device Address as System ID, the 
Company Identifier is concatenated with 0xFFFE followed by the Company Assigned Identifier 
of the Bluetooth Address. For more guidelines related to EUI-64, refer to 
http://standards.ieee.org/develop/regauth/tut/eui64.pdf.

Example:

If the system ID is based of a Bluetooth Device Address with a Company Identifier (OUI) 
is 0x123456 and the Company Assigned Identifier is 0x9ABCDE, then the System Identifier 
is required to be 0x123456FFFE9ABCDE.

the above from: www.bluetooth.com/.../org.bluetooth.characteristic.system_id.xml

3) the addition of the characteristics to the DFU service.

Cheers Paul

[run_ar]

1) No, as long as this is a proprietary service there is no registration.

2) not quite sure about this on, will have to check. Do you need to include this at all?

3) Is this the nordic DFU? adding extensions to proprietary services is no problem as long as you are using a vendor specific UUID.

[paul]

Hi Run_ar,

                    yes this is the Nordic DFU service with additions. So I take it I just change the UUID to a 128bit version and it should be right?

Cheers Paul

[run_ar]

Yes. Use a 128 bit vendor specific UUID for the additions and you should be fine.