Bluetooth profile common characteristics between services

[Tom]

We are currently developing a family of products that will use Bluetooth and I am putting together the plan for the profiles for each product.

I have structured the profiles so that there is much reuse as possible between products. There are services that will be identical across products, this seems straightforward.

Where I am questioning the structure is where there are characteristics that are common between services and whether my structure is the right way to do it, and more importantly, will it cause any unforeseen issues.

My current structure is something like this:

Product Apple   -   Service 1   -   Characteristic A
                                    Characteristic B
                    Service 2   -   Characteristic C
                                -   Characteristic D
                    Service 3   -   Characteristic E

Product Banana  -   Service 1   -   Characteristic A
                                -   Characteristic B
                    Service 4   -   Characteristic F
                                -   Characteristic G
                                    Characteristic C

Service 1 is shared between the two products, all good.

The structure of the UUIDs are that Characteristic A and B share the same base UUID as Service 1 but the second group of 16 bits are incremented, all good.

Where I start questioning this is when Service 4 comes into play and has the same characteristic (Characteristic C) as Service 2.

Characteristic C does not use the same base UUID as Service 2 or 4 - I gave it a different base as it is shared but does have the same UUID when used in Service 2 and 4.

The idea being that I could reuse the same code to create that characteristic (and the mobile app that will eventually connect to the product could do the same) and call it from Service 2 and 4.

Are there any issues with this approach? Am I likely to come into any issues reusing the UUID for the characteristics like this? Are there any best practices I am violating doing it this way?

[Sigurd]

Hi,

Your approach seems fine. Since the characteristic have a different UUID when it's used in e.g. service 2 and 4, it shouldn't be any issues.

[Tom]

Hi Sigurd,

Thanks for your response. You say that if the characterisitc have different UUID then this isn't an issue but from my description:

Tom said:

Characteristic C does not use the same base UUID as Service 2 or 4 - I gave it a different base as it is shared but does have the same UUID when used in Service 2 and 4.

Characteristic C does have the same UUID in Service 2 and 4.

Maybe my description wasn't the best, to expand this is what I proposed in the example with UUIDs for each

Product Apple - Service 1 (UUID 0xAAAA0000AAAAAAAAAAAAAAAAAAAAAAAA) - Characteristic A (UUID 0x0001)
                                                                    - Characteristic B (UUID 0x0002)
                Service 2 (UUID 0xBBBB0000BBBBBBBBBBBBBBBBBBBBBBBB) - Characteristic C (UUID 0xZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ)
                                                                    - Characteristic D (UUID 0x0001)
                Service 3 (UUID 0xCCCC0000CCCCCCCCCCCCCCCCCCCCCCCC) - Characteristic E (UUID 0x0001)

Product Banana- Service 1 (UUID 0xAAAA0000AAAAAAAAAAAAAAAAAAAAAAAA) - Characteristic A (UUID 0x0001)
                                                                      Characteristic B (UUID 0x0002)
                Service 4 (UUID 0xDDDD0000DDDDDDDDDDDDDDDDDDDDDDDD) - Characteristic F (UUID 0x0001)
                                                                    - Characteristic G (UUID 0x0002)
                                                                    - Characteristic C (UUID 0xZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ)

So to clarify, from your response should I change the UUID for Characteristic C from 0xZZ..ZZ to follow the base ID for each Service and use a 16 bit unique for that service? ie:

Product Apple - Service 1 (UUID 0xAAAA0000AAAAAAAAAAAAAAAAAAAAAAAA) - Characteristic A (UUID 0x0001)
                                                                    - Characteristic B (UUID 0x0002)
                Service 2 (UUID 0xBBBB0000BBBBBBBBBBBBBBBBBBBBBBBB) - Characteristic C (UUID 0x0002)
                                                                    - Characteristic D (UUID 0x0001)
                Service 3 (UUID 0xCCCC0000CCCCCCCCCCCCCCCCCCCCCCCC) - Characteristic E (UUID 0x0001)

Product Banana- Service 1 (UUID 0xAAAA0000AAAAAAAAAAAAAAAAAAAAAAAA) - Characteristic A (UUID 0x0001)
                                                                      Characteristic B (UUID 0x0002)
                Service 4 (UUID 0xDDDD0000DDDDDDDDDDDDDDDDDDDDDDDD) - Characteristic F (UUID 0x0001)
                                                                    - Characteristic G (UUID 0x0002)
                                                                    - Characteristic C (UUID 0x0003)

My thinking had been that given the characterstic was the same when used in different services it should have the same UUID. Should it instead be unique within each service, even if the characteristic is essentially duplicated?

[Sigurd]

Tom said:

You say that if the characterisitc have different UUID then this isn't an issue

 Since the Service base is different, then it should be possible for the central to distinguish e.g. Characteristic C used in Service 2 from the one used in Service 4, even if the 16 bit UUID is the same.

I did some quick testing, I modified the lbs(LED Button Service) 16 bits UUIDs to match the ones used in NUS(Nordic UART service), and then added added lbs to the ble_app_uart example, and I did not experience any issues when testing with a Android phone as central. But, if you run into issues during your testing, then I guess it's easy to change the 16 bit UUIDs to be unique when used in different services, but I think you should be OK. If you see any issues when testing this, then let me know.