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

Example project for Mesh Instaburst

Hi,

We managed to integrate both normal BLE and mesh stack onto our working prototype, powered by nRF52840. So far, it is working well. We are trying to further maximise our developed node by experimenting mesh Instaburst feature, as our TX mesh packet is around 48 - 132 bytes.

Before we get a head start, just wondering if there is any example project/template we can refer to? With this, at least we know how to use this feature properly.

Many thanks!

Parents
  • Hi Siew, 
    We currently don't have an example with Instabrust however as far as I know you don't need to change anything except for using compiling option: EXPERIMENTAL_INSTABURST_ENABLED  when you compile with cmake, as described here.
    The use of Instabrust is executed under the hood and transparent to the application. 

  • Hi Hung Bui,

    Thanks Hung for your quick reply. But the link seems to not working anymore. Can you kindly recheck it?

    Many thanks!

  • Thanks Hung Bui,

    I will have a look and get back to you with my development status.

    Thank you very much!

  • Have been trying to debug other bits and only managed to come back to this weeks ago. But getting nowhere.

    I am keep getting this error message when trying to build with cMake. Tried using the cmake-gui and the command line tool and I got the same errors.

    Any idea?

    Configuring CMake for nRF5 SDK for Bluetooth Mesh 4.2.0
    CMake Warning at CMake/FindSDK.cmake:24 (message):
      Could not find `patch` executable.  Automatic patching of the nRF5 SDK not
      supported.  See for diff to apply.
    Call Stack (most recent call first):
      CMakeLists.txt:49 (include)
    
    
    CMake Warning at CMake/FindSDK.cmake:56 (message):
      
    
        Could not find the nRF5 SDK. The build will fail.
        Please run the nRF5_SDK target to download it or provide the correct path
        using the -DSDK_ROOT option or setting the SDK_ROOT environment variable.
        After the download is complete, re-run `cmake`.
    
    Call Stack (most recent call first):
      CMakeLists.txt:49 (include)
    
    
    Configuring done

  • Hi Siew,

    As you can find in the log, the SDK_ROOT is missing, you would need to call cmake with the -DSDK_ROOT something like this: 

    cmake -GNinja -DSDK_ROOT=C:/NordicSDK/SDKv17/

    The path is the path to the nRF5 SDK, not the mesh SDK. Please download the matching version of the nRF5 SDK to the Mesh SDK that you are using. 
    Have you tried compiling with Segger Embedded Studio as well ? 

  • Thanks Hung Bui,

    I have tried to place both nRFSDK and mesh SDK in the same directory as suggested in the Getting Started guide. Here is the screenshot of the directory.

    And I had tried to add the SDK_ROOT while running the cmake. But still getting the same error:

    D:\NordicSDK\nRF5_SDK_for_mesh_4.2.0\build>cmake -GNinja -DSDK_ROOT=C:/NordicSDK/ ..
    -- Configuring CMake for nRF5 SDK for Bluetooth Mesh 4.2.0
    CMake Warning at CMake/FindSDK.cmake:24 (message):
      Could not find `patch` executable.  Automatic patching of the nRF5 SDK not
      supported.  See for diff to apply.
    Call Stack (most recent call first):
      CMakeLists.txt:50 (include)
    
    
    CMake Warning at CMake/FindSDK.cmake:56 (message):
    
    
        Could not find the nRF5 SDK. The build will fail.
        Please run the nRF5_SDK target to download it or provide the correct path
        using the -DSDK_ROOT option or setting the SDK_ROOT environment variable.
        After the download is complete, re-run `cmake`.
    
    Call Stack (most recent call first):
      CMakeLists.txt:50 (include)
    
    
    -- Configuring done
    -- Generating done
    -- Build files have been written to: D:/NordicSDK/nRF5_SDK_for_mesh_4.2.0/build
    
    D:\NordicSDK\nRF5_SDK_for_mesh_4.2.0\build>

    I am using:

    • nRF5_SDK_16.0.0_98a08e2
    • nRF5_SDK_for_mesh_4.2.0

    As we have been developing the our mesh application since last year.

    Also, when you mention whether I have tried to compile using SES, do you mean whether I have added the INSTABURST pre-compile definitives in the project setting?

    Any suggestion will be much appreciated. Many thanks!

  • Hi Siew,

    Please try cmake -GNinja -DSDK_ROOT=C:/NordicSDK/nrf5_SDK_16.0.0_98a08e2/ ..

    You need to point to the nRF5SDK not just the parent folder. 

    If you want to compile using SES, please do the following: 

    Define EXPERIMENTAL_INSTABURST_ENABLED = 1 in the preprocessor definition, or edit nrf_mesh_config_bearer.h to have EXPERIMENTAL_INSTABURST_ENABLED = 1. 

    Remove core_tx_adv.c and add core_tx_instaburst.c located in mesh\core folder

    Add the following in mesh\bearer\src: 


    instaburst.c
    instaburst_rx.c
    instaburst_tx.c
    adv_ext_tx.c
    adv_ext_packet.c

