nRF52833 cannot interconnect and communicate with BLE chip of Realtek

[panypan]

Hello,

Our customer has a project that uses nrf52833 as the master and want to connect to the slave of portable ECG meter (ble is Realtek). But they tried for a long time and still failed.

1. ECG meter (slave device) --- Realtek ble device Information :

UUID types: 128bit

UUID = {0xFB, 0x34, 0x9B, 0x5F, 0x80, 0x00, 0x00, 0x80, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}

2. nrf52833 DK as master device:

a. BLE central base on "nRF5_SDK_17.1.0_ddde560\examples\ble_central\ble_app_uart_c\pca10100\s122\arm5_no_packs"

b. Scan filter for UUIDs and UUID config is below:

#define NUS_BASE_UUID {{0xFB, 0x34, 0x9B, 0x5F, 0x80, 0x00, 0x00, 0x80, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}}   /**< Used vendor-specific UUID. */

#define BLE_UUID_NUS_SERVICE    0xFF12                                              /**< The UUID of the Nordic UART Service. */
#define BLE_UUID_NUS_RX_CHARACTERISTIC     0xFF01                      /**< The UUID of the RX Characteristic. */
#define BLE_UUID_NUS_TX_CHARACTERISTIC      0xFF02                      /**< The UUID of the TX Characteristic. */

c. If  "#define NUS_SERVICE_UUID_TYPE   BLE_UUID_TYPE_BLE", 52833 can be connected to ECG meter, but the service cannot be found that log is "Service UUID 0xFF12 not found.".

    If  "#define NUS_SERVICE_UUID_TYPE   BLE_UUID_TYPE_VENDOR_BEGIN" , 52833 cannot connect to ECG meter and the function of ble_advdata_uuid_find() return 7 (NRF_ERROR_INVALID_PARAM). This function is called by adv_uuid_compare() in the file "nrf_ble_scan.c".

3. My question:

a. Whether nRF52833 interconnect and communicate with Realtek are feasible?

b. If feasible, what is missing from the customer's above configuration?

c. Is there any other way to solve this problem?

Thanks

Pany

[Sigurd]

Hi,

UUID types: 128bit

UUID = {0xFB, 0x34, 0x9B, 0x5F, 0x80, 0x00, 0x00, 0x80, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}

This is not a vendor defined 128-bit UUID, this is the base UUID used by the 16-bit UUIDs defined by Bluetooth SIG.

0xFF12 

I can't find 0xFF12 in the Assigned Numbers document here, https://www.bluetooth.com/specifications/assigned-numbers/ , so it's seems like they have not registered it with the Bluetooth SIG...

Try using this scan-filter:

    #define TARGET_UUID 0xFF12

ble_uuid_t uuid =
    {
        .uuid = TARGET_UUID,
        .type = BLE_UUID_TYPE_BLE,
    };

    err_code = nrf_ble_scan_filter_set(&m_scan,
                                       SCAN_UUID_FILTER,
                                       &uuid);
    APP_ERROR_CHECK(err_code);

And use e.g. ble_app_hrs_c as an template example on how to create a central that connects to a peripheral that have a 16-bit UUID service(BLE_UUID_TYPE_BLE).

[panypan]

Hi sigurd,

The service (0xFF12) cannot be found after modifying according to your suggestions. The attachment is the output log.

Best regards,

Pany

Fullscreen ble_app_hrs_c_0xFF12_log.txt Download

