BLE MESH Stack(2.0.1)Light Switch Demo Roundtrip Delay getting higher between client and server

[Nikunj Patel]

Hii,

I am currently using two nRF52832 SDK boards to implement text message exchange with another nRF52832 SDK board via BLE Mesh SDK 2.0.1.

However, when I try to increase the frequency of sending the command the communication seem to choke. and i'm getting Roundtrip Delay higher between client and server.

Roundtrip calcualtion of 5byte send and receive  sheet is below

 

Round trip calcualtion of 11byte send and receive  sheet is below

How to reduce round trip delay time please suggest me ASAP.

Thanks,

Nikunj Patidar

 

[Nikunj Patel]

Hello,

I'm wating for reply from you...!

[Edvin]

Hello,

 

Sorry for the late reply. We are quite short staffed due to summer holiday here in Norway, so there is a little longer response time now, unfortunately.

What is the size of your Mesh Network, and how often do you send the messages?

When you send the 11Byte message, I suspect that it is split into several messages, and hence will increase the roundtrip time. 

Check out what Thomas and leonwj wrote in this case.

 

But yes, how many nodes are there in the network, and how often do you send the message?

 

Best regards,

Edvin

[Nikunj Patel]

Hi Edvin,

Thank's for reply me..!

        i want to calculate Roundtrip delay between client and server no other node in mesh network. However, when I try to increase the frequency of sending the command the communication seem to choke.

light switch example code(Mesh 2.0.1) is modify just i add simple message model.in this code.

Thank's

Nikunj

[Nikunj Patel]

Hello,

Please reply me...according to my log RSSI value is not ok. 

[Edvin]

Hello,

I had to ask a colleague of mine to look at your question. He had some questions about how you measure the delays. He writes:

----------

It doesn't look like he stamps the messages, so how does he know what message the server receives and answers to? It might have some implications on the measurements. Messages are not guaranteed to come in the right order in Mesh (although it is likely with only two nodes).The theoretical latency is ADV_INT/2 and default ADV_INT is 20ms. 

 

We have a feature in the stack that implements flow control relatively simple:

nrf_mesh_tx_token_t. Her is a code snippet that shows one way of using it:

static nrf_mesh_tx_token_t m_my_token;

static void mesh_evt_handler(const nrf_mesh_evt_t * p_evt)
{
    if (p_evt->type == NRF_MESH_EVT_TX_COMPLETE &&
        p_evt->params.tx_complete.token == m_my_token)
    {
        /* Message has been sent on air. */
    }
}

void packet_send(void)
{
    /* Using the access API directly. */
    access_message_tx_t message;
    memset(&message, 0, sizeof(message));

    /* TODO: Fill fields correctly */
    message.token = m_my_token;

    /* TODO: send */    
}


void init(void)
{
    static nrf_mesh_evt_handler_t s_evt_handler = {
        .evt_cb = mesh_evt_handler
    };

    /* nrf_mesh_unique_token_get() was introduced in v2.1.1 to guarantee uniqueness of the value.
     * You _could_ just use a #defined number, but risk using the same number as something else in
     * the stack.
     */
    m_my_token = nrf_mesh_unique_token_get();
    nrf_mesh_evt_handler_add(&s_evt_handler);
}

This is used e.g. in Node Reset to make sure that we have sent a status message before actually deleting everything and reset the node. Right now, you must use the access.h or nrf_mesh.h API directly to control tokens.

----------

 

So do you know that you are measuring the correct delays? Do you have any way of identifying the messages, or do you wait until you get the message back before you send a new one?

 

Best regards,

Edvin