Reply
  • Hi Siew,

    Please try cmake -GNinja -DSDK_ROOT=C:/NordicSDK/nrf5_SDK_16.0.0_98a08e2/ ..

    You need to point to the nRF5SDK not just the parent folder. 

    If you want to compile using SES, please do the following: 

    Define EXPERIMENTAL_INSTABURST_ENABLED = 1 in the preprocessor definition, or edit nrf_mesh_config_bearer.h to have EXPERIMENTAL_INSTABURST_ENABLED = 1. 

    Remove core_tx_adv.c and add core_tx_instaburst.c located in mesh\core folder

    Add the following in mesh\bearer\src: 


    instaburst.c
    instaburst_rx.c
    instaburst_tx.c
    adv_ext_tx.c
    adv_ext_packet.c

Children
  • Hi Hung Bui,

    For some reason, I still cannot build the project using the input argument -DSDK_ROOT=C:/NordicSDK/nrf5_SDK_16.0.0_98a08e2/ ..

    But I managed to compile the Instaburst manually through SES as suggested. Since we already have our own source codes and headers, I think this is the better way to proceed forward. Many thanks!

    However, after enabling the Instaburst feature on both server and client sides (We have been using light switch server and client as our base templates), the transmission is still limited to around 11 bytes per packets due to the segmentation check inside transport_metadata_from_tx_params in transport.c:

    static void transport_metadata_from_tx_params(transport_packet_metadata_t * p_metadata,
                                                  const nrf_mesh_tx_params_t * p_tx_params)
    {
        p_metadata->type.access.app_key_id = p_tx_params->security_material.p_app->aid;
        p_metadata->type.access.using_app_key = (!p_tx_params->security_material.p_app->is_device_key);
        p_metadata->p_security_material = p_tx_params->security_material.p_app;
    
        /* Messages should be segmented if:
         * - They won't fit in an unsegmented message.
         * - The user explicitly requested it.
         * - The user forced a large MIC size.
         */
        p_metadata->segmented = ((p_tx_params->data_len > NRF_MESH_UNSEG_PAYLOAD_SIZE_MAX) ||
                                 p_tx_params->force_segmented ||
                                 p_tx_params->transmic_size == NRF_MESH_TRANSMIC_SIZE_LARGE);
    
        if (p_metadata->segmented)
        {
            p_metadata->mic_size =
                mic_size_get((p_tx_params->transmic_size == NRF_MESH_TRANSMIC_SIZE_DEFAULT)
                                 ? m_trs_config.szmic
                                 : p_tx_params->transmic_size);
    
            uint32_t num_segments = ((p_tx_params->data_len + p_metadata->mic_size +
                                      PACKET_MESH_TRS_SEG_ACCESS_PDU_MAX_SIZE - 1) /
                                     PACKET_MESH_TRS_SEG_ACCESS_PDU_MAX_SIZE);
            p_metadata->segmentation.last_segment = num_segments - 1;
            p_metadata->segmentation.segment_offset = 0;
        }
        else
        {
            p_metadata->mic_size = PACKET_MESH_TRS_TRANSMIC_SMALL_SIZE;
        }
    
        p_metadata->net.control_packet = false;
        p_metadata->net.dst = p_tx_params->dst;
        p_metadata->net.p_security_material = p_tx_params->security_material.p_net;
        p_metadata->net.src = p_tx_params->src;
        p_metadata->net.ttl = p_tx_params->ttl;
        p_metadata->token = p_tx_params->tx_token;
        p_metadata->tx_bearer_selector = CORE_TX_BEARER_TYPE_ALLOW_ALL ^ CORE_TX_BEARER_TYPE_LOCAL;
    
        if (nrf_mesh_is_address_rx(&p_tx_params->dst))
        {
            p_metadata->tx_bearer_selector = (p_tx_params->dst.type != NRF_MESH_ADDRESS_TYPE_UNICAST) ?
                    CORE_TX_BEARER_TYPE_ALLOW_ALL : CORE_TX_BEARER_TYPE_LOCAL;
        }
    
    #if MESH_FEATURE_FRIEND_ENABLED
        if (friend_needs_packet(p_metadata))
        {
            if (p_metadata->net.dst.type == NRF_MESH_ADDRESS_TYPE_UNICAST)
            {
                p_metadata->tx_bearer_selector = CORE_TX_BEARER_TYPE_LOCAL;
            }
            else
            {
                p_metadata->tx_bearer_selector |= CORE_TX_BEARER_TYPE_LOCAL;
            }
        }
    #endif
    }

    As far as I understand, Instaburst will have a payload of around 498 raw data bytes per packet. But this function has limited its payload and will always split the data into segmented packets before transmission.

    To tackle this, I tried to change the value for:

    • nrf_mesh_defines.h - NRF_MESH_UNSEG_PAYLOAD_SIZE_MAX
    • packet_mesh.h - PACKET_MESH_TRS_UNSEG_ACCESS_PDU_MAX_SIZE

    to match my desired mesh packet payload. However, the device will give me an app_error_weak error while in the progress of sending the mesh message.

    So I am wondering, do we still need to make any changes to increase the payload for the Instaburst feature?


    Addition information:

    For my customised mesh packet, I have tweaked several values for mesh message structure and payload related definitions:

    generic_onoff_common.h:

    typedef struct
    {
        uint8_t tid;
        uint8_t packets[100];
    } generic_onoff_set_params_t;

    generic_onoff_mesages.h:

    #define GENERIC_ONOFF_SET_MINLEN 100
    #define GENERIC_ONOFF_SET_MAXLEN 103
    
    /*
    Other code
    */
    
    typedef struct __attribute((packed))
    {
        uint8_t packets[100];
        uint8_t tid;                                            /**< Transaction number for application */
        uint8_t transition_time;                                /**< Encoded transition time value */
        uint8_t delay;                                          /**< Encoded message execution delay in 5 millisecond steps */
    } generic_onoff_set_msg_pkt_t;

    generic_onoff_client.c:

    static uint8_t message_set_packet_create(generic_onoff_set_msg_pkt_t *p_set, const generic_onoff_set_params_t * p_params,
                                          const model_transition_t * p_transition)
    {
            memcpy(p_set->packets, p_params->packets, 100);
            
            p_set->tid = p_params->tid;
    
            if (p_transition != NULL)
            {
                p_set->transition_time = model_transition_time_encode(p_transition->transition_time_ms);
                p_set->delay = model_delay_encode(p_transition->delay_ms);
                return GENERIC_ONOFF_SET_MAXLEN;
            }
            else
            {
                return GENERIC_ONOFF_SET_MINLEN;
            }
    }

    Any advice will be much appreciated! 

    ------------------------------ Latest status update ------------------------------

    After playing around with the mesh packet over the weekend. I hereby confirm that I managed to send and receive the extended mesh packets. It ended up that I forgot to change the memcpy size when buffering the received packet onto my server.

    Difference of transmission speed between segmented packets and instaburst packet can be observed significantly.

    Many thanks for your advice and suggestion. I think the manual compilation using SES is a better way for our established project, instead of building a new one using cmake.

  • Hi

    What is the throughput you are getting after using this Nordic Advertiser Extensions (Instaburst) feature?

Related