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.
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.
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.
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.
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.
Karen’s Status Report for 10/29
This week I was very busy with assignments from other classes, so I did not work on the project as much as I would have liked. I helped Arden with testing his code for LoRa communication, and he was able to get nodes to communicate with each other. I also learned how to use the timer interrupts, and started working on code for sending the node into a low power mode using an interrupt, but I haven’t gotten it quite working yet. My goal for this week is to get timer interrupts to time sending the node into low power and taking measurements with the temperature sensor.
Karen’s Status Report for 10/22
This week I started working with the STM32s. After learning how to use the CubeIDE, I started by learning how to enter Standby and STOP mode and use the RTC to wake up from these low power modes. I also connected a temperature sensor to the nucleo board and got a reading from it using the ADC. I tested it using a hairdryer to see if it responded to temperature changes, and it did. Further testing will have to be done with a match/lighter to determine the best way to detect the temperature change caused by the flame. Arden also got two nodes to send messages using the LoRa transceivers, so the next step seems to be putting it all together so that the nodes wake up from a low power mode, take a sensor reading, send it to another node, then go back to a low power mode.
Karen’s Status Report for 10/08
Unfortunately this week I did not get much done. I thought that the microcontrollers we had ordered had not yet been delivered, and without them I wasn’t able to start assembling the nodes and programming them. I had planned to experiment with sending the nodes into different power modes, but without the boards I couldn’t accomplish this. I did look a bit more into standby mode, and how it might be possible to preserve some of SRAM in that mode. I also started working on the design document with the rest of the team. This week, I plan to start assembling the nodes and programming a node to go into different power modes on a schedule. I also want to get the nodes to take measurements with the temperature sensors. I will likely have to do some work over the break in order to catch up to where I want to be with the project after the break.