How to read and write to a non nordic device which has its own BLE characterstics?

Hi, 

I have a device which has different UUID s for the write and read characteristics than the Nordic devices. The device I want to connect to will give out sensor data via one specific characteristic and I want my central read that data. What should I be referring to? Are there any examples which I can modify and get it working?

Thanks in advance.

  • Hi,

    I have looked into the nus and replicated the same using the custom UUID, but instead of BLE_DB_DISCOVERY_COMPLETE I get ble_db_discovery_srv_not_found.

    I am not able to figure out why.

    sd_ble_uuid_vs_add() is done in the init function.

      #define BLE_UUID_B24_CONFIGURATION_SERVICE                          0xFD30
      #define BLE_UUID_B24_CONF_PIN_CHARACTERISTIC                        0xFD39
      #define BLE_UUID_B24_VIEW_PIN_CHARACTERISTIC                        0xFD34
    
      //a970fd30-a0e8-11e6-bdf4-0800200c9a66
      #define B24_BASE_UUID {{0x66, 0x9a, 0x0c, 0x20, 0x00, 0x08, 0xf4, 0xbd, 0xe6, 0x11, 0xe8, 0xa0, 0x00, 0x00, 0x70, 0xa9}}

    B24 module has the UUID as

    All the Mantracourt services and characteristics have a common 96 bit tail and a variable 32 bit identifier. 00000000-a0e8-11e6-bdf4-0800200c9a66

    The following table shows the 32 bit identifier used to replace the 00000000 shown above to produce the full 128-bit UUID.
    a970fd30 - Configuration Profile Service

    The below code shows my init function.

    uint32_t ble_b24_init(ble_b24_t * p_ble_b24, ble_b24_init_t * p_ble_b24_init)
    {
        uint32_t      err_code;
        ble_uuid_t    b24_uuid;
        ble_uuid128_t b24_base_uuid = B24_BASE_UUID;
    
        VERIFY_PARAM_NOT_NULL(p_ble_b24);
        VERIFY_PARAM_NOT_NULL(p_ble_b24_init);
        VERIFY_PARAM_NOT_NULL(p_ble_b24_init->p_gatt_queue);
    
        err_code = sd_ble_uuid_vs_add(&b24_base_uuid, &p_ble_b24->uuid_type);
        VERIFY_SUCCESS(err_code);
    
        b24_uuid.type = p_ble_b24->uuid_type;
        b24_uuid.uuid = BLE_UUID_B24_CONFIGURATION_SERVICE;
    
        p_ble_b24->conn_handle           = BLE_CONN_HANDLE_INVALID;
        p_ble_b24->evt_handler           = p_ble_b24_init->evt_handler;
        p_ble_b24->error_handler         = p_ble_b24_init->error_handler;
        p_ble_b24->handles.b24_tx_handle = BLE_GATT_HANDLE_INVALID;
        p_ble_b24->handles.b24_rx_handle = BLE_GATT_HANDLE_INVALID;
        p_ble_b24->p_gatt_queue          = p_ble_b24_init->p_gatt_queue;
    
        return ble_db_discovery_evt_register(&b24_uuid);
    }

  • Hi,

    You describe a UUID consisting of a common 96-bit part of a0e8-11e6-bdf4-0800200c9a66 preceeded by a 32 bit part of a970fd30, yielding the full UUID a970fd30-a0e8-11e6-bdf4-0800200c9a66.

    For handling by the SoftDevice, UUIDs consist of a "base UUID" of the pattern BBBBxxxx-BBBB-BBBB-BBBB-BBBBBBBBBBBB, where the B's are the values of the base UUID, and the x's mark where the final 16 bits are inserted to form a full 128 bit UUID.

    In order to access the full UUID of the Mantracourt service, you therefore must register a base UUID of a9700000-a0e8-11e6-bdf4-0800200c9a66, which will become a UUID type, and then combine that UUID type with the 16 remaining bits of fd30.

    This is, as far as I can tell, exactly what you are doing, and I would have expected this to work.

    Can you capture a sniffer trace of this, to see what is happening over the air?

    Regards,
    Terje

  • Hi, 

    I dont have a DK, I tried using the Fanstel EVBM833 as a sniffer. But it didnt work out.

    Any other suggestions that I can try?

  • Hi,

    If you haven't already, you should have a look at the nRF Connect app (available for iOS and Android.)

    With it, you can have a thorough look at the advertisements, services, characteristics, etc. and interact with the device which you are trying to connect to. You can also set up a custom advertiser, copying the device you want to connect to, and/or use it for checking if you are able to connect to a custom device that you fully control.

    There may be something happening on the remote device, which you are not in control of, which terminates the connection or prevents connection in the first place. What do you see from your central, is it connecting, is it disconnecting, do you get any error messages or other indication of what fails?

    Regards,
    Terje

  • Hi, 

    I have made some progress now. I am able to discover 6 of the characteristics. But the one which I need to modify is the 8th one in the list. 

    The Configuration Pin is the characteristic which need to be written into in  order to stay connected with the device. And if this doesn't happen in 5 seconds, the device automatically disconnects from the central.

    <info> app_timer: RTC: initialized.
    <info> app: BLE UART central example started.
    <info> app: Name filter match
    <info> app: Connecting to target 386F888402EA
    <info> app: ATT MTU exchange completed.
    <info> app: Ble NUS max data length set to 0x14(20)
    <info> app: BLE_UUID_B24_Data_Rate_Characteristic detected
    <info> app: BLE_UUID_B24_Resolution detected
    <info> app: BLE_UUID_B24_Battery_Threshold detected
    <info> app: BLE_UUID_B24_View_PIN detected
    <info> app: BLE_UUID_B24_Serial_Number detected
    <info> app: BLE_UUID_B24_Data_Tag detected
    <info> app: Disconnected. conn_handle: 0x0, reason: 0x5

    Is there any faster way that I can do a DB discovery that all of my chars get listed?

    And after a filter match, it takes around 20 seconds to get connected, where is this time being spent?

    After the Disconnection the code abruptly hangs somewhere, which I am not able to figure out.

Related