measure total time required to send message from client to sever and server acknowledges that message to client using BLE MESH stack (2.0.1)

[Nikunj Patel]

Hi...,

i have measured round trip delay from client to server.

Now I want to measure total time required to send  message from server to client and client acknowledges that message to server using BLE MESH stack (2.0.1) light-switch example demo.

is it possible or Not..?

Thanks,

-Nikunj Patidar

[Bjørn Kvaale]

This should be possible. You can use the log_timestamp_get() function located in log.h to get a timestamp & then have logging enabled via RTT for example to see when the message gets sent from the server & when the server gets the ACK from the client. Then, you just compare the difference between both timestamps to figure out the total time.

[Nikunj Patel]

in onoff light switch demo example, server only send light status to client. in that case, as i assume, client will not acknowledge to that message.so using that, i can not able to measure round trip delay.

is there Any different way to measure roundtrip delay?

  

[Nikunj Patel]

Hi  Bjorn Kvaale,

I'm waiting for reply from you.

[Bjørn Kvaale]

What if you just send a message back from the client to the server? In the client_status_cb in the light switch client example, you receive the server_index of whichever server status you have received. If you add logging information to this variable & test the mesh with two server boards, whenever you press button 1 on the first provisioned server -> the server_index returns 0. When you press button 1 on the server provisioned in afterwards, the server_index returns 1.

Therefore, I believe you should be able to find the roundtrip delay by sending a new message by calling

simple_on_off_client_set(&m_clients[server_index], false) in both these two cases: SIMPLE_ON_OFF_STATUS_ON & SIMPLE_ON_OFF_STATUS_OFF in the client example.

You could then use the log_timestamp_get() function to get a timestamp when you press button 1 on one of the servers & get a new timestamp when you get the set command in the on_off_server_set_cb in the light switch server.

[Nikunj Patel]

Hi Bjorn

I want to test latency using BLE MESH 2.0.1 Light Switch Example Code...I have modify simple on off Light Switch Example.

Example test Using two Development kit 52832. One Device Configure as a non-proxy client and another as a non-proxy server.no other node in mesh network i want to test latency between two device. 

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

3162.BLE_Mesh_Message_Roundtrip_Calculation_NonProxyClient.xls

50 and 250 byte round trip delay is higher.is it possible to reduce it or not..?

Thank's

Nikunj

[Nikunj Patel]

Hi

Please reply me ASAP.

[Bjørn Kvaale]

Sorry for the delayed response. This mesh blog post says this about mesh latency:

"The network latency and node power consumption depends on how much of the time is spent in scanning and advertising. The latency is on average 15ms per hop and the power consumption of the nodes is largely determined by the receive current (if everything is configured for minimum latency which means radio is on close to 100% of the time)"

It makes sense that the unreliable communication you receive for 10 bytes of data sent is slightly quicker that the reliable messages since the sender does not get an acknowledgement back from the receiver. You are not using the proxy functionality, which is good, because this would split up the radio time between mesh & GATT proxy, leading to increased latency. Have you investigated why the round trip delay is up to 2 seconds sometimes, while other times it is as low as 0.1 seconds? 

Remember that the client & server node will send health messages to the provisioner continuously. You might want to try to limit how often the heartbeat messages are sent. Take a look at Section 3.6.7 of the Mesh Profile Spec for more information about this.

Have you tried disabling the relay functionality to see if this affects the roundtrip delay? I am not sure this will have anything to say, as you only have one provisioner, one client & one server node.