Smartphone and nrf52 dk with same service

[rcfr]

Hello,

I've implemented one custom service very similar with NUS. I have two peripherical devices that are running in two PCA10040 with S132 12.1, and one central device that is running in one PCA10040 with S132 12.1. I've managed to connect, bond and communicate the periphericals and the central, one at a time. I've also implemented one peripherical device in one S6 with android 6. I've also managed to connect, bond and communicate the smartphone with central.

But I'm facing one problem: if I make the communication of the smartphone and central, and then try to communicate the PCA10040 with the central without reset the central, the connection and bond work, but the transmition of data through the caracteristics dont, despite the discovery of these characteristics "apparently" work. This problem also happens when I first communicate with the PCA10040, and then try to communicate with the smartphone. So my question is: Can the smartphone and the PCA10040 have the same service with the same UUID?

I'm asking this because I'm getting the same handdles in the service discovery when I switch between the devices(smartphone and PCA) without reset, but when I run then one at a time, resetting the PCA10040 between the executions, I get different handdles. For example, if I run the discovery for the PCA10040, I get the handles 1 and 2 for the tx and rx characteristics, then I reset the PCA10040 and run the discovery for the smartphone , I get the handles 3 and 4 for the tx and rx characteristics.

Best Regards.

[endnode]

Hello,

There are obviously some details missing in the story (e.g. it is pretty much impossible to have GATT Characteristic at handle number 1 because that's the first one on GATT server stack and hence no space for the Primary Service handle - I assume that numbers 1/2/3/4 in the last paragraph are just examples) but answer to general question "Can multiple GATT servers host Service or Characteristic with the same UUID?" is "Of course they can (actually they usually must;)."

The sequence how to work from GATT Client side with every GATT Server should be roughly following:

1. Based on MAC address (after deanonymisation if applied) check if you have ATT/GATT handles cached (= if the stack doesn't contain Service Changed characteristic which indicates it's static forever) and if so just use them.
2. If ATT/GATT server isn't static or you meet this MAC first time then do GATT Service Discovery. There is no standard sequence of ATT Methods how to go through Sever tree structure of handles but I'm sure you will design the best for your purpose (if you are looking always only for particular UUID(s) then you can do it faster then generic GATT Client - e.g. mobile phone - which should enumerate all).
3. Now depending on presence of GATT Service Changed characteristic (as discovered in previous step) you have your GATT handles for this device and only this connection (if Service Changed is present) or forever (if it isn't). Note that for dynamic Server situation you should subscribe to Service Changed characteristic for Notifications in case that GATT Server changes during your connection!

Key point is that each device (= GATT Server) must be treated separately but then it can contain the same UUIDs (and they can reside on different ATT/GATT handles! - and these can even change handle numbers if GATT Server is dynamic).

Cheers Jan

[rcfr]

Thanks for the response Jan.

The values of the handdles were just examples.

In my project I'm not doing the process the most fastest way: after de bond happen with sucess, using the peer manager (PM_EVT_CONN_SEC_SUCCEEDED), I'm always calling ble_db_discovery_start(), but the handdles are not changing, even if the devices that i'm connecting are different (smarthone and PCA10040). The service is based in the NUS, so I'm not using Service Changed characteristic, I'm using only notification (hvx). So based in your response, every time we call the discovery we should receive a different handdle if the devices are different, right?

Best Regards.