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.
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.
Karen’s Status Report for 10/01
After talking with Arden, we came up with a plan to have nodes operate on a schedule where they are ‘awake’ for a certain period, then ‘sleeping’ for a certain period. While it is awake, it is listening for a child node to transmit data. Once that happens, it takes a sensor reading and adds it to the received data. If it doesn’t receive anything by the end of its awake period, it will take a sensor reading. It will then send that data to the parent node. After the awake period, it will enter a sleep period where it is put in standby or shutdown mode. We can set a periodic wakeup using the RTC to wake up the node after a certain period of time. I have been busier than expected with classwork so I haven’t had time to look into the synchronization algorithm Arden researched. I will need to catch up this week by looking into how the algorithm calculates the clock offset, and if it’s possible to make sure all the nodes are on at the same time to synchronize the clocks. Once we get the STM32s we ordered I will try putting one into different low power modes and waking it up using the RTC.
Karen’s Status Report for 9/24
I spent the beginning of the week finishing and preparing for the proposal presentation. After speaking with Professor Mukherjee and our TA Adnan about pivoting our project, I started researching ways to lower power consumption in order to make different “power modes” for our nodes based on how much power is left in the batteries. It seems the main considerations will be how long we want the wake-up time to be, what peripherals we plan to use to wake up the node, and whether or not we want to preserve registers and SRAM for choosing which low power mode to use. The STOP modes are in the middle of balancing power consumption with wake-up time, so it might be good to use one or more of the STOP modes when the system is first starting to get low on battery. Which STOP mode is best will depend on how we want to wake up the node. I will have to talk with Arden about whether the networking will require certain peripherals active even when the node is in a low power mode. For even lower power, we could potentially use standby mode. This has a longer wake-up time, will restart the program, and turn off all peripherals, but the trade-offs may be worth it if power is critically low. I am on track to start designing the different power modes for the nodes this upcoming week.