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.

Parents Reply Children
  • Hi

    Do you know the which service/profile the device is running? If not I would look into using the BLE shell and the GATT https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/connectivity/bluetooth/bluetooth-shell.html#gatt 

    Regards

    Runar

  • Then i would take a look at this module

    Regards

    Runar

  • 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

Related