I am still very interested in your work. I've been out of pocket and haven't had much time to play with my project.
I have downloaded your latest software and got a 3 node MESH working. This is really cool stuff! So far I have only scratched the surface using USB FDDI boards to drive and test the MESH node functions.
Since I am testing just using FDDI modules connected to my ESP's, I have to type really fast since messages are constantly be sent between nodes. Can a perameter be added to slow down this messaging to allow hand typing AT commands easier to squeeze in between these messages?
Two things I have noticed so far:
1) It looks like one node ( the root node I believe) gets connected to other nodes as connection 251. It looks like the root node assigns connection numbers to the other nodes starting at 0 for the first connection and 1 for the second connection. From the root node I can perform AT+CIPSEND=0,3 /n/r 123/n/r and see +IPD,251,4B:123/n/rOK on the node whose connection number is 0. I can do the same thing from the root node to node connection 1. However, when I do the reverse and send AT+CIPSEND=251,3 /n/r xxx/n/r from the node assigned as connection 0, I only see the ROOT node respond with OK. I don't see the +IPD message displayed at all. I get the same result when I try sending from node connection 1 to the root connection 251. Can you confirm this behavior?
If I mess up typing the AT+CIPSEND command and use a bad connection number like 3, I get the response "link is not" and then the mesh restarts. Is this the intent or should the node just respond with "ERROR" and continue?
When I do AT+CIPSTATUS I don't see that node connection 0 sees node connection 1. Because of this I can't send messages directly between these two nodes. You had mentioned in an earlier post that the mesh would allow anly node to message to any other node in the mesh ( i.e. perform routing). Is this still planned? I could use this functionality in my application.
Thanks for sharing this excellent work!
BB
I shall look at the bug related with wrong command.
The network forms a Tree with a single root. Also, we should remember "I can accommodate Any nos of Child, but I must have only one Father". Where-I,Father,child denotes the ESP modules and Any means 255 max.
As per your observation and my suggestion:
1. It is better to avoid CIPSEND, rather use new command PINGROOT [AT+PINGROOT="YOUR DATA"] to send data from any child or grand-child or grand-grand child to Root. The info will propagate upto root. [There is another command which is under development AT+ROUTE=ConnectionLinkid,"Your data"]
2. Node-to-node communication will be added. Indeed, without that there is no meaning of mesh.
I am just busy with some UDP discovery, Mobile app, local cloud update, HTTP server setup stuffs.....all oriented with ESP.
Now, your network is like Node1->Root<-Node2. If you place the ESP geographically sequentially and start one after one with 10-15 sec gap, it will form a network like
Root<-node 1<-node2.
Thanks for your feedback. I shall update the code soon.
I tested some more tonight. It took a few tries but I finally got the mesh to configure as:
root<node1<node2. I issued an AT+PINGROOT="TEST" command. The ROOT node displayed the diagnostic messages:
>>> I am ROOT Node; Processing... State= 10
## DATA from child node->[MESH-300103¸p
OK
***LINK INFO: ME<-MESH-20010370216:2.1.1.0<-MESH-30010370203:2.2.1.0¸p
OK
The Root node indicated it recieved a message from a child node however, the Root node never indicated the actual data that was in the payload. I performed this test form both of the non-root nodes and got the same result from both.
Once I can get payload data to transfer through the mesh I will start software on my microprocessor boards to talk to the ESP MESH nodes rather than the FDDI modules I'm using now. Would it be possible to implement something like AT+DiagOn and AT+DiagOff to be able to turn on and off some of the diagnostic messaging so my micro doesn't have to parse that incoming data?
It's not big deal but my app supports packet payload lengths of 128 bytes plus an 8 byte wrapper. Could you stretch the packet length from 100 bytes up to 136 bytes by chance? It's not necessary but would be convienent.
Thanks!
BB