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

Test Mesh Network with Light Switch example

I am testing a mesh network, using the NRF52832 modules, SDK 15.2 and MESH_SDK 3.0, provisioning the nodes with nRF Mesh android app and using a modified firmware for the Light Switch (Client), connected to the PC via serial usb, which sends an on-off command to two groups of nodes (Server): first, sequentially through the implementation of a timer, the client [0] automatically sends the on-off command to the first group, then again the client ([1] to the second group, and so on.

 

This is the test network:

 

Client[0] –> Nodes 8-9-10 (group1)

Client[1] -> Nodes 1-2-3-4-5-6-7 (group2)

              

Group1

Server 1 0x0004 

Server 2 0x0008 

Server 3 0x0009 

Server 4 0x000A 

Server 5 0x000B 

Server 6 0x000C 

Server 7 0x000D

 

Group2

Server 8     0x000E 

Server 9     0x000F 

Server 10   0x0010 

Log file

I added the log to the network.c file, as in the following code

static bool should_relay(const network_packet_metadata_t * p_metadata)
{
    /* Relay feature must be enabled */
#if EXPERIMENTAL_INSTABURST_ENABLED
    if (!core_tx_instaburst_is_enabled(CORE_TX_ROLE_RELAY))
#else
    if (!core_tx_adv_is_enabled(CORE_TX_ROLE_RELAY))
#endif
    {
        return false;
    }
    /* TTL must be 2 or greater */
    if (p_metadata->ttl < 2)
    {
        return false;
    }
    /* Should not be directed to a unicast address on this device */
    if (p_metadata->dst.type == NRF_MESH_ADDRESS_TYPE_UNICAST)
    {
    // mod And see all the Health messages from the other server nodes in the network
     __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Packed relayed from Node: 0x%04x with TTL:%u sequence_numb: 0x%04x dest: 0x%04x.\n", p_metadata->src,p_metadata->ttl,p_metadata->internal.sequence_number, p_metadata->dst.value);
        nrf_mesh_address_t dummy_addr;
        if (nrf_mesh_rx_address_get(p_metadata->dst.value, &dummy_addr))
        {
            return false;
        }
    }
    /* Relay check callback function approves of the relay */
    if (m_relay_check_cb != NULL)
    {
        if (!m_relay_check_cb(p_metadata->src, p_metadata->dst.value, p_metadata->ttl))
        {
            return false;
        }
    }
    return true;
}
#endif /* MESH_FEATURE_RELAY_ENABLED */

Testing is done using the following configuration:

  • TTL (client and server) modified to 4
  • TX_power (client and server) 4dB
  • Network and relay configuration, for the application to test, as default.

 

The messages sent via the generic_onoff_client model (with ACK for both groups of nodes) are all received by the nodes of the network, both from those in range and those out of the client range, but, for each on-off command sent, I riceive back the STATUS of all the interested nodes only from group1, never from group2 (see log file above).

Could it be a network congestion problem due to packets exchanged between the nodes of group2, being these 7 to receive the command instead of 3 as in group 1? Or could it be trivially that I need to increase the TTL?

If so, I would like to know how to configure network level repetitions and network level repetition intervals, in order to solve the problem, as well as relay repetitions and relay repetition intervals. I can also easily do the same with nRF Mesh? 

  • Hi Andrea, 

    Please provide a little more information about the group address configuration you have ? Do you have any modification on the part that the server response status to the command ? 

    I would suggest you to try testing with only group 2 in the network. You can try first with just a few devices in range just to make sure that they works when there is no relay. 

    You can try to add some repetition when sending status packet, just to check if interference was the reason. 

  • Hi,

    I’m using the nRF Mesh app for network configuration. I publish on the 1st client with address 0xC000 to all servers of group 1 (with subscribe address 0xC000) and on 2nd client with address 0xC001 to all servers of group 2 (with subscribe address 0xC001).

    I haven’t applied any modification on the server status response part to the command. I have modified the   2nd client with acknowledged transaction (ACK), but from the client application side.

    Soon, I will run the test you suggested to me and I'll let you know.

    How can I increase the status message repetitions? In Config_messages.h?

    Finally, can I rule out this is a TTL problem?

  • TTL = 4 could be too small. TTL = 4 means it's will be maximum 3 hops. In your case I can it may takes 4 hops to get to the client ? Suggest to try TTL = 5 or 6. 

Related