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.
Team Status Report for 12/10
This week has been primarily centered around debugging for everyone. There were some flaws in the network, mostly caused by using the usb port of a laptop to power the nodes. Current spikes from the power supply caused unexpected behavior from the transceivers, and we had a lot less transmission issues when we started using batteries instead. We are thankful that Adnan suggested that we test our network with batteries. Furthermore, some acknowledgement schemes had timing flaws, which stemmed from timer-interrupts getting blocked in each STM, leading to variable timing, and unproducible bugs. It turned out that the JSON file was not writing from the network correctly so that was adjusted as well. The graph needed to be parsed in an alternate way. We have been working on getting a bunch of tests running as well as getting a video for the demo. We have decided to delay testing power consumption until after the demo for convenience and grappling with any final exams or projects people might be preparing for.
Karen’s Status Report for 12/10
This past week has been a lot of debugging. I have mostly been helping Arden run tests with the network to try to debug the transmission issues we were having. I also ran a bunch of tests with Ankita to get more data on how often our network was able to successfully run all the protocols, and which protocols it was failing in. I realized during testing that the code I had written for parsing the information from the graph of the tree was not correct. Ankita helped me write code for walking through the graph, as well as a test case so we could test locally before moving it to the RaspberryPi. I integrated that into the code for writing to the JSON file, and after testing that it worked locally I pushed it to the RaspberryPi. When we ran tests with the full system, it accurately recorded active links to the JSON file and we could see this reflected on the WebApp. I added heat shrink and some hot glue to the temperature sensors to ensure that the leads would not touch each other and that they were less likely to break off the sensor. Leading up to and after the demo, we will be running more tests to determine how accurate our network is and measure the power consumption of the nodes after the demo.
Ankita’s Status Report for 12/10
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.
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 Status Report for 12/03
Since the last status report, we focused mainly on integration amongst all of our individual parts. The web application now works with whatever data is provided to it via the json file generated by our network code. It is able to show all the links that are being used by the Spanning Tree Protocol and indicate what nodes are “caught on fire.” All the temperature sensors have been added to each of the nodes, so all the nodes are now completely constructed. The main bottleneck has been actually getting all eight nodes in the network to actually work. We are having issues with the packets communicating with one another. We are getting many errors and bugs related to transmissions between the nodes and are unsure of the origin of the errors. A lot of it seems to be timing issues and issues with retransmitting packets. We were having issues with testing the entire topology so we ended up paring it down to only four nodes to get that working reliably before scaling back up. Other than debugging, we have been working on our final presentation and prepping information that would need to be included in our final paper as well.
Rescoping:
There are a few things that are being rescoped in the context of our project. When we are doing our schedule distribution phase, we are assuming a certain amount of packet losses. So in the fixed time span from our Phase 3/Scheduling Phase to our Phase 4/Data Phase, we are planning on assuming that there are N packet errors only that can occur in that time frame. In addition, the web application isn’t going to be automatically reloaded every time the JSON file contains new data. The web application will be manually reloaded by a member of the team. We have also removed NTP from our protocols because we would not have finished that in one semester and would have taken much longer time.
Karen’s Status Report for 12/03
Arden integrated my schedule code into the main code for the nodes, and I’ve made some adjustments since the integration. One of the changes I made was improving the temperature sensing for fire detection. I used a hairdryer to test how much the ADC measurement changed after being heated up for a few seconds. I used these tests to find a good threshold for how much of a temperature difference over a short period of time should indicate a “fire”. I noticed that the reading on the ADC consistently dropped a bit from the first reading to the last reading, so I also took some unused measurements before taking the “start” temperature measurement in order to warm up the sensor. I found that there was less change between readings after that. I also took the average of a few measurements to get the “start” and “end” temperatures, just to make the sensing a bit more consistent. I also added code to put the nodes in standby once the schedule is done executing. Previously the nodes would just print that they should go into standby, now they actually do it. During testing, when the nodes successfully reached the end of the data phase the nodes would come out of standby within 1 second of each other. This makes sense given that they are using a 1Hz clock to determine when to wake up from standby. Finally, I wrote the code for parsing the graph of the tree and the information gained during the data phase into a json file for the web app. I found a library called json-c, and initially tested it on a fake tree and fake data. In tests with the nodes that reached the end of the data phase, the web app accurately displayed the tree. We have not yet been able to test with the fire detection to see if it accurately displays a node detecting a “fire”, or what happens when a node goes offline.
Ankita’s Status Report for 12/03
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.
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