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

Compliance with Bluetooth Qualification - adopted services

In the source files of standard/adopted services, there's a comment stating:

/* Attention!
 * To maintain compliance with Nordic Semiconductor ASA's Bluetooth profile
 * qualification listings, this section of source code must not be modified.
 */

If one wants to use one of these services and initialize it as a secondary service instead of a primary service, does that interfere with the qualification?

What's the best way to re-use one of these services as a secondary service? I assume modifying the original files for these services would not be a good idea(?)

  • Hi Mohammad,

    Could you give some more information why you want to use the service as secondary service ? We don't really support secondary service as it's hard to find the need to use secondary service.

    I believe if you use the service as secondary service, you do need to re-qualify the profile.

  • Hi Hung,

    Thanks for the answer. The use case I'm running into is as follows: I have an nRF52 acting as a "gateway" running in Central Mode to connect and read data from other Peripherals, and then as a Peripheral to expose this data to the nRF Cloud via a PC (or another internet-connected device such as a Raspberry Pi 3).

    The end nodes in the system each has a battery and exposes a Battery service, so my thinking is that instead of having multiple instances of the Battery service on the peripheral side for my "gateway" (one for each end node), I'd create one secondary Battery service and include it in multiple services.

    Does this make sense? any suggestions?

    Thanks!

  • I don't think you need to use battery service as secondary service in your use case. I don't see any benefit here. It actually takes longer to discover secondary service than the primary one.

    Are you planning to create a service for each of the device you connect to ? If they are sharing the same services, I would suggest to use one service for all of them, and use one extra byte or one extra characteristic as the identifier to select each of the peripherals.

  • Hung,

    So here's a more detailed explanation of what I'm attempting to do. I will have 3 devices that each exposes a Battery service (with Battery level characteristic). The "gateway" will read these values and the intention is to expose them in the peripheral mode. The devices are different and each expose different types of values (characteristics), so it makes sense to use one service per device.

    Now, if I define a Battery service as a primary service on the "gateway" then this would show up when discovering services on the gateway. How would this Battery service map to each end node device? or is the suggestion to have 3 primary Battery services? I was thinking that each end-node device will have a service (3 services total on the gateway):

    • Device 1 service: { char 1a, char 1b...etc }
    • Device 2 service: { char 2a, char 2b, ...etc }
    • Device 3 service: { char 3a, char 3b, ...etc }

    In addition to each of these characteristics, each device's service would include the Battery service (and hence the thinking that the Battery service would be a secondary service). In this case, would each of these Device services have its own "instance" of the battery service? or am I getting this wrong? and what difference would it make if each service included a primary Battery service instead of a secondary?

  • You are correct. Even if you use battery service as secondary service, you would need one battery secondary service for each of the service you relate from.

    There is very little if not, none, use of the secondary service. I would suggest you to simply put the battery service as the 2nd service of each device, like this:

    Device 1 service: { char 1a, char 1b...etc }
    Device 1 battery service: { char 1a, char 1b...etc }
    Device 2 service: { char 2a, char 2b, ...etc }
    Device 2 battery service: { char 1a, char 1b...etc }
    Device 3 service: { char 3a, char 3b, ...etc }
    Device 3 battery service: { char 1a, char 1b...etc }
    

    I don't see any disadvantage doing it this way.

Related