Connecting nRF52832 to OBDII using NUS (Issue: Receiving a response from OBDII)

[HMD]

Hi everyone, I'm trying to communicate with OBDII through NUS using nRF52832. I was able to initiate the connection, send commands to OBDII, and get responses on the ECUsim 2000. However, I wasn't able to get the responses sent back to nRF52832 through bluetooth.

I used the centeral ble_app_uart_c example from the SDK.

The OBDII NUS UUID is 0x0000FFF0-0000-1000-8000-00805F9B34FB

#define NUS_BASE_UUID {{0xFB, 0x34, 0x9B, 0x5F, 0x80, 0x00, 0x00, 0x80, 0x00, 0x10, 0x00, 0x00, 0xEF, 0xFF, 0x00, 0x00}}
#define BLE_UUID_NUS_SERVICE 0xFFF0
#define BLE_UUID_NUS_RX_CHARACTERISTIC 0XFFF2 
#define BLE_UUID_NUS_TX_CHARACTERISTIC 0xFFF1 

For the UUID Type I used:

#define NUS_SERVICE_UUID_TYPE   BLE_UUID_TYPE_BLE

After I send commands from nRF32 to OBDII, I get the expected results on ECUsim 2000. However, these results are not sent back to nRF32!

while debugging the code, I found that IF statement of the on_hvx function (ble_nus_c.c)  is never met (always treated as FALSE), and I'm not sure why is this happening.

static void on_hvx(ble_nus_c_t * p_ble_nus_c, ble_evt_t const * p_ble_evt)
{
      // HVX can only occur from client sending.
      if ( (p_ble_nus_c->handles.nus_tx_handle != BLE_GATT_HANDLE_INVALID)
      && (p_ble_evt->evt.gattc_evt.params.hvx.handle != p_ble_nus_c->handles.nus_tx_handle)
      && (p_ble_nus_c->evt_handler != NULL))
      {
              ble_nus_c_evt_t ble_nus_c_evt;

              ble_nus_c_evt.evt_type = BLE_NUS_C_EVT_NUS_TX_EVT;
              ble_nus_c_evt.p_data = (uint8_t *)p_ble_evt->evt.gattc_evt.params.hvx.data;
              ble_nus_c_evt.data_len = p_ble_evt->evt.gattc_evt.params.hvx.len;

              p_ble_nus_c->evt_handler(p_ble_nus_c, &ble_nus_c_evt);
              printf("Client sending data.");
      }
}

Could you please help me solve this issue to get the results sent back to nRF32 through bluetooth?

[Einar Thorsrud]

If the peripheral (OBDII device) use a 16 bit UUID for the service then you essentially do the same thing, you still need to add the base UUID and refer to it for the characteristics, but the service UUID is set without a base. I suggest you refer to ble_dfu_buttonless_init() in components\ble\ble_services\ble_dfu\ble_dfu.c for an example of that.

[HMD]

Thanks for the reply Einar!

I tried to test the code with another nRF device with 128-bit UUID and it's working. Then I changed the UUID type of the peripheral to 16-bit, and updated the UUID type in the central code, it worked as well.

However, for the OBDII it keeps saying that 0xFFF0 Service UUID not found.

it's still not clear for me why I'm getting this error. I will summarise the issue down hopefully you or others can guide me through how to overcome it.

Goal: Communicating with OBD through NUS (UART over BLE).

Hardware: nRF52832 ß à OBDII (connected car simulator ECUsim2000)

Software: ble_app_uart_c from nRF5_SDK_17.1.0

 

• Succeeded in initiating the connection between the two devices.
• Able to send commands from nRF to OBDII through NUS.
  • Monitored the OBDII traffic using USB connected to ECUsim2000, proved that commands are received by OBDII and results are as expected.

 

ISSUE:

Not able to receive OBDII results back in nRF (due to nRF not being able to discover OBDII service)

After debugging the software, and testing it with another BLE device (software is working with both 128bit UUIDs and 16bit UUIDs)

 

Used Base UUID: {{0xFB, 0x34, 0x9B, 0x5F, 0x80, 0x00, 0x00, 0x80, 0x00, 0x10, 0x00, 0x00, 0xEF, 0xFF, 0x00, 0x00}}

              Also tried: {{0xFB, 0x34, 0x9B, 0x5F, 0x80, 0x00, 0x00, 0x80, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}}

Used Service UUID: 0xFFF0

Used TX and RX UUIDS: 0xFFF1 and 0xFFF2 (tried flipping them)

Used 16-bit UUID Type

 

• The device finds the OBDII, connect with it, and can send commands to it. However, it’s not receiving the OBDII results back in the device due to the “OBDII FFF0 service not found”.

Any help is appreciated. Thanks!

[Einar Thorsrud]

Hi,

Do you by any chance have contact with those who made the OBDII device and can ask them about it's implementation? If you are just making assumptions that could perhaps be a good idea. alternatively, do you have access to some other device that already can communicate with it? If so, sniffing the communication could be useful in order to understand how you can communicate with it.