Compliance with Bluetooth Qualification - adopted services

RE: Compliance with Bluetooth Qualification - adopted services

Hung Bui — Mon, 06 Nov 2017 08:55:42 GMT

Hi Mohammad,

It would reduce the time needed to do service discovery. It requires a few more packets to discovery a service, compare to an extra characteristic inside the defined service.

The advantage of separated battery service is interoperability. If you use battery service as standard SIG service, other 3rd party app can read and interpret the service.

However, if your main service is proprietary, then I don't think it would be a big advantage.

RE: Compliance with Bluetooth Qualification - adopted services

Mohammad Afaneh — Fri, 03 Nov 2017 21:19:39 GMT

Hung, one question: is there an advantage for having three battery services (one per device) vs. just having a battery level characteristic within each of the existing device services?

RE: Compliance with Bluetooth Qualification - adopted services

Mohammad Afaneh — Fri, 03 Nov 2017 14:17:08 GMT

Thanks, Hung

RE: Compliance with Bluetooth Qualification - adopted services

Hung Bui — Fri, 03 Nov 2017 12:46:52 GMT

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.

RE: Compliance with Bluetooth Qualification - adopted services

Mohammad Afaneh — Fri, 03 Nov 2017 03:24:06 GMT

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?

RE: Compliance with Bluetooth Qualification - adopted services

Hung Bui — Thu, 02 Nov 2017 11:39:16 GMT

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.

RE: Compliance with Bluetooth Qualification - adopted services

Mohammad Afaneh — Wed, 01 Nov 2017 17:09:04 GMT

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!

RE: Compliance with Bluetooth Qualification - adopted services

Hung Bui — Tue, 31 Oct 2017 14:34:05 GMT

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.