BLE Central tutorial not connecting to my peripheral

Question

The BLE Central tutorial (S130 based) does not connect to my peripheral. My peripheral connects fine to the Android MCP and the 128-bit service UUID is what I expect. 
 I'm debugging the Central code and looking at the BLE_GAP_EVT_ADV_REPORT case in the on_ble_evt function. It calls adv_report_parse to find advertising data of type BLE_GAP_AD_TYPE_128BIT_SERVICE_UUID_MORE_AVAILABLE and then BLE_GAP_AD_TYPE_128BIT_SERVICE_UUID_COMPLETE. But it never finds advertising data of either type. Shouldn't the 128-bit service UUID be coming in as one of these types? 
 What might I be doing wrong? 
 Here's a screenshot of the MCP data received:
 
 Here's the UUID as defined in the code of the central: 
 #define THROUGHPUT_BASE_UUID {0x9E, 0xCA, 0xDC, 0x24, 0x0E, 0xE5, 0xA9, 0xE0, 0x93, 0xF3, 0xA3, 0xB5, 0x00, 0x00, 0x40, 0x6E} /**< Used vendor specific UUID. */

Anders Strand · Accepted Answer

Hi. 
 I will start by explaining a couple of concepts regarding UUID's and advertising. Then i will address your errors. 
 When dealing with 128 bits UUID's, we use a base uuid (128 bit) and a service uuid (16 bit). For example in advertising, the 16 bit uuid is places on byte 12 and 13 of the base uuid, and advertised. 
 This is copied from the UUID section of the BLE services tutorial : 
 "The second type is a 128-bit UUID, sometimes referred to as a vendor specific UUID. 
This is the type of UUID you need to use when you are making your own custom services and characteristics. 
It looks something like this: 4A98xxxx-1CC4-E7C1-C757-F1267DD021E8 and is called the “base UUID”. 
The four x’s represent a field where you will insert your own 16-bit IDs for your custom services and characteristics and use them just like a predefined UUID. 
This way you can store the base UUID once in memory, forget about it, and work with 16-bit IDs as normal."
 
 In the nus (Nordic Uart Service) example we use the function 
 sd_ble_uuid_vs_add(&nus_base_uuid, &p_nus->uuid_type)
 
 to add a base uuid to the softdevice. The p_nus->uuid_type will be written when calling the function. This variable will contain the uuid type of the base uuid. In practice, it is a number to where in a table the base uuid was stored. 
 The first time we call sd_ble_uuid_vs_add , the base uuid we put in is stored at the index BLE_UUID_TYPE_VENDOR_BEGIN. Therefore. If we add another, it will be at BLE_UUID_TYPE_VENDOR_BEGIN+1. Since you are only using one custom service (i am assuming), your base uuid will be at BLE_UUID_TYPE_VENDOR_BEGIN. 
 In any case: The best way to do this is to store the value p_nus->uuid_type, and use this whenever we do anything related to the base uuid. (For example adding a service, or adding the full uuid to the advertising packet). We can see that this is actually being done by the NUS code inside ble_nus_init . 
 Now. In the NUS peripheral example, we see that the type BLE_UUID_TYPE_VENDOR_BEGIN is used for the type in the uuid array m_adv_uuids. This is actually a "shortcut" or easy solution. Since we know that we will only add one custom (or vendor specific) uuid, we know that BLE_UUID_TYPE_VENDOR_BEGIN will be the correct type. 
 On to solving your issue. Either use BLE_UUID_TYPE_VENDOR_BEGIN as the uuid type THROUGHPUT_SERVICE_UUID_TYPE. Or use the uuid type stored in m_nus.uuid_type. 
 Let me know if anything is unclear. 
 -Anders