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

Adding nRF52 DK to gitHub mesh demo for thingys

Hello everyone, 

I`ve 4 thingys and ran the https://github.com/NordicPlayground/Nordic-Thingy52-mesh-demo. That works well. 

Now I`m trying to add the nRF52 DK as a Node to the bluetooth mesh network in order for it to receive the periodic messages sent by the sensor nodes. 

As a first step, I was trying to program the light_switch_example_server_nrf52832_xxAA_s132_3_1_0 from the nRF5 SDK for Mesh v1.0.1 onto the Chip (using SEGGER Embedded Studio) to see whether it is being provisioned by the bridge. Unfortunately it is not. 

My question is: Why doesn`t the nRF5 DK get provisioned by the bridge? And what do I have to change to add it to the mesh and to receive the messages of the thingys? 

Best regards, 

Michael

Parents
  • Hello Michael,

    Great to hear that the Thingy mesh demo works well.

    The reason why the nRF52-DK with "light switch server" cannot work with "Thingy bridge" correctly is that:

    1. The "Thingy bridge" will do provision for the unprovisioned device and then do the configuration
    2. During the configuration, Thingy bridge will try to bind the AppKey to the "simple Thingy server model" (the code is in here)
    3. However, the "light switch server" is using the "simple on off server", which is different
    4. So the configuration will fail

    Basically, if you want your nRF52-DK works with "Thingy mesh demo", you have to add the "simple Thingy server model" into your project which running on nRF52-DK.

    Also, since "Thingy mesh demo" is quite old (using nRF5 Mesh SDK v1.0.1), I would like to suggest you try the project "Thingy mesh provisioning demo"  which made by Hung :)

    Best regards,

    Rick

  • Thank you very much for your fast response, Rick!

    I`m not sure what adding simple thingy server model in detail means. I added simple_thingy_server.c and ...server.h to the light_switch_project and additionally added the include directories for the preprocessor, which means building the project works fine now. 

    Furthermore I have initialized the simple_thingy_server and bound it to an element. What else do I have to do to get my nRF52 DK provisioned?

  • Hello Rick 

    yes, the link works now. But that`s exactly how I initialized the model. Unfortunately it still doesn`t work. 

    /* Copyright (c) 2010 - 2017, Nordic Semiconductor ASA
     * All rights reserved.
     *
     * Redistribution and use in source and binary forms, with or without modification,
     * are permitted provided that the following conditions are met:
     *
     * 1. Redistributions of source code must retain the above copyright notice, this
     * list of conditions and the following disclaimer.
     *
     * 2. Redistributions in binary form, except as embedded into a Nordic
     *    Semiconductor ASA integrated circuit in a product or a software update for
     *    such product, must reproduce the above copyright notice, this list of
     *    conditions and the following disclaimer in the documentation and/or other
     *    materials provided with the distribution.
     *
     * 3. Neither the name of Nordic Semiconductor ASA nor the names of its
     *    contributors may be used to endorse or promote products derived from this
     *    software without specific prior written permission.
     *
     * 4. This software, with or without modification, must only be used with a
     *    Nordic Semiconductor ASA integrated circuit.
     *
     * 5. Any software provided in binary form under this license must not be reverse
     *    engineered, decompiled, modified and/or disassembled.
     *
     * THIS SOFTWARE IS PROVIDED BY NORDIC SEMICONDUCTOR ASA "AS IS" AND ANY EXPRESS
     * OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
     * OF MERCHANTABILITY, NONINFRINGEMENT, AND FITNESS FOR A PARTICULAR PURPOSE ARE
     * DISCLAIMED. IN NO EVENT SHALL NORDIC SEMICONDUCTOR ASA OR CONTRIBUTORS BE
     * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
     * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
     * GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
     * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
     * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
     * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
     */
    
    #include <stdint.h>
    #include <string.h>
    #include "simple_thingy_server.h"
    #include "ble_uis.h"
    
    /* HAL */
    #include "nrf.h"
    #include "boards.h"
    #include "nrf_mesh_sdk.h"
    #include "nrf_delay.h"
    #include "simple_hal.h"
    
    /* Core */
    #include "nrf_mesh.h"
    #include "nrf_mesh_events.h"
    #include "log.h"
    
    #include "access.h"
    #include "access_config.h"
    #include "device_state_manager.h"
    #include "nrf_mesh_node_config.h"
    
    #include "simple_on_off_server.h"
    
    #include "light_switch_example_common.h"
    
    /*****************************************************************************
     * Definitions
     *****************************************************************************/
    
    #define LED_PIN_NUMBER (BSP_LED_0)
    #define LED_PIN_MASK   (1u << LED_PIN_NUMBER)
    
    /*****************************************************************************
     * Static data
     *****************************************************************************/
    
    //static simple_on_off_server_t m_server;
    static simple_thingy_server_t m_server; 
    
    /* Forward declaration */
    static bool get_cb(const simple_on_off_server_t * p_server);
    static bool set_cb(const simple_on_off_server_t * p_server, bool value);
    
    static ble_uis_led_t led_get_cb(); 
    static ble_uis_led_t led_set_cb(const simple_thingy_server_t * server, ble_uis_led_t led_config);
    static void sensor_set_cb(const simple_thingy_server_t * server, sensor_config_t sensor_cfg);
    
    
    /*****************************************************************************
     * Static utility functions
     *****************************************************************************/
    
    static void configuration_setup(void * p_unused)
    {
        __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Initializing and adding models\n");
    //    m_server.get_cb = get_cb;
    //    m_server.set_cb = set_cb;
        m_server.led_get_cb = led_get_cb; 
        m_server.led_set_cb = led_set_cb; 
        m_server.sensor_set_cb = sensor_set_cb; 
    //    ERROR_CHECK(simple_on_off_server_init(&m_server, 0));
        ERROR_CHECK(simple_thingy_server_init(&m_server,0));
        ERROR_CHECK(access_model_subscription_list_alloc(m_server.model_handle));
       
       // hal_led_mask_set(LEDS_MASK, true);
    }
    
    static void provisioning_complete(void * p_unused)
    {
        __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Successfully provisioned\n");
        hal_led_mask_set(LEDS_MASK, false);
        hal_led_blink_ms(LED_PIN_MASK, 200, 4);
    
    }
    
    /*****************************************************************************
     * Simple OnOff Callbacks/ Simple Thingy Callbacks
     *****************************************************************************/
    
    //static bool get_cb(const simple_on_off_server_t * p_server)
    //{
    //    return hal_led_pin_get(LED_PIN_NUMBER);
    //}
    
    static ble_uis_led_t led_get_cb()
    {
        // Dummy method just to get simple thingy model initialized and nRF5 DK provisioned
        ble_uis_led_t led_cmd;
        led_cmd.mode = BLE_UIS_LED_MODE_CONST;
        led_cmd.data.mode_const.r = 0x0f;
        led_cmd.data.mode_const.g = 0x0f;
        led_cmd.data.mode_const.b = 0x0f;
        return led_cmd; 
    }
    
    static ble_uis_led_t led_set_cb(const simple_thingy_server_t * server, ble_uis_led_t led_config)
    {
        // Dummy method just to get simple thingy model initialized and nRF5 DK provisioned
        return led_config; 
    }
    
    static void sensor_set_cb(const simple_thingy_server_t * server, sensor_config_t sensor_cfg)
    {
      // Dummy method just to get simple thingy model initialized and nRF5 DK provisioned
       __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "----- sensor set callback -----\n");
      
    }
    //static bool set_cb(const simple_on_off_server_t * p_server, bool value)
    //{
    //    __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Got SET command to %u\n", value);
    //    hal_led_pin_set(LED_PIN_NUMBER, value);
    //    return value;
    //}
    
    void mesh_stack_init(void)    // von Thingy_node kopiert, um gleiches Setup des provisionees zu gewährleisten
    {
        static const uint8_t static_auth_data[NRF_MESH_KEY_SIZE] = STATIC_AUTH_DATA;
        static nrf_mesh_node_config_params_t config_params;
        config_params.prov_caps.num_elements = ACCESS_ELEMENT_COUNT;
        config_params.prov_caps.algorithms = NRF_MESH_PROV_ALGORITHM_FIPS_P256EC;
        config_params.prov_caps.oob_static_types = NRF_MESH_PROV_OOB_STATIC_TYPE_SUPPORTED;
        config_params.p_static_data = static_auth_data;
        config_params.complete_callback = provisioning_complete;
        config_params.setup_callback = configuration_setup;
        config_params.irq_priority = NRF_MESH_IRQ_PRIORITY_LOWEST;
        config_params.lf_clk_cfg.source = NRF_CLOCK_LF_SRC_XTAL;
        config_params.lf_clk_cfg.xtal_accuracy = NRF_CLOCK_LF_XTAL_ACCURACY_20_PPM;
        nrf_mesh_node_config(&config_params);
    }
    
    int main(void)
    {
        __LOG_INIT(LOG_SRC_APP | LOG_SRC_ACCESS, LOG_LEVEL_INFO, LOG_CALLBACK_DEFAULT);
        __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "----- BLE Mesh Light Switch Server Demo -----\n");
    
        hal_leds_init();
    
    //   static const uint8_t static_auth_data[NRF_MESH_KEY_SIZE] = STATIC_AUTH_DATA;
    //    static nrf_mesh_node_config_params_t config_params =
    //        {.prov_caps = NRF_MESH_PROV_OOB_CAPS_DEFAULT(ACCESS_ELEMENT_COUNT)};
    //    config_params.p_static_data = static_auth_data;
    //    config_params.complete_callback = provisioning_complete;
    //    config_params.setup_callback = configuration_setup;
    //    config_params.irq_priority = NRF_MESH_IRQ_PRIORITY_LOWEST;
    //
    //#if defined(S110)
    //    config_params.lf_clk_cfg = NRF_CLOCK_LFCLKSRC_XTAL_20_PPM;
    //#elif SD_BLE_API_VERSION >= 5
    //    config_params.lf_clk_cfg.source = NRF_CLOCK_LF_SRC_XTAL;
    //    config_params.lf_clk_cfg.accuracy = NRF_CLOCK_LF_ACCURACY_20_PPM;
    //#else
    //    config_params.lf_clk_cfg.source = NRF_CLOCK_LF_SRC_XTAL;
    //    config_params.lf_clk_cfg.xtal_accuracy = NRF_CLOCK_LF_XTAL_ACCURACY_20_PPM;
    //#endif
    
     //   ERROR_CHECK(nrf_mesh_node_config(&config_params));
    
        mesh_stack_init(); 
        hal_led_mask_set(LEDS_MASK, true);
        while (true)
        {
            (void)sd_app_evt_wait();
        }
    }
    

    I posted my new code for reference. 

    Might there be any problem with the bearer? While checking the code I realized, that there is a difference between the bearer of the light_switch_example and the one of the thingy_mesh_demo. 

    Other than that I don`t have an idea whatsoever. 

    : Implementing the DK as the bridge makes more sense indeed, but I would like to first solve the provisioning problem before I change the architecture and have to start over again. 

    Best regards, 

    Michael

  • Hello Michael,

    Have you seen any error log from the provisioner or the server node itself?

    Since there's no error log, so I cannot give more help on this.

    And the reason why we should use "bridge" node as a reference is that the bridge contains with "simple_thingy_client", which has the sensor_status_cb() for handling the sensor information Slight smile

  • Hello Rick, 

    This is the log I get by debugging the thingy with the bridge software while I have a thingy with node and the development kit with my modified code ( which can be seen in my previous response). 

    This is the log I get from the thingy node: 

    And this is what the debugging of the dk with the simple_thingy_server results in: 

    Both the thingy server and the dk server initialize the simple_thingy_server-model, however, only the one implemented in the thingy is provisioned. Say you were right and the problem would be during the configuration process, shouldn`t then the provisioning process be successful and the following configuration process report an error? 

    Since the provisioning process doesn`t even start (at least in the log I cannot see that it starts) I think the problem is already located in the provisioning process.

    I then checked the configuration parameters used to configure the node with nrf_mesh_node_config() and they are similar as well. (Same authentication key and static, same setup_callback() etc.). I finally realized that during the initialization of the provisionee model different bearer types are used. Might that be the reason, why the bridge doesn`t even seem to recognize the dk?

    Regards Michael

  • Hello Michael,

    May I know how you create the project for running "simple Thingy server" on the nRF52-DK? E.g. Are you using the workspace base on the "Thingy node" project in Thingy mesh demo, or are you using the example project in the mesh SDK v1.0.1?

    And would you please explain more about the "different bearer types" mentioned in the previous message? :)

  • I`m using the light_switch_server-project from the examples of the mesh sdk v1.0.1. 

    While configuring the mesh node using nrf_mesh_node_config() the provisionee-model is initialized using setup_provisionee(). In this process, public and private keys for the provisioning cryptography are generated, the provisionee is initialized with a so called provisioning context, which contains important information for setting up the provisionee. One of these characteristics is the bearer type, which I believe has to be similar to the one of the bridge. And right now it apparently is not, which might be the reason why the bridge doesn`t recognize the dk. 

    Regards Michael

Reply
  • I`m using the light_switch_server-project from the examples of the mesh sdk v1.0.1. 

    While configuring the mesh node using nrf_mesh_node_config() the provisionee-model is initialized using setup_provisionee(). In this process, public and private keys for the provisioning cryptography are generated, the provisionee is initialized with a so called provisioning context, which contains important information for setting up the provisionee. One of these characteristics is the bearer type, which I believe has to be similar to the one of the bridge. And right now it apparently is not, which might be the reason why the bridge doesn`t recognize the dk. 

    Regards Michael

Children
Related