Sending commands from nRF52 acting as central to peripheral OBD II BLE Device

RE: Sending commands from nRF52 acting as central to peripheral OBD II BLE Device

Edvin — Wed, 18 Sep 2024 10:26:36 GMT

yes, but it is not a vendor specific UUID (if it is only 16 bit long). So you can look at the ble_hrs_c_init() function for reference:

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);
}

As you can see, it is mostly the same, but you don't need the sd_ble_uuid_vs_add() (softdevice_bluetooth low energy_uuid_vendor specific_add())

Vendor specific refers to 128-bit UUIDs, as the are specified by the vendor. 16 bit uuids are "standard" UUIDs. Look at the ble_app_hrs_c example for reference.

BR,
Edvin

RE: Sending commands from nRF52 acting as central to peripheral OBD II BLE Device

inspiringdev123 — Tue, 17 Sep 2024 16:16:48 GMT

So do I need to add the service UUID here?

uint32_t ble_obd_c_init(ble_obd_c_t * p_ble_obd_c, ble_obd_c_init_t * p_ble_obd_c_init)
{
    uint32_t      err_code;
    ble_uuid_t    obd_uuid;
    ble_uuid128_t obd_base_uuid = OBD_BASE_UUID;

    VERIFY_PARAM_NOT_NULL(p_ble_obd_c);
    VERIFY_PARAM_NOT_NULL(p_ble_obd_c_init);
    VERIFY_PARAM_NOT_NULL(p_ble_obd_c_init->p_gatt_queue);

    err_code = sd_ble_uuid_vs_add(&obd_base_uuid, &p_ble_obd_c->uuid_type);
    VERIFY_SUCCESS(err_code);

    obd_uuid.type = p_ble_obd_c->uuid_type;
    obd_uuid.uuid = BLE_UUID_OBD_SERVICE;

    p_ble_obd_c->conn_handle           = BLE_CONN_HANDLE_INVALID;
    p_ble_obd_c->evt_handler           = p_ble_obd_c_init->evt_handler;
    p_ble_obd_c->error_handler         = p_ble_obd_c_init->error_handler;
    p_ble_obd_c->handles.obd_tx_handle = BLE_GATT_HANDLE_INVALID;
    p_ble_obd_c->handles.obd_rx_handle = BLE_GATT_HANDLE_INVALID;
    p_ble_obd_c->p_gatt_queue          = p_ble_obd_c_init->p_gatt_queue;

    return ble_db_discovery_evt_register(&obd_uuid);
}

I have the base UUID, service UUID and characteristic defined as follows:

#define BASE_UUID {0xFB, 0x34, 0x9B, 0x5F, 0x80, 0x00, 0x00, 0x80, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}

#define BLE_UUID_OBD_SERVICE 0xFFE0 /**< The UUID of the OBD Service. */
#define BLE_UUID_OBD_CHARACTERISTIC 0xFFE1 /**< The UUID of the RX and TX Characteristic. */

RE: Sending commands from nRF52 acting as central to peripheral OBD II BLE Device

Edvin — Tue, 17 Sep 2024 12:13:30 GMT

Strange. It looks like it uses a short UUID (16 bit), but it is not registered with Bluetooth:

https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Assigned_Numbers/out/en/Assigned_Numbers.pdf?v=1726574177481

(page 76)

Perhaps it is possible to purchase a 16-bit UUID and not publish it's use. I don't remember.

But yes, it looks like the service you are looking for is 0xFFE0, and the characteristics are 0xFFE1 and 0xFFEE. In this case, when it is a 16 bit UUID, I suggest you look into the ble_app_hrs_c example, as this uses a 16 bit UUID.

I can't tell from your screenshot, but it looks like the 0xFFE1 is a characteristic on which you would want to enable notifications, and the 0xFFEE is probably one you would want to write to (the arrows in the app will tell you).

However, on what format the OBDBLE device expects it's data, I don't know. You will have to check with the producer of this device.

But your steps should be: Look at the ble_app_hrs_c example on how to do discovery on a 16 bit (short) UUID. Then you can look at the ble_app_uart_c example for how to enable notifications, and write to a characteristic. I suspect it is quite similar to the ble_app_uart/ble_app_uart_c application, apart from the 16-bit UUID.

Best regards,

Edvin

RE: Sending commands from nRF52 acting as central to peripheral OBD II BLE Device

inspiringdev123 — Mon, 16 Sep 2024 15:50:52 GMT

So basically, I should start here and edit the UUID to use my custom UUID's I am looking for?

uint32_t ble_nus_c_init(ble_nus_c_t * p_ble_nus_c, ble_nus_c_init_t * p_ble_nus_c_init)
{
    uint32_t      err_code;
    ble_uuid_t    uart_uuid;
    ble_uuid128_t nus_base_uuid = NUS_BASE_UUID;

    VERIFY_PARAM_NOT_NULL(p_ble_nus_c);
    VERIFY_PARAM_NOT_NULL(p_ble_nus_c_init);
    VERIFY_PARAM_NOT_NULL(p_ble_nus_c_init->p_gatt_queue);

    err_code = sd_ble_uuid_vs_add(&nus_base_uuid, &p_ble_nus_c->uuid_type);
    VERIFY_SUCCESS(err_code);

    uart_uuid.type = p_ble_nus_c->uuid_type;
    uart_uuid.uuid = BLE_UUID_NUS_SERVICE;

    p_ble_nus_c->conn_handle           = BLE_CONN_HANDLE_INVALID;
    p_ble_nus_c->evt_handler           = p_ble_nus_c_init->evt_handler;
    p_ble_nus_c->error_handler         = p_ble_nus_c_init->error_handler;
    p_ble_nus_c->handles.nus_tx_handle = BLE_GATT_HANDLE_INVALID;
    p_ble_nus_c->handles.nus_rx_handle = BLE_GATT_HANDLE_INVALID;
    p_ble_nus_c->p_gatt_queue          = p_ble_nus_c_init->p_gatt_queue;

    return ble_db_discovery_evt_register(&uart_uuid);
}

I scanned for the device on the nrf connect app and this is what I got.

The service I am interested in is the FFE0 and the characteristic used to read and write is FFE1

RE: Sending commands from nRF52 acting as central to peripheral OBD II BLE Device

Edvin — Fri, 13 Sep 2024 13:11:32 GMT

Hello,

Do you have any information indicating that the OBD II uses the Nordic UART Service (NUS)?

Also, the API that you are pointing to, bt_nus_data_send() is the API intended for the peripheral, not the central. For a central_uart application, you should use:

bt_nus_client_send()

like it is done in the central_uart sample application (ncs\nrf\samples\bluetooth\central_uart).

So the reason it fails using bt_nus_data_send() is that it assumes that the connected device has enabled notifications to the nRF's Nordic UART service, which is not the case. Typically central's don't have services and characteristics that the peripheral will enable notifications on (subscribe to).

So if you want to connect to, and use the OBD II device over BLE, you need to connect to it using e.g. nRF Connect for Desktop -> Bluetooth Low Energy, and look at what Services and Characteristics it has. Then you need to implement a central application (like the central_uart application) that uses those services and characteristics. You can look at the central_uart sample to see how it does service discovery, and how it uses the characteristics that is present in the peripheral_uart sample, and apply this to the services and characteristics that you find on your OBD II.

Best regards,

Edvin