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

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

Pegah — Fri, 24 May 2019 10:57:18 GMT

Hi Nikunj,

Have you been able to use this method to measure RTT by using timer? If yes, could you share an example or a link that is useful?

Thanks,

Pegah

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

zeroking5 — Mon, 11 Mar 2019 09:03:47 GMT

Hi Nikunj Patel ,How is the project going now?

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

zeroking5 — Mon, 11 Mar 2019 08:43:29 GMT

Hi Edvin,I had create my ticket here (hope your reply :) ),and there is the relation with this topic,show below

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

Edvin — Mon, 11 Mar 2019 07:44:41 GMT

Hello zeroking5,

I don't really see that this is related to this ticket. Please create a new ticket with the description of your issue.

BR,

Edvin

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

zeroking5 — Sat, 09 Mar 2019 10:14:29 GMT

Hi,Edvin

I had modified the light-switch example into a model that can sent random bytes.But I need to Send data at >2s intervals when the bytes is upper to 10,or that the client code will run in to the place show as bellow.I want to know what can I deal with this problem,hope your reply.thanks.

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

Edvin — Tue, 31 Jul 2018 11:27:53 GMT

Hello Nikunj,

Sorry for the late reply. I was out of office last week.

As mentioned, the proxy part of the project is using the radio for BLE (non-Mesh) protocol, which means that if the message is sent out from one of the mesh nodes when the other is not listening, then it will not be received.

To minimize the chance of this happening you should increase your advertising and connection intervals. Try setting the advertising interval to something higher, like 1 second. I don't know whether you are in a BLE connection while doing these tests, are you? If so, you can try to increase the MIN_CONN_INTERVAL but depending on the phone, it might not work, as it is always the central in a BLE connection that decides the connection interval.

Try to increase the adv interval to 1 second, and see whether the behavior improves.

I should also mention a couple of things:

If you add a third node, then the third node would repeat the message, thus increasing the chance of the second node/proxy node to hear the message. This way, if the second node would hear the message from the repeating node if it was busy while it was first broadcasted.
Mesh is really not made for high bandwidth. If you intend to send large chunks of data frequently in your network, Mesh might not be the right protocol. What is the sort of throughput that you are looking at?

Best regards,

Edvin

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

Nikunj Patel — Fri, 27 Jul 2018 11:32:37 GMT

Hi Edvin,

Please Reply me ASAP.

Regard's

Nikunj

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

Nikunj Patel — Mon, 23 Jul 2018 10:52:24 GMT

Hello Edvin,

Now i'm using non proxy example,The results is better then previous one.

Connection Interval

#define MIN_CONN_INTERVAL MSEC_TO_UNITS(250, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(1000, UNIT_1_25_MS)

Advertisement interval
#define BEARER_ADV_INT_DEFAULT_MS 20

Scan interval
#define BEARER_SCAN_INT_DEFAULT_MS 2000

Scan window
#define BEARER_SCAN_WINDOW_DEFAULT_MS 2000

i want to send 250 byte Payload using light switch ble mesh example code.i have implemented echo back mechanism.

i have attached sheet of readings taken with 10,50,250 byte.

devzone.nordicsemi.com/.../Roundtrip_5F00_Calculation_5F00_NonProxyClient.xls

please check it and tell me that roundtrip delay is getting some time higher.

Thank's

Nikunj

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

Edvin — Fri, 20 Jul 2018 11:52:26 GMT

Hello,

Ok. It seems that you are missing some packets (then the other device will try to resend them).

Since you are using the proxy example, what conn_interval and advertising_interval do you use? Can you try with the non-proxy example to see if that helps?

The reason might be that since you are using the proxy example, the device will not have control of the radio all the time. Not when the softdevice is using it. If it works better with the non-proxy example, you can try to increase the BLE interval (advertising/scanning interval and connection interval) to see if that helps.

Best regards,

Edvin

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

Nikunj Patel — Fri, 20 Jul 2018 04:55:01 GMT

Hello Edvin,

I have try to send only 8 byte Echo back message.

Echo Back Calculation Time = (Stop Count - Start Count )/32768 in Second

Loge Snap Shot is Below

1st time Send 8 byte Echo back time =(176891 -71253)/32768= 3.22 Second
2nd time Send 8 byte Echo back time =(16612647 -16585267 )/32768= 0.83 Second
3rd time Send 8 byte Echo back time =(48805 -21421 )/32768= 0.83 Second

See in Log 1st time Client send only 8byt to server ,Client Retries 3 time after receive Ack but server receive message 2 times.

i think client wait for Ack if not receive then retries multiple time . in my case server receive messege 2 time but not send ack to client.

Thank's

Nikunj

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

Edvin — Thu, 19 Jul 2018 13:59:15 GMT

Hello Nikunj,

Mesh is built on BLE advertisement packets. An advertising packet is 31 bytes long. In Mesh, if you exclude the headers, you are left with 11 bytes. In addition, since you are using the nordic access API, company-ID and opcode, you are left with 8 bytes.

This means that when you send a message with 50 bytes, it is split into 7 packets. six with 8 bytes, and one with 2 bytes.

Your devices will only send a packet every 20ms. I am not sure exactly how that example works, but if you loose a packet, it might have to send the entire message again. Since you only have 2 nodes in the network, you don't have any nodes to retransmit the packets either, so if the client doesn't receive the packet initially, the message will be lost.

