Compliance with Bluetooth Qualification - adopted services

[Mohammad Afaneh]

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(?)

[Mohammad Afaneh]

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?