getting ble_app_uart_c central device connecting with peripheral

[kont40]

Hello,

I am trying to adjust a peripheral device to connect a central device based on ble_app_uart_c example. Although this example has been discussed numerous times I was not able to find what's wrong by browsing previous discussions.

In short, about a year ago I have adjusted ble_app_uart_c  to work with a previously developed peripheral device (using a TI CC2650), that's why service UUID and characteristic UUID were modified. The previously developed device connects to the central just fine. However, I am working on a new device, which is based on nRF52832, and trying to adjust it to connect the same central device. I adjusted the service and characteristic IDs as shown below, but still can't get them connected, and I am a bit out of ideas what I am missing, any help would be appreciated.

The configuration of the central device is:

// service ID    
#define NUS_BASE_UUID                   {{0xFB, 0x34, 0x9B, 0x5F, 0x80, 0x00, 0x00, 0x80, 0x00, 0x10, 0x00, 0x00, 0xF0, 0xFF, 0x00, 0x00}}                 
#define BLE_UUID_NUS_SERVICE            0xFFF0 
#define BLE_UUID_NUS_RX_CHARACTERISTIC  0x0002
#define BLE_UUID_NUS_TX_CHARACTERISTIC  0xFFF4 

On the other side, the configuration of the peripheral device is:

#define BLE_UUID_DEV_CHARACTERISTC_UUID    0xFFF4

#define BLE_UUID_DEV_BASE_UUID              {0xFB, 0x34, 0x9B, 0x5F, 0x80, 0x00, 0x00, 0x80, 0x00, 0x10, 0x00, 0x00, 0xF0, 0xFF, 0x00, 0x00}
#define BLE_UUID_DEV_SERVICE                0xFFF0 

[tesc]

Hi,

• Can you confirm that it does not assert / reset? See this thread for how to debug.
• Can you confirm that the device advertises?
• Are you able to connect to it using nRF Connect? (Either for Android, iOS, or for desktop.)
• When you change an example from using 16 bit UUIDs (as defined from Bluetooth SIG) to using custom UUIDs ("vendor specific UUIDs"), you must configure the SoftDevice to allocate space in memory for your custom UUIDs. See this thread. Please also note that in the latest SDKs the number of custom UUIDs is defined using NRF_SDH_BLE_VS_UUID_COUNT in sdk_config.h.

Regards,
Terje

[kont40]

Dear Terje,

Thanks for detailed response. As to above points:

- the device do not seem to reset;

- since I am able to see it in nRF connect on a tablet with Android OS, I believe advertising is fine.

- I am able to connect to device using nRF connect, see the characteristic and get the data from notifications.

- as to the last point - to avoid potential problems with 16-bit UUID I set back the Nordic UART service as shown in the screenshot. Also, I have changed the respective ids at the central side too, as shown in the code below. However, still can't get the two boards connect. Will appreciate any further advice.

The configuration at the central device:

#define NUS_BASE_UUID 					{{0x9E, 0xCA, 0xDC, 0x24, 0x0E, 0xE5, 0xA9, 0xE0, 0x93, 0xF3, 0xA3, 0xB5, 0x00, 0x00, 0x40, 0x6E}} /**< Used vendor specific UUID. */
#define BLE_UUID_NUS_SERVICE            0x0001                     
#define BLE_UUID_NUS_TX_CHARACTERISTIC  0x0002                      
#define BLE_UUID_NUS_RX_CHARACTERISTIC  0x0003                     

The peripheral seen in nRF Connect:

[tesc]

Then you must look at how the central finds the peripheral. For instance, the central may filter what peripheral to connect to based on advertised name, or advertised service UUID.

An easy way to get some clues could be to let the old device advertise, and look at that advertisement data from nRF Connect.

Edit: Since you made the central device, you probably know what the central is looking for in order to connect?

[kont40]

Hello tesc

Thanks for the advice, following it I found that the target UUID checked into is_uuid_present() was different from extracted UUID. Problem solved!!!