easyMesh
easyMesh copied to clipboard
Coopdis
easyMesh Protocol (TCP)
Is there any documentation (outline) of the easyMesh Protocol? Just how they interact with each other (TCP) to maintain the mesh and what messages are past back and forth and how they are forwarded ... and maybe something about how the timing sync stuff works too?
Gosh... that is a really good idea!
The good news is that it is all pretty straight forward and the packages are all reasonably human readable Jsons. If you turn on all the debuggingMsgTypes, then you will see all of the communications being sent on the Serial port.
Perhaps the most complex part is the "adopt" decision which controls which node adopts the time base of the other, but even this is quite simple. Basically both nodes in a new connection count the number of sub connections they have. The node with fewer connections adopts the time base of the node with more connections... if there is a tie, the AP wins. If the node that adopts has sub-connections, then it goes through the sub-connections and re-syncs with all those. Because a node always has more sub-connections then any of it's sub-connections, the majority time base always wins, and the whole mesh gets synchronized to a single time base. This works even if you have a mesh of (say) 27 nodes (re?) connecting to a mesh of 20 nodes. The time base of the 27 wins.
Time syncing itself is also pretty simple. Node A starts a time sync with Node B by sending a TIME_SYNC package with its "meshTime" (whatever that may be) and num=0. When B receives the TIME_SYNC packet, it records the meshTime that Node A sent, and sends back another TIME_SYNC packet with what it thinks meshTime is (whatever that may be) and num++. When A get's B's packet, it does the same thing, and this goes on until num=TIME_SYNC_CYCLES (defined as 10 in easyMeshSync.h). At this point, both nodes have 5 records of what the other node thinks the time should be. Then the node that "adopts" simply looks for the 2 records that are closest together (which is to say the two packets with the shortest round trip time), takes the average and adopts that number as it's new meshTime. Nothing fancy. Could be better, but works pretty well for the time being.
(aside: there is a good argument to be made, that this is inefficient... and there is no doubt that this is true in multiple ways. The biggest way that springs to mind is that the adopting node spends a bunch of time sending its time base information to the other node, and that info is never going to get used... but this is intentional! The benefit here is that both nodes are running through the same code and doing the same thing on every cycle, regardless of the adoption status, and so it is likely that running these routines will take the same amount of time on both sides. So it is somewhat reasonable to assume that a package going one way takes just about as long as a package going the other. Of course, this is not strictly true, as virtually nothing available through the SDK is running deterministically... but it is likely to be the case unless you've got the processor pinned at 100% which is not a good idea for lots reasons. In my experience your chances of getting a delayed packet are way lower than the 60% required for this game to work... delays seem to crop up with a frequency of more like 3%. My totally un-rigorous observations have been that typically the round trip time stays pretty close to constant for all five pairs, with the occasional big delay showing up here and there, and in a super obvious sort of way. These delayed pairs get thrown out automagically unless all five pairs have delays. So... could be better, but works pretty good as is.)
It would be great if someone wanted to start developing some proper docs. I'd be happy to help intermittently. Otherwise, I'll push it to the list of good ideas and get around to it eventually.
Bill
How long would the above process take? What if I have a normal process running, real work controlling something. Maybe even serving a web page with some images or a chart of data. Would it cause any significant delays, or timeout errors to a connected client.
I haven't had time to try this yet. I hope I can soon.
Because a node always has more sub-connections then any of it's sub-connections, the majority time base always wins, and the whole mesh gets synchronized to a single time base.
I have five nodes and they are not all in sync. Currently three of the five are in sync. I have had it where I had two in sync with each other, two different ones in sync with each other, and one not in sync with anyone.
The attached image shows the value for mesh.getNodeTime() on the right.
Hours later:
The node count on three modules had gone up to 10, but it seems to be back to normal again.
Hello! Please someone help me start with EasyMesh! I have 3pcs ESP8266MOD, two USB-UART converters, and PIC32 USB development board with GPIO. Should I use Arduino or I can make this mesh with PIC32+ESP ??? My preferrably goal is using 8266 mesh under control of PIC32. It is enough to use "standard AT" firmware for 8266? Or I must to flashing my 8266's with specific firmware?
I have one question about Timebase adaptation. Instead of opening a new issue let me ask here.
When a Node adopts the timebase synchronization of another node what about the WiFi SSID and Password? Are they also adopted? Also, the description mentions something like this
"###void easyMesh::init( String prefix, String password, uint16_t port ) Add this to your setup() function. Initialize the mesh network. This routine does the following things…
Starts a wifi network Begins searching for other wifi networks that are part of the mesh Logs on to the best mesh network node it finds… if it doesn’t find anything, it starts a new search in 5 seconds. prefix = the name of your mesh. The wifi ssid of this node will be prefix + chipId password = wifi password to your mesh port = the TCP port that you want the mesh server to run on"
