ble_thread_dyn_mtd_coap_cli ERROR 19 / 0x13

[ToasTer86]

Hey dear Devzone,

I am trying out some Thread and BLE dynamical examples on my nRF52840's but running into some problems using the " ble_thread_dyn_mtd_coap_cli " example. All boards are running the soft device added with the Thread_SDK. Specifically the one found in : /components/softdevice/s140/hex/s140_nrf52840_5.0.0-2.alpha_softdevice.hex.

Currently I have 2 CoAP servers, 1 CoAP client all which are running without dynamic protocol. Then I have 1 running the ble_thread_dyn_mtd_coap_cli dynamic example.

The dynamic device gets added to the mesh network as a End Device: role 2. Once I connect to that board using the nRF toolbox (newest version downloaded from PlayStore) I get the following error and message in the debug terminal :

<error> ble_gatt: sd_ble_gap_data_length_update() (request) on connection 0x0 returned unexpected value 0x13.
<info> app: Connected
<info> app: Data len is set to 0x3D(61)
<error> app: ERROR 19 [Unknown error code]

I can retrace it back to this event on the BLE_EVT_HANDLER :

 case BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST:
{
    ble_gap_data_length_params_t dl_params;

    // Clearing the struct will effectivly set members to @ref BLE_GAP_DATA_LENGTH_AUTO
    memset(&dl_params, 0, sizeof(ble_gap_data_length_params_t));
    err_code = sd_ble_gap_data_length_update(p_ble_evt->evt.gap_evt.conn_handle, &dl_params, NULL);
    APP_ERROR_CHECK(err_code);
} break;

For now I have not been able to get BLE + Thread running concurrently with the "ble_thread_dyn_mtd_coap_cli" example.

Can someone help me with this?

Some other random things I have tried: But while using the "ble_thread_dyn_template" example I have been able to have success. I can change the device name for example.

[Lukasz Duda]

Hello,

Thank you for raising this issue.

Can you try to remove the entire case (BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST) from ble_evt_handler?

We will investigate this issue but it looks like some mobile phones act differently to others when it comes to data length negotiations.

[Lukasz Duda]

Unfortunately we don't have any measurements for this moment, i think that some examples will be available in subsequent nRF5 SDK for Thread.

Your settings indicates that scan window is set to 50ms and scan interval to 100ms. It depends of the use case, but this means that you will block Thread transmission for approx. 50ms. I would consider to make this value as small as possible e.g. set it to 2.5-10ms, and scan interval to e.g. 50ms (or 53ms to try rule out scenario when advertising packet is synchronized with the inactive time on BLE).

In that case there will be higher probability that 802.15.4 frame (e.g. by retransmissions) reaches the node.