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
Karen’s Status Report for 11/19
This week I worked on the code for the nodes to execute the schedule they were given. The beginning of this week was mostly the team hashing out the details of how the schedule is structured so that we could all work in parallel. I referenced Arden’s code for the STP to learn how he got the nodes to communicate with each other, and used that as the starting point as that is likely the most difficult part of timing the schedule. I started with just printing statements about what the node should do in each time slot given a test schedule. I would check if the current time slot was a transmit slot, a receive slot, or if all the time slots had passed and it was time for the node to sleep. Once that was working, I used some of Arden’s functions for transmitting with the LORA to test if two nodes would communicate with each other according to the schedule. Initially I was calling a function to execute a time slot in the timer callback when tim16 interrupted. Arden was using the callback when tim2 interrupted to increment a counter used for timeouts in his LORA functions. Because of how the callback works, this meant the tim2 counter did not increment while my tim16 interrupt handler was running and if I called a LORA function to transmit or receive data in the handler it would not time out. I fixed this by moving the function into an infinite while loop in main, and have the tim16 interrupt set a boolean value to indicate the start of a timeslot. Now I have successfully gotten one node to send a packet to another node in a given time slot. Next I will make a packet structure that will be used to communicate to the gateway which nodes have detected fire and which are offline, and make it so parent nodes include data from their children in the packet they transmit. Once that is working, I will add in sensing for a fire during the transmit time slot and put the node into standby when the node is supposed to sleep. Then I will have to integrate my code with the rest of the team.
Ankita’s Status Report for 11/19
This week was primarily spent on the network scheduling. I needed to create a structure from the topology provided to me that maps out which nodes would be receiving and transmitting at what time slot as well as which node will be getting the schedule in what order. This involved using some of the structures created by Arden and making my own data struct that had all these elements of the schedule. The way I approached it was walking through the topology using an algorithm similar to Breadth First Search, where each “level” of the tree was looked at separately. However, we look at the leaf nodes first and then move up to the higher-level nodes. I then kept track of the nodes that were being looked at and their parent node to determine what is transmitting and what is receiving. This was all added to two separate adjacent lists allocated to a buffer size of one less than the number of nodes. In terms of the receiving order, it works using the quasi-Breadth First Search method and sends it to all the nodes on higher levels. I tested this with a few different topologies to make sure it works: a line topology of four nodes, a tree of all nine nodes that we use in our design report, and a mesh topology of four nodes. The schedule is printed out to see the order. Working on the schedule exposed some bugs in the code, but those were quickly resolved. This is now being integrated into the rest of the protocol. Now, as more of the network is being resolved, I need to figure out how to build the backend of the web application and take input from the network.
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).
Karen’s Status Report for 11/12
I added a temperature calculation for getting a temperature in celsius from the ADC reading from the temperature sensor. I also cleaned up my code for going into standby mode and getting a temperature reading. I made separate header and source files for the standby function and temperature reading function, so that down the line integrating the group’s code together will be easier. As a group we discussed potential ways of handling the fact that the nodes need to start the STP protocol at the same time in a real world environment. One of the ideas was using an external real time clock with its own battery, so I have been researching how to use one with the STM32. I picked one up from the physical computing lab in IDeATe, and plan to try using it this week. I also started writing code for the nodes to transmit to each other on a schedule. It currently just times how long to wait until transmitting and how long to go into standby mode given the number of time slots and its TX slot, but I will work on it more once Ankita writes the code for creating the schedule.
Ankita’s Status Report for 11/12
The web application has been for the most part completed and since the demos some more features have been added to make the interface more user-friendly. The “About” and “How to Use” sections have been flushed out in terms of the words that are used to describe it. The map has been slightly adjusted so that all the nodes are as equidistant away from each other as possible to replicate our smaller-scaled future demo. Now, instead of just a node turning red when there is a fire (there is a change in some of the graphics here now too) it is also able to handle when a node dies. This means that the node has gone down in the system. This is currently also being hard-coded with a boolean flag, causing the node to turn gray to signify it being inaccessible. This code has been set aside for now and needs to include a json file input but that will be adjusted when the network is complete. Since then and our various team meetings, I have been sick and have not been super able to do work while in quarantine. However, I am now working on creating a schedule for our network to determine if it is under RX/TX. This transmission schedule is beneficial to work with the rest of the protocol and needs to be completed for a lot of the rest to continue. At the moment, my design for the schedule is a framework but is in the process of being implemented. The plan is to have this done during the week so that Arden will have it ready to transmit the schedule amongst the nodes and Karen will have it ready to execute the schedule.
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.
Team’s Status Report for 11/05
As a team we decided to try to finish as much as possible to show our working parts of the project in the interim demo. We met twice outside of class time to work on our respective parts of the project. We built five nodes and powered them with a 9V barrel jack and created a reset button that resets all the boards when pressed to make testing the networking with many nodes easier. We also implemented Spanning Tree Protocol (STP), the first phase of our routing algorithm, as well as LSA (replicated on a node instead of on the RPi). In order to test the topology, we gathered logs over UART from 4 nodes, and checked that a line and fully-connected topology were reduced to a line and star topology, respectively. In a separate program, we got a node to use timer interrupts to time taking a measurement from the temperature sensor and go into standby mode. The web application was finished as an individual part of the project and is waiting until the remaining of the project is done to be fully integrated. The expectation is that the network will be the focus for all of us in the remaining weeks.