The PIC Mesh is a distributed programmable network capable of building motion sensitive alarm systems, automatic lighting, door alarms and various other home automation systems in a matter of minutes.
In this project, we built a mesh network of PIC32 devices using low-cost, low-power nordic radios. We modified an existing nrf24 library to support targeted and flood network messages, and developed a modified version of the AODV (Ad hoc On-Demand Distance Vector) routing algorithm. Our algorithm learns paths through the network as needed, and can therefore support any network topology.
To demonstrate the power of this network, we built a programmable home automation system. Each node in our system has one input and one output, to which a variety of sensors and actuators may be connected. The system is controlled by a 'master' node capable of querying any node's input, controlling every node's output, and setting arbitrary logical relationships among the inputs and outputs of other nodes. Once these relationships are configured, the mesh can operate independently of the master, and can be used for a variety of 'if-then-else' automation tasks.
Our project is motivated by the high cost of existing home automation solutions. We believe the same cutting edge IoT functionality can be delivered at a fraction of the cost, and are using this project as a proof-of-concept of a versatile, configurable home automation system that costs less than $20/node.
To deal with complexity in a project of this scale, we divided the system into the following logical components. These are loosely based on the standard Open Systems Interconnection (OSI) model.
The bulk of our work was devoted to developing, optimizing, and integrating the 3 top-most layers: application, mesh, and radio. These are described in depth here: application layer, mesh layer, radio layer.
In terms of tradeoffs, due to the total budget of the project, it was decided to keep all nodes under a budget of around $15. While this was achieved, one tradeoff was to use only one nRF24 radio transceiver on each chip rather than have a dedicated send and receive chip. This ultimately proved to be a large tradeoff in both hardware and software as we dealt with packet collisions on the hardware side due to the 1-element FIFO included on the radios. In addition, this proved to be a software tradeoff as well as the radios weren't capable of quick transitions from sending and receiving in our code. Because we had to enter a send mode prior to actually sending, if the send function took a long time to execute, then it would not be able to receive during this time. To fix this, we switched to having a dedicated receive and service function with the receive function being an extremely stripped down event-based thread of simply polling the radio layer and placing any received messages on a queue. The service thread on the other hand did all of the packet decoding by reading off a queue and then servicing it. Handling receiving like this gave us more leeway in handling concurrent sends and receives.
In addition, their were also software tradeoffs in the mesh layer due to the performance of the radios. Several filters were placed into the mesh layer to reject influxes of packets due to initial RREQ requests. In addition, the mesh network had to be made more resilient to be able to handle this so the inclusion of several flags were put into place to prevent servicing of multiple types of the same message to occur. Another tradeoff was made in testing. Due to budget constraints, we were only able to develop around 5 boards which meant we weren't able to fully test the mesh network's capabilities. Despite this, due to our abstraction layers, the application layer did not have any tradeoffs which were made due to hardware or software.
Because we were split into 3 groups, results came at leaps and bounds. This is where abstraction helped - while one person was writing code for mesh layer, another could be testing dependencies on application layer while another soldered boards for hardware layer. True results finally started coming in when we started integrating our layers. We found that between 2 nodes, communication was near perfect, and that we could easily use applicaiton layer to set and remove dependencies on any general node ID with no dropped packets. We used a TFT display to verify that all packets were being received, and that the appropriate functionality was being set on the general node.
Moving forward, we attempted to send to 1 node when there were 2 nodes in range of the master node. It was here that we started to drop packets at the hardware layer. This is because the nRF radios have a built in auto-acknoweldgement packet that is sent out when a pakcet is sucessfully received. So, even if one of the radios received a packet, the other could have not received it and the master node would have thought that all was well, even though the packet was not received by the correct node. This was further frustrated when the pipes for the radios did not work with our given library for our desired implementation.
We resolved this issue by disabling the auto-acknowledgement bits for the radios, but by manually retransmitting a set number of times for each radio. This seemed to alleviate the problem for smaller number of radios, but for large numbers, there may be packet collision at higher numbers of nodes. Ultimately, we were able to properly send packets between 2 radios.
The next step was testing the mesh network. For this, we took 1 radio outisde of the range of the master node, and 1 radio in between the two. The way the mesh network functioned is that it sent a flood packet to the middle node looking for the destination node. The middle node would hear the flood and send out its own flood looking for the destination node. Upon hearing the middle node's flood, the destination node would send a return flood packet, which would be heard by the middle node and forwarded to the master node. The master node would then be able to construct a path through the middle node to communicate with the destination node. This allows for the master node to be able to communicate with nodes even though they are out of range, one of the key functionalities of a mesh network.
Very few quantitative results were able to be taken because the project was to create a programmable system rather than measure or affect the environment.
In conclusion, the mesh network performed well given the constraints of having a single on-chip nRF24 transciever chip for both sending and receiving. The mesh network was tested with up to 5 different nodes communicating and dynamically discovering paths. This worked well despite the packet collisions and the vast majority of tries for the nodes ended in success with a path being placed in the corresponding caches. One limitation of this testing is that 5 is a relatively small number in a realistic application. Ideally, we would have 100 or more nodes so that the mesh network can fully show its throughput under high stress. In other words, we weren't able to take advantage of the unique advantages a mesh networking protocol provides due to time and monetary constraints.
Despite this, we were correctly able to verify multi-node paths by constructing several test cases with out-of-reach nodes and/or by using physical attenuation or softare attenuation to simulate distance. These tests verified the consistency of multi-node hopping. We were also able to verify path discovery in multi-node systems of up to 5 nodes. In these systems, the network will see more traffic in the form of RREQ floods and RREP messages during route discovery stage. However, by carefully adding software filtering of these packets, we were able to ensure performance remained stable even during high-activity situations.
The radio layer was able to acheive reasonable power budget and performance based off of the tight budget it was given. The final nodes created could be optimized to be as cheap as 8 dollars per node. Although this requires more software to be developed to deal with the burden of the hardware, it couldnt stem the flood of errors that spawned from the cheap hardware. There was a lot of effort put into debugging the radio layer due to the nRF24L01 radios being extremely unreliable. There were numerous modifications made to attempt to lower the packet drop rate. We tried varying channels, using varying pipes, changing transmit frequency, transmit powers, transmit rates, swapping between radio hardwares, modifying transmit software, modifying mesh layer radio software, attaching decoupling caps to hardware, retransmit delays, retransmit counts, auto-ack packets, specific node addressing, and basically every possible aspect of the radio configuration that our library allowed us to modify we experimented with at some point.
In future iterations, it would be most helpful for 2 radios to be used as one of the fundamental problems is that the nRF radios cannot transmit and receive packets at the same time, and will suffer from packet collision if they receive two packets at once. This causes very unexpected behaviour and increasing rates of failure as the number of nodes in communication range increases. Another difficulty is that communication range is not a specific black and white area - there's a grey area between which we would receive about 50% of packets, and walls and obstacles would also drastically affect the packet drop rate of the radios. Ultimately, the hardware layer suffered immensely from faulty radios and lack of utility from the nRF24L01, but still managed to sustain reasonable packet success rates at low enough node count.
The application layer worked reliably in all tests we conducted so far. We were able to query multiple nodes, configure parameters, force node outputs, and link node relations. All failures in these tasks stemmed from message transmission or reception failures in our radio modules.
Overall, we were able to acheive many of the goals of our final project. While radios turned out to be more fickle and mesh algorithms far more difficult than expected, we were able to demonstrate functionality as desired. We were able, in our demonstration, we were able to demonstrate the functionality of our mesh network to create and remove dependencies between different nodes, and show how our mesh network was able to dynamically create paths between nodes that were known and unknown to the master node.
Future work on this project could involve superior hardware, optimized algorithm for mesh routing, and even more application support to allow for this project to become a fully independent, low power, and highly customizable system for almost any application.
In regards to standards, we loosely followed the Open Systems Interconnection model during development. We strictly defined three orthogonal layers: application, mesh, and radio which were developed independently. This model allowed us to parallelize development on each section by defining a simple communication interface between layers. Overall, this lead to a top-down design with the radio layer being abstracted to the mesh network layer which is then abstracted to the applicaiton layer. In addition, the software follows basic C guidelines by including interface functions and variables as a header file and placing all prototypes and shared variables in a header file to be included by other layers.
The mesh networking protocol which was modified for this project is the Ad hoc On-Demand Distance Vector (AODV) Routing protocol mainly used for wireless ad hoc networks. This protocol was jointly developed on July 2003 by Nokia Research Center, UCSB, and University of Cincinnati. This algorithm is well-documented online interms of high-level implementation. All of the code written in regards to the networking was developed using these documents as only a reference. In the end, the networking algorithm used borrows from AODV as well as other routing algorithms.
The nRF24L01+ library used for this project was adapted from a previous ece4760 project by XiaoXing Zhao, Fred Kummer, and Douglas Katz. In addition, the idea for applying this system as a home automation system draws inspiration from one of the team member's previous ECE 3140 projects. Overall, no patent claims or any other IP concerns have been breached throughout this project as all of the hardware and software were developed orthogonally from any other project while only using open-source material as references.
In regards to ethical concerns, this project was not made for profit, nor was it made for a specific goal other than to serve as a final project for ECE4760 and also as a great learning experience for the team. The provided documentation for the project is realistic and does not attempt to hide any shortcomings of the project and exposes all design flaws as well as design choices due to constraints.
Please note the following section is heavily based on the IEEE code of ethics page .
We accept responsibility in making decisions consistent with the safety, health, and welfare of the public, and to disclose promptly factors that might endanger the public or the environment. There was no bribery taken or given with regards to this project. We attempted avoid real or perceived conflicts of interest whenever possible, and to disclose them to affected parties when they do exist. We were honest and realistic in stating claims or estimates based on available data. Our project aimed to improve the understanding of technology, its appropriate application, and potential consequences.
As consistent with the course, we hoped to maintain and improve our technical competence and to undertake technological tasks for others only if qualified by training or experience, or after full disclosure of pertinent limitations. We activley seek and accept honest criticism of technical work, to acknowledge and correct errors, and we have properly attributed the contributions of others. We have treated fairly all persons and to not engage in acts of discrimination based on race, religion, gender, disability, age, national origin, sexual orientation, gender identity, or gender expression. Our project aims to avoid injuring others, their property, reputation, or employment by false or malicious action, and actually hopes to reduce criminal activites in real world applications. We actively assisted colleagues and co-workers in their professional development and supported them in following this code of ethics.
As stated on the Nordic nRF24L01+ datasheet, in order to comply with FCC regulations concerning operation of low power, non-licensed transmitters, we must operate in the 2.4-2.835 GHz frequency range and also must use an emission limit of 50000 uV/m @ 3m. Fortunately, this specific RF transciever chip falls directly under these categories.