<info> app_timer: RTC: initialized.
<debug> nrf_ble_lesc: Initialized nrf_crypto.
<debug> nrf_ble_lesc: Initialized nrf_ble_lesc.
<debug> nrf_ble_lesc: Generating ECC key pair
<debug> ble_scan: Added filter on UUID FF12
<info> app: Heart Rate collector example started.
<info> app: Starting scan.
<debug> ble_scan: Scanning parameters have been changed successfully
<debug> ble_scan: Scanning
<debug> ble_scan: Connecting
<debug> ble_scan: Connection status: 0
<debug> nrf_ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x0.
<debug> nrf_ble_gatt: Updating data length to 251 on connection 0x0.
<info> app: Connected.
<debug> nrf_ble_gq: Registering connection handle: 0x0000
<debug> ble_db_disc: Starting discovery of service with UUID 0xFF12 on connection handle 0x0.
<debug> nrf_ble_gq: Adding item to the request queue
<debug> nrf_ble_gq: GATTC Primary Services Discovery Request
<debug> nrf_ble_gq: SD is currently busy. The GATT request procedure will be attempted                       again later.
<debug> nrf_ble_gq: Processing the request queue...
<debug> nrf_ble_gq: GATTC Primary Service Discovery Request
<debug> nrf_ble_gq: SD is currently busy. The GATT request procedure will be attempted                           again later.
<debug> nrf_ble_gq: Processing the request queue...
<debug> nrf_ble_gq: GATTC Primary Service Discovery Request
<debug> nrf_ble_gq: SD GATT procedure (2) succeeded on connection handle: 0.
<debug> nrf_ble_gatt: ATT MTU updated to 247 bytes on connection 0x0 (response).
<info> app: GATT ATT MTU on connection 0x0 changed to 247.
<debug> nrf_ble_gq: Processing the request queue...
<debug> nrf_ble_gatt: Peer on connection 0x0 requested an ATT MTU of 247 bytes.
<debug> nrf_ble_gatt: Updating ATT MTU to 247 bytes (desired: 247) on connection 0x0.
<info> app: GATT ATT MTU on connection 0x0 changed to 247.
<debug> nrf_ble_gatt: Data length updated to 251 on connection 0x0.
<debug> nrf_ble_gatt: max_rx_octets: 251
<debug> nrf_ble_gatt: max_tx_octets: 251
<debug> nrf_ble_gatt: max_rx_time: 2120
<debug> nrf_ble_gatt: max_tx_time: 2120
<info> app: Data length for connection 0x0 updated to 251.
<debug> nrf_ble_gq: Processing the request queue...
<debug> ble_db_disc: Service UUID 0xFF12 not found.
<debug> ble_db_disc: Starting discovery of service with UUID 0x180F on connection handle 0x0.
<debug> nrf_ble_gq: Adding item to the request queue
<debug> nrf_ble_gq: GATTC Primary Services Discovery Request
<debug> nrf_ble_gq: SD GATT procedure (2) succeeded on connection handle: 0.
<debug> nrf_ble_gq: Processing the request queue...
<debug> ble_db_disc: Service UUID 0x180F not found.
<debug> ble_bas_c: Battery Service discovery failure at peer. 
<debug> ble_bas_c: Battery Service discovery failure at peer. 
<info> app: Disconnected, reason 0x8.
<info> app: Starting scan.
<debug> ble_scan: Scanning

[Sigurd]

Hi,

Did you do any other changes? e.g. in ble_hrs_c.c ?

[panypan]

Hi,

Only change this: 

[Sigurd]

Try to change this:

uint32_t ble_hrs_c_init(ble_hrs_c_t * p_ble_hrs_c, ble_hrs_c_init_t * p_ble_hrs_c_init)
{
    VERIFY_PARAM_NOT_NULL(p_ble_hrs_c);
    VERIFY_PARAM_NOT_NULL(p_ble_hrs_c_init);

    ble_uuid_t hrs_uuid;

    hrs_uuid.type = BLE_UUID_TYPE_BLE;
    hrs_uuid.uuid = BLE_UUID_HEART_RATE_SERVICE;

    p_ble_hrs_c->evt_handler                 = p_ble_hrs_c_init->evt_handler;
    p_ble_hrs_c->error_handler               = p_ble_hrs_c_init->error_handler;
    p_ble_hrs_c->p_gatt_queue                = p_ble_hrs_c_init->p_gatt_queue;
    p_ble_hrs_c->conn_handle                 = BLE_CONN_HANDLE_INVALID;
    p_ble_hrs_c->peer_hrs_db.hrm_cccd_handle = BLE_GATT_HANDLE_INVALID;
    p_ble_hrs_c->peer_hrs_db.hrm_handle      = BLE_GATT_HANDLE_INVALID;

    return ble_db_discovery_evt_register(&hrs_uuid);
}

to this as well:

uint32_t ble_hrs_c_init(ble_hrs_c_t * p_ble_hrs_c, ble_hrs_c_init_t * p_ble_hrs_c_init)
{
    VERIFY_PARAM_NOT_NULL(p_ble_hrs_c);
    VERIFY_PARAM_NOT_NULL(p_ble_hrs_c_init);

    ble_uuid_t hrs_uuid;

    hrs_uuid.type = BLE_UUID_TYPE_BLE;
    hrs_uuid.uuid = 0xFF12;

    p_ble_hrs_c->evt_handler                 = p_ble_hrs_c_init->evt_handler;
    p_ble_hrs_c->error_handler               = p_ble_hrs_c_init->error_handler;
    p_ble_hrs_c->p_gatt_queue                = p_ble_hrs_c_init->p_gatt_queue;
    p_ble_hrs_c->conn_handle                 = BLE_CONN_HANDLE_INVALID;
    p_ble_hrs_c->peer_hrs_db.hrm_cccd_handle = BLE_GATT_HANDLE_INVALID;
    p_ble_hrs_c->peer_hrs_db.hrm_handle      = BLE_GATT_HANDLE_INVALID;

    return ble_db_discovery_evt_register(&hrs_uuid);
}

[panypan]

Hi Sigurd,

Sorry, I've changed this too.

In addition, a good news that the customer has solved this problem used ncs (modify base on : ncs\v2.0.0\nrf\samples\bluetooth\central_uart).

Thanks,

Pany

[Sigurd]

panypan said:

In addition, a good news that the customer has solved this problem used ncs (modify base on : ncs\v2.0.0\nrf\samples\bluetooth\central_uart).

Great!