Service discovery call back returns incorrect service UUID?

[MichaelNordicUser]

I'm printing the value of the UUID of the service(s) discovered on two types devices when the BLE Multi-link Example connects to them, an NRF52 flashed with the blinky app in the same SDK, and my Android phone running this server app.

/**
 * This method is the service-discovery call-back in ble_lbs_c.c. I've added a log statement to print out 
 * of the value of the UUID of the service(s) being discovered. 
 **/
void ble_lbs_on_db_disc_evt( ble_lbs_c_t * p_ble_lbs_c, ble_db_discovery_evt_t const * p_evt)
{
    
    int  num = p_evt->params.discovered_db.srv_uuid.uuid; 
    char hex[4];
    sprintf(hex, "%x", num);

    SEGGER_RTT_WriteString(0, "discovered service UUID = ");
    SEGGER_RTT_WriteString(0, hex);
    SEGGER_RTT_WriteString(0, "\n");
        
   // ... the rest of the body
}

What I've noticed is that that the service UUID of the discovered service(s) on the phone is always 1523 which is strange becuase isn't 1523 also the service UUID of the discovered LED service on blinky app? Why is the short UUID being used and not the long version?

A sample output in my RTT when discovering the services on the Android phone is the following (P027 is the device model of the phone)

 0> Intercepted P027 packet
 0> Connecting to P027
 0> Intercepted P027 packet
 0> Connecting to P027
 0> discovered service UUID = 1523
 0> device disconnected
 0> device disconnected
 0> device disconnected
 0> device disconnected
 0> device disconnected
 0> device disconnected
 0> device disconnected
 0> device disconnected
 0> Intercepted P027 packet
 0> Connecting to P027
 0> discovered service UUID = 1523

Why is it that the service UUID of the my phone is 1523 ? Is that right?

When the services of the blinky app are discovered, I get this output

 0> Connecting to blinky
 0> Intercepted blinky packet
 0> Connecting to blinky...
 0> discovered service UUID = 11
 0> discovered service UUID = 11
 0> discovered service UUID = 11
 0> discovered service UUID = 11
 0> discovered service UUID = 11
 0> discovered service UUID = 11
 0> discovered service UUID = 11
 0> discovered service UUID = 11
 0> discovered service UUID = 1523

Now what is the significance of the number 11?

To make a long short, why does the service in the phone have the same short UUID as the blinky app? And what is 11?

[endnode]

Hi,

The point is that you print out only short 16-bit (2-byte) UUIDs. Nordic stack always work with full 128-bit UUIDs in a little bit special form (which makes sense if you appreciate how UUIDs are defined in BT SIG specification):

• Each UUID is pair of short UUID value (in your case 0x1523 or 0x0011) and "UUID type" which is actually index in virtual table of known (= provisioned to Soft Devie BLE stack through GATT API function sd_ble_uuid_vs_add) - or actually unknown - 128-bit UUID bases.
• So the fact that some UUIDs have the same 16-bit short part can be only coincidence, the type says all.

In addition there are definitely more than one service on phone's GATT Server so firstly I'm not sure if your service discovery is doing what it should (or what you want) and secondly the questions "Why is it that the service UUID of the my phone is 1523 ? Is that right?" don't make any sense. if you as if it's possible that GATT Server on the phone has such service then indeed it's possible, why not? If there is any application which provisions such GATT Service then it's there. Who knows what you have on that phone?:) And btw. there can be even more GATT objects with the same UUID on the same server. They will have different handle IDs but UUID is like a name and you can have several people named John in your house so it works the same way.

When it comes tho discovery of your blinky app it kind of indicates that your GATT Service discovery is out of control or just acting weirdly: why would your discovery DB module report the same service 8 times? Unless you modified the GATT Server code and it really contains 8 such Services... but I doubt.

[RK]

and apart from that there are various error codes which tell you whether the data is even valid and none of those have been checked. So this is a print out of random nubers.

[endnode]

You seems to be missing how advertiser/broadcaster and connection link work. The scenario you describe is very much unlikely and the probability that you have bug in your code is many times bigger. GATT Service discovery has nothing to do with advertisement and it cannot be disturbed by any such packet even if it would be sent (mainly because receiver cannot by any chance accept it as part of the valid link). I'm afraid you lost control over your project long time ago and from some messy RTT debug messages (which you are unsure what they say and where they come from) it will be hard to get it together again.

Also 95% of GATT Clients have very simple use case of "find one service => find one characteristic under it => use it as communication tube" so I have feeling that most of things your client does on app layer is totally wasting of time and code space.

[MichaelNordicUser]

Thanks for the feeback. I will flash the chip and start from scratch. I am reading the docs and trying to understand the database discovery module. Am I correct when I say that the discovery event handler forwards discovery events to the ble_lbs_on_db_disc_evt function if the server UUID in the discovery event matches the registered Light Service UUID? Or are all discovery events whose UUID matches a registered UUID (and no others) forward to ble_lbs_on_db_disc_evt function? Or am I just not making any sense?

[endnode]

Well I cannot comment much on how exactly db_discovery module works because as I said I never found use for it. If I'm looking for specific Service and Characteristics then it can be done in two simple loops going through certain ranges of GATT handles and there are even GATT Methods where you ask for handle with given UUID and you get straight answer so why to discover all objects and building some database? This is what generic devices with separated GATT Client and APP layers do, e.g. all phones and tablets and probably PCs. But that's basically never the case on embedded system such as nRF5x. You basically always know what UUID are you looking for right now so I don't see any use of this module...

[MichaelNordicUser]

Thanks. This is exactly what I want to do. I want to connect to multiple GATT servers I know the UUIDs of. Is this multi-link app the closest example in the SDK of what I want to accomplish? You make it sound so simple, but I have no idea how to accomplish this.