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.
Ankita’s Status Report for 11/05
This week was the most successful work week this semester in terms of the capstone project. I had to find a USB keyboard and mouse to use the monitors on campus easily but found an alternative way to create the web application. As Django can be installed locally on my laptop, I used it that way to make the web application and plan to scp it to the RPi when I can. The web application is now working: there is a map that shows our eight nodes as well as two other tabs on the web application created for the convenience of the user. I actually completely scrapped the design that I used in the design report in terms of the APIs and libraries I was planning on using. I was struggling with the app this past week, because I was trying to create an image map (images transposed on one another) but realized it was easier to use Folium, a library used to make maps. It made things way easier to implement and use. I was able to get a popup to show up at the node “on fire” and was able to change its color depending on if it is on fire or not. At the moment, the way of deciding if the node is on fire is through setting the node’s id in the code but will be changed to the output of the network when that is configured. This week I plan on possibly refining the web application more if it seems needed but transition to helping with the network.
Karen’s Status Report for 11/05
This week I got the timer interrupt to send the node into standby mode. I also figured out how to change the timer’s period after it is initialized, so that the same timer can be reused with a different period. I was able to have a timer wait a short time before triggering an interrupt to take a temperature sensor, then changed the period so that it waited a longer period of time before putting the node into standby mode. I also made an external reset button and got a 9V barrel jack so that we can power a bunch of nodes without having to plug them into our laptops and can easily reset them all at the same time with a button. This has made it easier to test with more than a couple nodes. I have also been helping my group prepare for the interim demo this week by helping Arden with testing the STP, and I plan to help him test and debug the LSA this upcoming week.