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

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

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

 

  • 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
  • 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

  • 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

  • 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?

    Firmware.rar

    Thank's

    Nikunj Patel

  • 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

Related