What is the average latency for the Mesh.publish calls when the two particles are connected? Has anyone benchmarked it? I am trying to build a project that has 1ms timing error margins. Would mesh be appropriate in these situations?
I haven’t tested it, but I’d say the answer is almost certainly the latency will be much larger than that.
This paper describes some real-world tests of Thread mesh. It was not done with Particle hardware but it gives a ballpark estimate of what to expect, and it’s definitely not that fast. It also depends on the number of hops in the network between the nodes.
3 Likes
Out of curiosity, what is it you’re trying to achieve?
@rickkas7 Thank you! That is useful. Puts a kibosh on using this for my project.
@Moors7 I have built a DIY wired fencing box and was hoping to take it wireless. The commercially available options are super expensive and thought this would be a cool little hack for my kid and me to work on.
@fundamol, when you say “fencing” do you mean the sport? Is latency an issue if you capture an event with a timestamp at the node?
@peekay123 Yes! 
I am considering first just ignoring timing and see what happens and then if the latency is an issue solve for it if possible. I did consider timestamps however I would have to handshake because I have to synchronize two clocks since there are two wireless transmitters.
@fundamol, mesh will most likely not give you the short and fixed latency you are looking for. As you said, you need accurate synchronization of a time reference on each node so you can “subtract out” the mesh network latency time. One way to do this is to use a GPS on each unit as a clock source. In theory, given the physical adjacency of the units (nodes and gateway), tight synchronicity should be achievable. However, this means you need extra components and the ability to receive the GPS signal indoors. @ScruffR, any thoughts on this?
Thanks for the suggestion @peekay123. However I dont think I need GPS. If before a match, we just did a handshake of system ticks and then used it to understand who scored first, that might work.
1 Like
@fundamol, perhaps but how do you propose doing that handshake?
*edited to correct my dumbass mistake and provide updated test results 
I was curious about mesh latency too, and decided to test.
I get ~10ms round trip latency between an argon and a xenon over a single hop. The distance between devices does not seem to matter within range.
I’ve included my code below, it’s pretty quick and dirty so let me know if I have missed anything!
For the master device
//poll to ensure second device is online
Timer greeting(2000, checkForFriend);
unsigned long serveTime;
void setup() {
waitUntil(Mesh.ready);
// Start when second device is ready
Mesh.subscribe("ready-and-waiting", gameOn);
// Prepare for return of serve
Mesh.subscribe("pong", measureLatency);
Serial.begin();
greeting.start();
}
void measureLatency(const char *event, const char *data){
int latency = micros()-serveTime;
//Log to USB Serial
Serial.print("Round trip latency was: ");
Serial.print(latency);
Serial.println(" µs.");
//Have a wee rest
delay(1000);
//Serve again
serveTime = micros();
Mesh.publish("ping");
}
void checkForFriend(){
waitUntil(Mesh.ready);
Mesh.publish("ready?");
}
void gameOn(const char *event, const char *data){
greeting.stop();
serveTime = micros();
Mesh.publish("ping");
}
and on a second device on the same mesh network
void setup() {
waitUntil(Mesh.ready);
Mesh.subscribe("ready?", confirmReady);
Mesh.subscribe("ping", returnServe);
}
void returnServe(const char *event, const char *data){
Mesh.publish("pong");
}
void confirmReady(const char *event, const char *data){
Mesh.publish("ready-and-waiting");
}
@sryburn thank you for providing more concrete proof. In my case, I also only care for one way latency and not round trip, so its even better.
It seems to me that Timestamps would be more accurate and dependable in this situation.
Could your Gateway be used to calibrate the "time" on both Xenons ?
Something as simple as physically driving a Pin High (short wires) on both Xenons causing a calibration publish before a match. The Gateway will use the millis() or micros() from both Xenons' publish to define the timing offsets.
The Gateway could also track/test the difference over time during initial testing (the Xenons may not need to be re-calibrated after every match, depending on those results).
Folks, testing single-hop latency is not fully representative of overall Mesh latency. Multi-hop latency needs to be tested and characterized as well. Ideally, a gateway is not burdened with a large number of single hop nodes and I’m not sure what a realistic limit is for Particle mesh devices. I believe a gateway should have around 10 single-hop nodes and each repeater node should have up to 10 sleepy or repeater nodes. Again, this has not been characterized in terms of CPU load, RAM usage, latency, error rate, etc.
This is why I put somewhat high on my Particle todo list the need for a network management API to assist in designing and managing a mesh network.
1 Like
@peekay123 totally agree with your comment that this is unlikely to be representative of latency in a larger / more complex mesh network. A network management API would be super useful to assist with mesh network design in this case!
FWIW In my current project I’m not really using mesh networking per se - I have a simple wireless remote (consisting of LCD touchscreen, rotary encoder, xenon, lipo battery) that talks to a wired basestation (argon) that controls various relays and actuators. It’s important that the LCD remote accurately reflects the state of the basestation. I currently have it configured such that a rotary encoder pulse will publish an updated value to the basestation which then publishes it’s state back to the remote, which then updates the LCD (via serial). To my surprise this works amazingly well with no real perceptible lag between turning the encoder and seeing the updated value on screen. I will also look into using bluetooth for this if/when those APIs are available but for now I’m pleasantly surprised with the speed of mesh in this configuration.
Of course at a human scale 10ms is fast beyond the level of our perception (faster than the refresh rate on a 60hz display)
1 Like