-
Just In Cases
05/15/2016 at 02:17 • 0 commentsPicked up the cases for each node this evening. I would up going with the classic Radio Shack project box. They are about $3.50 each (which more or less blows up the cost per node) but they are the right size and I do not want to wait on something cheap to come over from China. They are the right size, durable, easy to work with, and I already had one to test the fit.
Upon further review, I realized there might have been some fun options ton consider with plastic pipe. Plastic electrical conduit of about 1" interior diameter is waterproof, weather proof, shock resistant, and very compact. All of the components would slip nicely inside (sans battery of course). This might be a cool option for future node variants.
Tonight I'm creating Y connections so I can have one 5V in port on the outside of the box and still feed separate power to the Arduino and the RF adapter board. Once that's done, I'll dry fit each node in a box, feed the wires through and fix the female 22awg connectors with hot glue (probably) on the inside. Stay tuned for multiple pictures when that's done.
-
Much Solder...Such Connections
05/13/2016 at 01:01 • 0 commentsTonight I made a couple of new videos (which will be uploaded this weekend) demonstrating how to modify the battery pack to power each node. I also made a connection guide for the RF breakout and Arduino Nano. At this point, I've soldered headers on all 6 arduinos, connected each breakout with jumpers, and installed all 6 radios. All 6 battery packs have been modified appropriately.
I did further investigation on the tests I did yesterday and discovered that I actually wasn't sending packets back and forth like I thought. Some witchcraft had apparently vexed my radios and my serial monitor was lying. I could unplug one radio and still see transmissions....so....yeah.
I eventually tried using the RF24Mesh library (which we will discuss thoroughly later on) and was able to get reliable results on a master/node network. The don't-call-it-DHCP stuff seemed to work well, and my node was handed an address of "05" according to the serial monitor.
I was very disappointed to find that it seems that RF24Mesh requires some sort of master node. That means that I may not be able to achieve one of my primary goals: generic nodes. I wanted each node to be like all the others. Having a master node isn't really that big of a deal, but still, it introduces a single point of failure, and means that we have to treat one node specially to ensure it never leaves the mesh. This is NOT what I wanted, so I intend to spend some time trying to avoid it.
Perhaps each node can poll the mesh to see if a master node is present, and if not, launch into "master mode" or something like that. It would mean a bit more code on each node, but then any node on the network could assume the role of "master" since apparently that's necessary for addressing.
Perhaps if the entire network is alive and the master goes off-grid, every other node would soon realize that there is no longer a master node. Each node might try to fight over becoming the master node in that case. Perhaps each node could implement a randomized delay (with steps of 1000ms) and that way whichever node has the lowest random number would most quickly switch to master mode. At the beginning of the master-mode code, a final check would be done to ensure that there isn't another node that made itself master before we try.
It sounds rather exciting really. Someone might want to make a show out of this :)
-
Hello! World? Is that you?
05/11/2016 at 21:00 • 0 commentsThis evening I connected a couple of nodes using the excellent getting started documentation found on this website. I just barely survived the Comic Sans, but I did manage to get these nodes up and running on one of the examples provided by the libraries. I tested each of the six RF modules and they seem to work flawlessly. I'll try and put up a video at some point in the near future.
-
Simulation
05/11/2016 at 01:57 • 0 commentsBefore beginning this adventure in networking, I decided to write up a realistic software simulation of a mesh network. I fired up a new C# project and successfully created an application that will generate a randomized mesh topology with a random number of nodes (within a user-defined range) and will simulate visibility between those nodes. I drew out the mesh configurations it was creating, and after adding in some more variables to ensure the network was spread out enough to be realistic, I called it done. That much of it works well for a decent number of nodes. It does sometimes get angry and not execute if I ask for a network of 254 nodes, but that's beside the point.
Once the network is created, each node is actually capable of sending packets to other nodes (these are several instances of a "node" object). Each node can currently map its immediate neighbors quite reliably. Each node keeps a sort of database of the nodes it can find. I am still trying to learn about topological sorting, which seems to be a rather advanced mathematical process, but I hope to get it working eventually.
Even though each instance of the node object could just send a packet to any other node on the mesh, this simulator also simulates distance between each node. For instance, node 5 might be able to see nodes 1 and 3, but it can't see 4. Therefore, when node 5 sends a packet, 1 and 3 will see it (and subsequently determine whether to accept it or ignore it) and node 4 won't see it. Once the full mapping is in place, one of the nodes that is within 5's range should know how to forward the packet on the next hop to node 4. I have successfully mapped the network up to two hops deep and sent packets over 2 hops.
The full recursive mapping of the mesh is not yet working. I'll keep you posted. It will be a fun sandbox for playing around with these protocols and simulating ideas in software.