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.
Introduction and Project Summary
Our project is aimed to create a system to quickly detect and notify where these forest fires are occurring. Because forest fires are becoming a major problem in places like California, we are trying to create a system that could quickly notify the public of the fire’s location. We want this system to be low power and time-efficient. We plan to implement a wireless sensor network with multiple nodes where we are able to transmit amongst the nodes where the fire is happening. This node’s (where the fire is “set off”) location will be displayed on a web application. With the resources from this course, we will obviously not be testing it on a large scale, but designing it such that it can be scaled as needed.
We ended up changing our project, this was our previous project idea:
Our project is aimed to create the optimal environment for growing healthy plants, more specifically plants used for medicinal purposes. The target audience for our project is pharmaceutical botanists who farm medicinal plants on a large scale. When growing plants for medicinal purposes, it’s vital that the plants have the appropriate soil pH and soil moisture and that those attributes are being constantly monitored. We plan to implement a system that gathers soil samples from a plant and measures its pH and moisture using the appropriate sensors. The data that is read from the sensor will trigger an additional system to mix a solution that is pumped into the soil to adjust the pH to the optimal level. We want our system to be something that can be scaled up so pharmaceutical botanists will be able to apply this to multiple plants.