Author: abhanjoi

This past week, I prepped a lot for the presentation on Monday and made sure I understood every part of the project. And once again, it ended up being a lot of debugging for everyone. I had to adjust around my web application a lot as well because we initially were going to rescope to only 7 nodes but ended up switching back to 9 nodes so I had to readjust everything again. And while testing, it uncovered a bug in how I was doing some of the web application. Essentially, I was not showing the dead links and adding the links of the STP after showing the dead links. Apart from the web application, I helped debug some parts of the graph code to eliminate nodes from the graph when they are dead and assisted with helping fix the JSON file writing. I had two final exams this week so I spent a lot of time studying for those. Today, however, we settled on how we are planning to demo and got some runs going. I have also gotten a start on the final paper and created slides for a demo to make sure anyone who has never seen our project before will be able to understand the project. We still need to do more testing to measure all of our requirements. I will be reaching out to course staff for assistance in measuring power consumption in the next day or so.

These past two weeks have involved lots of integration of our parts. I had to add some features to the web application to make it more coherent and accessible to the user. Now, each node can be one of three statuses: standard, on fire, or dead. There are also now links between each of the nodes that shows the topology between the nodes and shows what our code is actually doing. These links can be one of three statuses as well: possible link, link being used by the Spanning Tree Protocol, or dead. So now, within the web application a user should be able to see which form of the spanning tree provides the optimal path to where the fire location is as indicated by the rest of our code. I added all of this to a separate Git repository to store all my code and have some version control. All the code from the web application was then moved onto the Raspberry Pi finally and integrated with the rest of the parts. Though those parts are still in progress, I am able to get the data from the nodes and display it properly. There were just some issues with choosing what would be displayed because if a node is dead and on fire, I should be showing on the application that it is dead because there is no way the user will know it is on fire. Those small cases that I never considered were added into the web application. [RESCOPING] To focus attention on the network debugging and the testing aspect of our project, the web application will not include an ability to refresh the page every time the JSON file receives new data. One of us will manually reload the page to show the change in data. Other than that, I have been helping debug the network issues as well as taking the LoRA transceiver’s TOA (time on air) calculations and trying to make functions out of those equations to make it easier for network communication post-presentation and pre-final demo. Hopefully this will help improve timing and help with our “efficiency” later on.

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. 

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.

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.

This week my work on the capstone project hit a bit of an obstacle. I managed to have the web application up and running; however, when trying to add images to the web application I am running into issues. Thinking about how the web application should respond to the network is making me reconsider some of the design details that were stated in the paper. I am planning by next week to have the images working so I can shift my focus to the scheduling in the network when Arden is ready. I will talk to the faculty on Monday about suggestions about the web application and who to reach out to for my issues.

In the past few weeks since the last status report, I worked with the rest of my team writing up the design document. After writing all our individual parts, we spent many hours combining our content into our document. I went home for fall break and took the Raspberry Pi with me. It was difficult to deal with because my home network is not that great but I got our fire-away web application up and running. Right now it is a skeleton web app and simply has text. I am trying to create a database that can take the status of each of the 8 nodes to signal to the application if the node is alive or not but am having trouble with that. I need to figure out how to create some table or database to keep track of that. Debugging some of the setup for the web application did take me some time. I have decided that if I were to create a skeleton that is taking in the data and assist with the actual routing protocol and network and then come back to the application to make it pretty and professional, it would be a more efficient use of my time. Therefore, depending on how much I get done in the upcoming week, I will shift around my individual Gantt chart components to have something worthwhile to show at the Interim Demo. So, I want to get the data inputs up and running but am not sure how to get that working. I will do more research on that and attempt it.