Connecting to peripheral BLE device using BMD 350 (nrf52 based chip) as central BLE device.

I have been able to connect and initialize two different Bluetooth OBD II Devices. I am running into issues with the third device I am trying to add as an option. I add the Primary Services in the code below.

 

I add filters to find the devices by name. After I connect to the found device, I start the database discovery. 

The following snippet shows my code for my database discovery event. 

For the LE Link and VLINK devices, the event type is BLE_DB_DISCOVERY_COMPLETE and gets their service uuids that contain the tx and rx characteristics. The issue is with the FIXD device. The output says "<info> ble_obd_c: Service Not Found, UUID: 0xFFF0" yet this is the service I am looking for. The event type says "BLE_DB_DISCOVERY_SRV_NOT_FOUND" yet the uuid is equal to the BLE_UUID_FIXD_SERVICE (which is 0xFFF0). I have attached the attribute table from the nRF52 connect app which connects to the FIXD Device fine. 

I also have wireshark logs of a OBD II phone app connecting to the device and what the nRF52 does when trying to connect if that helps at all as well. This was all developed using nRF52 sdk 17.0.2.

4073.VLINK to iOS Capture from connecting.pcapngVLINK to nRF52 Capture from connecting.pcapng

Parents
  • Hi Matt,

    I can see that you are using nRF5SDK. Your discovery is failing because the FIXD device's service UUID 0xFFF0 is not a standard 16-I think your BLE UUID, it's a 128-bit vendor-specific UUID, even though it appears as 0xFFF0 in nRF Connect.

    You registered it as a 16-bit UUID which you should do if the UUID is a BLE standard UUID of type BLE_UUID_TYPE_BLE .

    The screenshot in the nrf connect app confirms this as it seems 0XFFF0 as unknown service

    In your code you have this check

    This check fails before BLE_UUID_TYPE_BLE != BLE_UUID_TYPE_VENDOR_BEGIN + X

    You need to add a full 128 bit UUID for your FIXD service/Device something like this

    See that 0XFFF0 is represented in your base UUID in the little endian format.

    Register this to the softdevice uuid database

    You clearly need to have your uuid.type updated so that your compare in the discovery callback is comparing the right things.

    This should work now

Reply
  • Hi Matt,

    I can see that you are using nRF5SDK. Your discovery is failing because the FIXD device's service UUID 0xFFF0 is not a standard 16-I think your BLE UUID, it's a 128-bit vendor-specific UUID, even though it appears as 0xFFF0 in nRF Connect.

    You registered it as a 16-bit UUID which you should do if the UUID is a BLE standard UUID of type BLE_UUID_TYPE_BLE .

    The screenshot in the nrf connect app confirms this as it seems 0XFFF0 as unknown service

    In your code you have this check

    This check fails before BLE_UUID_TYPE_BLE != BLE_UUID_TYPE_VENDOR_BEGIN + X

    You need to add a full 128 bit UUID for your FIXD service/Device something like this

    See that 0XFFF0 is represented in your base UUID in the little endian format.

    Register this to the softdevice uuid database

    You clearly need to have your uuid.type updated so that your compare in the discovery callback is comparing the right things.

    This should work now

Children
  •   

    I have added the following code to add the uuid. 

    But after adding the uuid, the uuid type is 0x04 instead of 0x02. I cannot find anywhere that says what 0x04 for uuid type would mean after registering it? It should be 0x02 if it is vendor specific correct?

    EDIT: I see in the documentation, after each call it increments the uuid type by one. I call for ble_nus and dfu so 4 makes sense since this is the third call. 

    But I am still getting the service not found in the discovery event callback.