Can you please try to split the packet into 8 bytes sized packets? You can use the NRF_MESH_EVT_TX_COMPLETE event to know when a packet is sent, to trigger the next one, like explained earlier.

Best regards,

Edvin

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

Nikunj Patel — Thu, 19 Jul 2018 11:12:20 GMT

HI Edvin,

Forgot Every Thing ..I have modify simple on_off Light Switch Example.

Query : When Client Send 50 Byte to server, server get 50 byte message immediately after sever send echo back message to client but client does not get message immediately, due to this server retries message.

My question is why client does not receive echo back message immediately?

devzone.nordicsemi.com/.../Firmware.rar

Thank's

Nikunj Patel

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

Edvin — Thu, 19 Jul 2018 06:33:32 GMT

Hello,

You write that you use two DKs, right?

Is it possible to send the project that you are using to perform the tests?

Best regards,

Edvin

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

Nikunj Patel — Wed, 18 Jul 2018 11:43:06 GMT

Hi Edvin,

Please focus on my main Question is to reduce roundtrip delay of echo-back message from client to server to client again with the same message.

Client Send Message:-

uint8_t DATA_Tx[50]="ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWX";
uint32_t status = NRF_SUCCESS;
    status = send_command_client(&m_clients[button_number],&DATA_Tx[0],sizeof(DATA_Tx));
    if(!status)
    {
        Send_Cnt++;
        Start_timer_cnt=log_timestamp_get();
        
        __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "SendMsg to Server:%s    Msg_Send_Cntr:%d     Start_timer_cnt =%d \n",DATA_Tx, Send_Cnt,Start_timer_cnt);
    }

Server Received Message After Echo-Back Message to client:-

static void handle_send_command_cb(access_model_handle_t handle, const access_message_rx_t * p_message, void * p_args) 
{
    
    uint16_t  i;
    uint8_t buffer[260];
    
    
    Stop_timer_cnt= log_timestamp_get();
    Rec_Cnt++;
    Actual_Time =((Stop_timer_cnt-Start_timer_cnt)/32768);
    
    memset(buffer, 0, sizeof(buffer));
    strncpy(buffer, command, length); 
    __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Received Data From Client: %s Rec_Cnt = %d rssi=%d Stop_timer_cnt=%d Actual_Time=%d\n", buffer,Rec_Cnt,p_message->meta_data.p_core_metadata->params.scanner.rssi,Stop_timer_cnt,Actual_Time);


    strncpy(response_msg.response, command, length);
    response_msg.length = length;               


    if (response_msg.length !=0)
    {  // need to send reply
        access_message_tx_t reply; 
        reply.opcode.opcode = Custom_message_OPCODE_RESPOND;
        reply.opcode.company_id = ACCESS_COMPANY_ID_NORDIC;
        reply.p_buffer = (const uint8_t *) &response_msg;
        reply.length = response_msg.length+2;  // just sending the length (16-bit) + response string.
        (void) access_model_publish(p_server->model_handle, &reply); //Publishing
    }    
    else
     {
        failureCount++;
     }
}

Client Received Echo Message :-

static void handle_status_cb(access_model_handle_t handle, const access_message_rx_t * p_message, void * p_args) { uint16_t i; uint8_t buffer[260]; simple_on_off_client_t * p_client = p_args; NRF_MESH_ASSERT(p_client->status_cb != NULL); uint8_t *command = ((send_command_msg_t *) p_message->p_data)->command; uint16_t length = ((send_command_msg_t *) p_message->p_data)->length; if (!is_valid_source(p_client, p_message)) { return; } Stop_timer_cnt= log_timestamp_get(); Recv_Cnt++; Actual_Time =((Stop_timer_cnt-Start_timer_cnt)/32768); receive_response_msg_t *p_response = (receive_response_msg_t *) p_message->p_data; memset(buffer, 0, sizeof(buffer)); strncpy(buffer, p_response->response, p_message->length-2); __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Received Data From Server: %s\t Rec_Cnt = %d rssi=%d Stop_timer_cnt=%d Actual_Time=%d\n", buffer,Recv_Cnt,p_message->meta_data.p_core_metadata->params.scanner.rssi,Stop_timer_cnt,Actual_Time); }

Thank's

Nikunj Patel

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

Nikunj Patel — Wed, 18 Jul 2018 10:51:26 GMT

Hi Edvin,

your answer does not match with my requirement. Answer for your required question below.

Que:Do you have any way of identifying message?
Ans: whatever client will send, server will echoback same message it received.

Que: Do you know that you are measuring the correct delay?
Ans: when client send message to server,timer started in client and it waits for echoback message from server. when echoback message received at client side.it will capture the timer.

Que: do you wait until you get the message back before you send a new one?
Ans: Yes

Thank's

Nikunj Patel

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

Edvin — Wed, 18 Jul 2018 10:29:21 GMT

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

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

Nikunj Patel — Wed, 18 Jul 2018 08:24:17 GMT

Hello,

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

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

Nikunj Patel — Tue, 17 Jul 2018 03:40:19 GMT

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

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

Edvin — Mon, 16 Jul 2018 14:15:40 GMT

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

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

Nikunj Patel — Mon, 16 Jul 2018 04:59:22 GMT

Hello,

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