This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Problems with adding openthread to gcc BLE project

Hi,

I'm trying to add Openthread support to my project, which is based on ATT_MTU_Throughput example. I followed the tutorial in infocenter, but I still have some problems in linking stage:

image description

Thanks from advance for your help.

Parents
  • One side advice for extending ATT_MTU example with Thread protocol.

    In the dynamic multiprotocol solution, the Timeslot API is used to achieve radio concurrency.

    Softdevice always gives higher priority to BLE operations over Thread operations. ATT_MTU throughput example is designed to utilize the whole radio time usage between two connection intervals (of course only during the test).

    Because of that Thread protocol will ungracefully try to get access to RADIO peripheral. In order to change this behaviour, you need to adjust two parameters in the ATT_MTU example to reduce the RADIO time usage on BLE from 100% to e.g. 25% (to give around 75% for Thread):

    • The event length and the connection interval are the primary parameters for setting the throughput of a connection. You need to change the first by reducing NRF_SDH_BLE_GAP_EVENT_LENGTH value in sdk_config.h from 320 (400ms) to smaller value e.g. 25% of connection interval (for connection interval of 400ms please use value of 80 (100ms)). This will effectively give around 300ms (75%) for Thread operations in between of BLE operations (but it will also reduce BLE throughput).

    • Turn off BLE_COMMON_OPT_CONN_EVT_EXT extension, please change conn_evt_len_ext_enabled parameter to false in the line number 155 of main.c:

        .conn_evt_len_ext_enabled = false
      

      If this event extension option is enabled it will dynamically extend the event length when possible and so overwrite the value of NRF_SDH_BLE_GAP_EVENT_LENGTH.

    In order to read more about event length and dynamic event length extension please follow infocenter documentation: infocenter.nordicsemi.com/index.jsp

    In all our current examples Thread has around 95%+ of radio time, since BLE applications send small amout of data and the examples don't require special BLE parameters tunning. It is possible to design application that transfer large portion of data over Bluetooth LE with maximum throughput, however this operation should be as short as possible to allow Thread protocol to access the radio (eventually put Thread device into sleep mode - see SED example).

    We will make sure to add description of effective BLE radio usage time and its configuration running concurrently with Thread, in the next nRF5 for Thread releases.

Reply
  • One side advice for extending ATT_MTU example with Thread protocol.

    In the dynamic multiprotocol solution, the Timeslot API is used to achieve radio concurrency.

    Softdevice always gives higher priority to BLE operations over Thread operations. ATT_MTU throughput example is designed to utilize the whole radio time usage between two connection intervals (of course only during the test).

    Because of that Thread protocol will ungracefully try to get access to RADIO peripheral. In order to change this behaviour, you need to adjust two parameters in the ATT_MTU example to reduce the RADIO time usage on BLE from 100% to e.g. 25% (to give around 75% for Thread):

    • The event length and the connection interval are the primary parameters for setting the throughput of a connection. You need to change the first by reducing NRF_SDH_BLE_GAP_EVENT_LENGTH value in sdk_config.h from 320 (400ms) to smaller value e.g. 25% of connection interval (for connection interval of 400ms please use value of 80 (100ms)). This will effectively give around 300ms (75%) for Thread operations in between of BLE operations (but it will also reduce BLE throughput).

    • Turn off BLE_COMMON_OPT_CONN_EVT_EXT extension, please change conn_evt_len_ext_enabled parameter to false in the line number 155 of main.c:

        .conn_evt_len_ext_enabled = false
      

      If this event extension option is enabled it will dynamically extend the event length when possible and so overwrite the value of NRF_SDH_BLE_GAP_EVENT_LENGTH.

    In order to read more about event length and dynamic event length extension please follow infocenter documentation: infocenter.nordicsemi.com/index.jsp

    In all our current examples Thread has around 95%+ of radio time, since BLE applications send small amout of data and the examples don't require special BLE parameters tunning. It is possible to design application that transfer large portion of data over Bluetooth LE with maximum throughput, however this operation should be as short as possible to allow Thread protocol to access the radio (eventually put Thread device into sleep mode - see SED example).

    We will make sure to add description of effective BLE radio usage time and its configuration running concurrently with Thread, in the next nRF5 for Thread releases.

Children
No Data
Related