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.

[endnode]

Yes, this is the right understanding how connections are handled by SD and its API!