This past week I focused on reliable transmission between nodes, like last week. Unfortunately, due to spikes in current from powering the nodes from a laptop’s USB, I kept running into different issues with acknowledgments causing packets to timeout, and the nodes getting stuck in loops where each one waits on the other to transmit…indefinitely. Switching to batteries imparted some robustness in the protocol. Another major change was changing STM to RYLR896 (LoRa module) communications to UART interrupts. By changing the priority of the UART interrupt to be less than the priority of the tick interrupt, the nodes could still maintain a common notion of time while sending commands to the transciever. However changing the code to using interrupts to communicate with the LoRa module required a non-trivial shift of several functions. I also added a reset line on each individual node to reset the LoRa transciever module itself whenever a general reset is performed, and read in the resulting “LoRa ready” command on restart. I also tested the final topology of 8 nodes several times to detect networking bugs.
Arden’s Report for 12/3
These past two weeks, I focused on getting the sensor network to run through the entire protocol stack with all eight nodes. I also implemented ACKs, timeouts, and re-transmissions, and debugged some problems I encountered with communicating with the LoRa modules via UART, when implementing re-transmissions. Going forward, we will be working on testing the topology with eight nodes in a MESH network, and will focus next week on testing power consumption, and robustness to node failures (i.e. if a node drops offline, can STP re-configure the tree to route around the offline node).
Team’s Status Report for 11/19
This week we had further code reviews to familiarize each other with every individual member’s code, as integration between individual parts is starting. We met with the professor and TA about how we would reset all the nodes in the network and how to approach that. Through our discussions, we agreed to synchronize all nodes at the onset by resetting them all at once. If a node were to drop offline, a wildland forest fighter would be able to bring the node online (after having repaired it) at a specific time interval with a 3-5 second margin. We also discussed concerns about integrating our individual parts of the project. The schedule for each of the nodes has been created and includes the receiving and transmitting nodes as well as the order with which the nodes receive the schedule. Essentially, phase 3 of the networking protocol stack has been completed, and the RX/TX schedule is now transmitted throughout the WSN. We are able to synchronize time using a hard-coded time value, that each node’s internal clock will reach simultaneously because they were all reset at the same time. Hence, each node will begin executing the schedule (Phase 4) at the same time. The code for nodes to execute a given schedule is still in progress. Collectively, we hope to test our entire protocol stack on all 8 sensor nodes and the GW running on the RPI by the end of next week.
Arden’s Status Report for 11/19
This week I worked on the RX/TX schedule distribution phase of the protocol stack. Once the gateway router has a complete view of the sensor network topology (i.e after the LSA phase is complete), it calculates a node transmission schedule based on this topology. At the moment, the gateway is being run on an STM32, so an objective for next week is to port the code over from the STM to the RPI, using an external UART library to interface with the LoRa transceivers. Once the gateway router has calculated the schedule, it iteratively sends the schedule out to its children. Unfortunately, due to materials constraints, we have only been able to test these three out of four protocol phases on a network of 4 nodes, and more complications may arise when testing with 8 nodes. We are slightly behind schedule, and using slack-time. For this next week, I will work on:
- implementing ACKs for the schedule distribution phase of the routing protocol, in order to avoid packet collisions (which will arise in an 8-node topology)
- porting the code for the GW node from the STM32 platform to the RPI
Team’s Status Report for 11/12
As a team, we had our interim demos this past week and from those demos, we realized what needs to be worked on more and what needs to be completed as soon as possible to have a good final demo. As a lot of individual parts have come to a resting point (testing the temperature sensors, the web application, and some of the protocol stack). We decided to have a code-review session where we all go over our code to make sure we are all on the same page, so that we can develop in parallel. This mainly resulted in us going over the network code as it is due time for all members to work on the network. There have been some changes to the web application to get it ready and set up for network integration. Next week we will be working on getting the output of the network (which node is detecting a fire) to feed data into the web application. There are some tweaks that will need to be made when the time comes for that, namely, porting code from the STM platform to the RPI platform, and using an underlying UART library on the RPI to interface with the LORA transceiver. The RX/TX schedule is being designed and shall be fully created and implemented this coming week.
Arden’s Status Report for 11/12
Two out of four protocols on the networking stack have been successfully implemented, and were demonstrated on Monday. Furthermore, I changed the packet format (we were using inefficient strings to encode packet information before), therefore increasing the scalability of the code substantially. We are slightly behind schedule, as I had expected to have written the RX/TX schedule last week after the demo on Monday. Nevertheless, I am now much more confident in the robustness of the code, and am sure that we will be able to accomplish at least the schedule-distribution phase of the protocol at the end of next week. I have also been working on making the network robust to node failure: essentially detecting if neighboring nodes are unresponsive during the STP phase (phase 1) of the protocol, and ignoring these nodes during the LSA phase (phase 2). Right now, the gateway node is informed of the overall topology. We have split up the work of the next phase into three items:
- Creating the schedule based on the WSN tree-topology (via an adjacency list).
- Distributing the schedule to all nodes across the spanning tree
- Synchronizing nodes using a pre-computed fixed delay
We plan on accomplishing these three items in the coming week, after which we will be much more on track (as according to our Gantt chart).
Arden’s Status Report for 11/05
This week I worked on implementing the spanning tree protocol and the link state advertisement protocol. These comprise the first and second phase of the overall routing protocol, and are run every 15minutes in order to detect node failures. In our preliminary tests, we tested two four-node topologies: a line topology and a fully-connected topology. After running STP, the line topology did not change, and the fully-connected topology was reduced to a star topology centered at the gateway node (address 1). The image below shows 4 nodes running the spanning tree protocol (one of the nodes is transmitting). Once a tree has been created, link state requests are sent from the gateway node to each of its neighbors iteratively, however link-state aggregation has not yet been implemented or tested. I am now closer to the initial schedule, and next week I will be testing more topologies with more nodes and will work on the sensor-node scheduler.
Arden’s Status Report for 10/29
This week I was able to get two nodes to poll for packets, receive incoming packets, extract the relevant data, and return this data. These functions are modular and use a polling form of UART. As a test, I sent 100 packets from node A to node B using a stop-and-wait protocol (A waited for an ACK from node B before sending the next packet). We are still slightly behind schedule, and the interim demo is quickly approaching. In order to compensate for this delay, I will be working on integrating timer interrupts with my current stop-and-wait implementation in order to port over a previous implementation of STP protocol, and convert it to a distributed TDM version. I plan to accomplish a functional STP by the middle of next week. I believe that with our stop-and-wait implementation, we will be able to easily effectuate the LSA phase of our protocol stack. I plan to get both working phases (STP, LSA) by the interim demo at the latest.
Arden’s Status Report for 10/22
This week I established a communication channel between two nodes. This was a multi-step process involving programming the nodes to use UART communication from the MCU to the LoRa transceiver. Unfortunately two of our transceivers were broken, and will have to be replaced before we can conduct a test of our 8 node and gateway topology. My progress is slightly behind schedule, however, now that nodes can send and receive data the development of the STP and LSA protocols can begin. I plan on getting a topology of 3 or four nodes either establishing a tree topology or gathering link-state and sending it to the gateway. I will be working with Ankita to develop the border gateway side of the routing algorithms.
Arden’s Status Report for 10/08
This week I focused on calculating the power consumption for the design presentation. I used Semtek’s LoRa calculator to estimate the current draw of running the routing algorithm. After getting some feedback on the previous TX-schedule distribution algorithm, we decided to pivot to another approach which was both more power efficient and took less time to run. The final numbers calculated for the design presentation considered primarily a 30min sensor sampling rate, and tree-reforming period. I also spent some time working on the design document, consolidating the various aspects of the routing algorithm, and parsing through essential details. Next week I will begin developing the TDM STP protocol on the dev boards themselves, and will finalize the design document.