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.

[ToasTer86]

Hey Lukasz,

Thanks for your quick reponse. That seemed to have worked, it's a nice and dirty fix ;-). I can now control the LEDS on my CoAP servers from my mobile phone.

Thanks a lot

ps I will create a another thread related question tomorrow involving using the nRF52840 as a BLE central concurrently with Thread. Seems that my parent requests from my BLE central+Thread board are not responded to. But I have to make some captures from that using the Thread Sniffer.

[Lukasz Duda]

Great to hear that example works for you.

BLE part from our application is based on the ble_app_uart from the regular SDK. We haven't noticed this issue, probably it depends on mobile phone firmware.

I think you can look at this topic, to see how to fix the issue without removing the BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST case: devzone.nordicsemi.com/.../

We will inform our BLE SDK team about it, thank you!

P.S. Unfortunately for now, we have no official support for BLE Central + Thread. However it should be possible to run it, if only scanning does not completely occupies the radio.

[ToasTer86]

To make sure scanning does not occupy the whole radio should I add a timeout for that ? Could you give a estimation about how I should set the scanning variables?

These are the values I have set it to now:

#define SCAN_INTERVAL             0x00A0                                /**< Determines scan interval in units of 0.625 millisecond. */
#define SCAN_WINDOW               0x0050                                /**< Determines scan window in units of 0.625 millisecond. */
#define SCAN_TIMEOUT              0x0000                               /**< Timeout when scanning. 0x0000 disables timeout. */

[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.