Category: Neha

Earlier in the week, our team spent a lot of time going through our final presentation slides and adding some more testing metrics and quantitative design choices. We wanted to ensure that we were able to address the design and use case requirements and show how our project had progressed over time and what more we will have to accomplish. The main focus of the week was the PCB fabrication. Early in the week, we caught an issue with the PCBs that we had just sent out for fabrication. As a result, Aidan and I had to quickly redesign, finalize, and send out a new order with the updated design. We also added more trace widths that should have been thicker as well as mounting holes for the batteries. Luckily we were able to ask Quinn to quickly send out another order with our updated design and they are currently supposed to come on May 2. This would mean that we would have to immediately solder and test. However, if they still do not work as intended, we would be cutting it extremely close for our May 8 so we would have to solder our parts onto a larger protoboard. 

In order to see if our new design was working as intended, Aidan and I reattempted to print our own PCB using the Voltera. This was the first time using the machine without Quinn and it went really smoothly. We used the new 2.5mm drill bit as well which ended up matching the mounting holes on our display, battery packs, and smoke sensors perfectly. The printing process went smoothly as well. However, when we tried to test this by soldering some components to the board, we noticed that when trying to heat the pad with the soldering iron, it was removing the conductive ink. We didn’t expect this to happen especially with the fact that we baked the board in between printing iterations. We also received our original PCBs with the issues that we caught at the beginning of the week and we are trying to see if we can test the parts without the issues that were found or if that is worth spending our time. Soldering components to those boards are a lot more reliable as well. We are hoping to wait for our new boards as they come in but are anticipating the use of a bigger protoboard as well. 

Simultaneously towards the end of the week, Jason and I started planning out and building our small scale demo. We spent the first day taking a look at the rendering that Jason created and figuring out the best way to do the rooms. Originally, we went into it thinking that we would just be using plywood but after struggling with ways to connect edges together, we started to make proper frames. We cut out the 2”x2” studs as well as some of the plywood for the interior walls, and we wanted to see if we can go to the Hunt lending booth to buy two 2’x2’ clear acrylic sheets so that we can look into the rooms and be able to see the nodes of interest and how the displays are updated as a result. 

Finally, the smoke sensors came in on Tuesday and I was able to interface with them using the ESP32 and get smoke readings. The nice thing about this sensor is that I can use the potentiometer to calibrate the sensor to the presence of smoke. All I had with me was a lighter at the time, but Jason and Aidan recommended testing using incense or blowing out the candle so I will try that as well as look up smoke readings in smoke detectors as well. The datasheet for the MQ-02 smoke sensor also had a list of thresholds for different gasses so I will refer to those as well and compare to find the threshold which shouldn’t be too hard to add into the existing code once I get that value.

In the upcoming week, we have a lot to get done. Our PCBs will be our main priority when the new designs come in. We also will have to start working on a poster by May 2 so it can be printed by May 4. We will also want to complete our small scale demo as well as work on our final report which is due by the end of the week. While this is our home stretch, we will be having a busy week. We are a bit behind schedule in terms of the PCBs as we had to order new ones, but our schedule highlights the small scale demo, poster creation, youtube video, and final report as tasks for the week which is what our current plan is.

This week we spent the majority of our time on the PCB design and fabrication. Earlier in the week, we made the decision to order MQ-02 smoke sensors that came with a breakout board. This is because originally, we thought that because we figured out how to read from the sensors we wouldn’t need the additional breakout board and thus, could directly attach the sensor by itself to our PCB. However, upon more research from last week we realized that if we wanted to control the sensitivity of the smoke sensor, we would need a potentiometer. There are smoke sensors that come with breakout boards with a potentiometer for this reason, and if we just had the smoke sensor on its own then we would have to build a new circuit which included a combination or more resistors, diodes, op amps, and transistors which we realized a) we would be making up the internals of the breakout board and b) it wouldn’t make sense do do seven times for each PCB that we were fabricated. Based on this, we placed a new order of smoke sensors which should be arriving Monday and we already know how to set it up which is great. 

After our weekly meeting with Professor Mukherjee and Kaashvi, we found out the Quinn, the lab technician, was learning how to use the Voltera machine in Techspark that allows us to make the PCBs from scratch. Immediately after this conversation, we reached out to him and he let us send over an initial PCB design that he got started on. On Thursday, we found that some of the holes in our design were too close together resulting in the conductive ink joining pads that otherwise shouldn’t have been connected. Aidan worked to quickly fix these issues and we sent over another design. On Friday, I met with Quinn to learn how to use the Voltera and he walked me through the process using our new design. While the front of the board printed well, there were multiple issues on the back regarding the conductive ink flow. It was not being calibrated properly and a lot of the traces ended up being too thick and the conductive ink would get dragged across the board forming connections that we shouldn’t have on our board. While we didn’t have the right drill bits for some of our bigger holes, Quinn promptly ordered them and I will be going back in on Monday when they arrive to finish the PCB we made and clean up the incorrect connections. While this was a time consuming process, we greatly appreciate the effort Quinn spent with us and we hope that we can make a PCB using this machine sometime next week. There are just a lot of steps that can go wrong, the biggest being the act of controlling the flow of the conductive ink so that it is precise. While it would be difficult and time consuming to do all 7 PCBs in this manner, Quinn helped us place an order through JLCPCB with our updated PCB design which should hopefully come in next week. I have attached pictures of the Voltera at work below.

In an attempt to see if we can find another way to make our PCBs in Techspark, Aidan and I tried to learn how to use the Bantam milling machines as shown below. However the material we had was copper with the middle non-conductive layer so essentially the mill would etch away and leave the copper in the places where the traces lie. We experimented with this for a while after downloading the corresponding software and attaching our Gerber files but we couldn’t find a way to ensure the machine would etch the excess copper away instead of tracing out the exact circuit. 

We have also started working on the slides to prepare for the final presentation next week. This weekend and in the upcoming week, we plan to work on the slides and incorporate components that we have gotten working from the interim demo and beyond. When the smoke sensors come in, early next week, I hope to quickly test them and find a working threshold for fire detection. When the PCBs come in next week, Aidan and I plan to test each sub circuit and confirm that our PCB works as intended or quickly make changes as necessary. With regards to the Gantt chart, I am feeling a bit more pressed for time despite actually being on schedule given that we already sent the PCBs for fabrication and next week will be all about assembling the board and testing its correctness but we will have to act quickly if things don’t go as expected.

This week we spent some time working on integration in preparation for our interim demo. We worked on adding to our PCB design as well as coding the LEDs to work in conjunction with the displays based on some hard coded paths and being able to pick the corresponding direction and highlight its matching path. I have also been working on finding the threshold for the smoke sensor that we will use for our fire detection but am still running into issues where different sources have different values but I am determined to get past this block this upcoming week to even see if we are getting accurate smoke readings based on how we wire them up.

One particular step that I am struggling with is figuring out the best plan of action for our PCB design. While Aidan has also been working on our design, we know that this can be applied to the machines in techspark that we had visited last week. However, there does not seem to be resources available besides youtube videos and manuals which have been our research for now. I have also been communicating with Quinn about possible resources as I had mentioned wanting to do in my last status report, and he had mentioned two embedded TAs but after messaging they actually only have experience assembling already fabricating PCBs. Quinn also recommended using JLCPCB in parallel so at least we have a way of getting these PCBs especially after realizing we might be having a 2 layer board. After our interim demo, we also brought up these concerns with Professor Mukherjee and Kaashvi to which we were recommended to reach out to a student of Professor Carley, Brandon Gonzalez, about our options there as he has done research in the area so I plan on reaching out quickly. 

For the components that I am working on, I have a testing mechanism that relates to each individual circuit. For example, for the smoke and temperature sensors we have created a threshold of fire in proximity to the sensor itself and we will be able to detect if our node senses this fire or not. For the sake of testing, we would be using a lighter or a candle. For the LEDs circuits, Aidan and I have already tested being able to input different North, East, South, West directions and have the LEDs correspond to those directions. We also tested hardcoding a path based on four nodes and three edges allowing us to output a specified path. This was also highlighted in our display which shows some of our initial integration between working with the ESP32 to both the individual LEDs and also the display. In regards to testing the actual PCBs, that would come with assembling them when they come as we want to make sure that based on our Eagle file that we can replicate the circuits that we have already breadboarded. My components relate to the fire detection use case requirement where we specified that 95% of fires are detected and in order to do so one way to go about it is as we keep testing our nodes by moving a flame towards the sensors, we want to ensure that 95% of the time they are detecting the fire, which currently doesn’t seem to be an issue as we have both temperature and smokes sensors. The other design requirement that my components relate to is the use case requirement that we want to show directions in less than 100s after fire detection. Here this integrated the pathfinding computation with downloading time and the time to display instructions so while this combines separate subcomponents, ideally when testing we could time this to see if we are within our limits.

In the upcoming week, I want to figure out how to get precise smoke sensor readings, wrap up the PCB design and either act on a response from Brandon or send out the PCB design to be fabricated in parallel as well as finalize the rechargeable battery circuit to be able to order the hardware necessary (diodes, resistors, battery holders) as well as figure out how that plays into our PCB design. Furthermore, we would like to continue more steps toward integration especially between pathfinding on Jason’s end so that we can make progress away from just hardcoding paths but paths that actually correspond to smoke and temperature data. With regards to the Gantt chart, we updated it with smaller tasks that need to be done to reach our bigger goals and most notably, we pushed back the PCB component of design and fabrication. With these new edits I am mostly on schedule especially when prioritizing the smoke threshold and using that in conjunction with the temperature sensors so I can test them simultaneously. 

This week I finished up the wiring of the smoke sensors that I was stuck on last week. After consulting with Aidan too, we agreed on how we wire the sensors up and were finally able to get some readings. However, we are a bit confused on how to set a good and accurate threshold that indicates a fire as the readings fluctuate from sensor to sensor. I did a lot of research to figure out how other usages of the sensor were related to the presence of a fire and what exactly the output means but am still searching for a definite answer. This part should be a quick fix to the code as we would just create a threshold variable in our code that would indicate a fire if reached, similarly to how we did it for the temperature sensor and it alerted a fire once we got above a certain temperature. 

Furthermore, after our weekly meeting with Professor Mukherjee and Kaashvi, we went to see the machines that allow us to print our PCB on a copper sheet in Techspark. We are still confused on how to use the machine but it definitely relies on an Eagle file which is my goal this week to get a version completed. I would also like to talk to Quinn to see if he has anyone with experience with the machine that we could reach out to for extra assistance. I have a copy of the manual as well which I’ve been reading through but want to ensure that I am going about it properly. We also discussed several backup options regarding the PCBs. While most start with the Eagle file, ideally we can make them in house. But we also have the option to send them out to be made, ordered, and delivered in parallel as well as simply using solderable breadboards/protoboards for each individual node which would be easy to obtain but maybe not the most sleek solution. Finally, the only thing really holding Aidan and I back on the design would be the delay of the batteries as the rechargeable battery circuit is also another component of each individual node. Ideally they would have arrived in the last week like we expected, but they still have yet to come in despite being in stock through Amazon prime. We want to be able to confirm this circuit to work as we have already created small circuits for the rest of the components that make up each node. We can still create the design for the rest of the circuit and add in the batteries when they come in, which is hopefully soon.

In the upcoming week, I want to build the PCB design in Eagle based on everything but the batteries (unless the batteries come in then we can build the entire design for an individual node) and reach out to Quinn to see if we can talk to someone who has experience with the PCB making machines. We also have our interim demo on Wednesday this week so the first half of the week will be spent doing some extra integration of the communication side of our project with potentially the displays. Jason did a lot of great work in the past week which helps to put us in a good place for our demo as a huge part of an entire subcomponent of our system is very close to being finalized. We would just like to further this even more to show some integration between subcomponents for our demo if possible. We plan to take videos as well just in case for whatever reason we cannot show in real time or create some sort of slideshow with these clips if we feel it is necessary. 

With regards to the Gantt chart, I am pretty much on schedule with the exception of pushing back the PCB design as I had mentioned in last week’s status report. Once we are able to get a design going and either upload it to the machine in Techspark using their software or submit it to be printed I will be exactly on track as we planned to start moving our node from breadboard to PCB by April 12 which might be too soon but we hope to get as close to this deadline as best as we can. The other task for this week on my schedule is to start thinking about direction testing with real time smoke and temperature data which is the integration bit that we discussed would be cool to include for our interim demo and something we want to prioritize as well.

This week I spent some more time getting through tasks on our Gantt chart in order to keep on schedule. At the beginning of the week, Aidan and I were able to finish up the demo that we were stuck on towards the end of last week where we were trying to be able to programmatically change the display using the ESP32. We added two images onto the micro sd card that we put the build file onto and we were able to flip between the two images using some Arduino code. We realized that we had to match the baud rate of not just the serial monitor that we had previously been doing but also the fact that we are sending commands between the transmitting/receiver line. That was one of the causes of the issue we were facing last week. The second was the fact that when sending the command to the display, we were just doing a Serial.write of the entire string command that changes the variable from the first to the second image. We ended up switching to writing the command one character at a time before sending the terminating strings. This is probably a good reference for us to switch between different images or a floor plan. But now we have to think about how we will be tracing a path over the floor plan. It seems that the Nextion application might only be used for the background image but all of the other code will be done on an Arduino sketch that will interface between the display and the ESP32.

After we got this working, I wanted to move forward with trying to test the smaller components that make up our nodes, like the 5 LEDs that show the direction and the smoke sensors. During the middle of the week, I coded up an Arduino file that iterated between North, East, South, and West commands and would display the arrow for the corresponding direction on a timer. This was just done through hard coding the four directions and changing which second LED was on because we decided the middle, reference LED will always be one so the user can tell directionally which way to go. Finally, as the smoke sensors only arrived Friday afternoon, I started to figure out how to wire it but it required multiple look throughs of datasheets and tutorials. I already wrote up the code for how to test it but based on my understanding of how to wire it, I created the circuit below. 

My readings for smoke seem a bit off so I want to ensure that I am wiring it up correctly and I might try a different method as the tutorials I’ve gone through mention the use of a fourth pin or simply just three. I want to figure this out by early next week. Further, we only ordered one breakout board for the smoke sensors as we would be using our own version of PCBs for an entire node so we wanted one to ensure the right pin layout. For now, as I am not soldering quite yet, I just used banana plugs to make my connections with the breadboard but eventually we would solder directly onto the PCB we end up using.

In the upcoming week, I want to tune the smoke sensor to display accurate readings. I also have been communicating with Aidan about what our plans are for the PCB in which case I would like to finalize the in house manufacturing method that Professor Mukherjee had mentioned. We had mentioned that in this case we might not need a complex Eagle design but if we do I want to ensure enough time. Beyond this, I would love to get some integration going before our final demo. Based on Jason’s pathfinding code and broadcasting methods, we would love for it to be integrated with the temperature and smoke sensors that we are reading and have it correspond to some sort of helpful output on our display. 

While we missed a little bit of class time due to the ethics lecture, we were able to work on our parts independently outside of class. That being said, I think I am close to being on schedule with the exception of the smoke sensors which I hope to fix early next week. Jason worked hard on the broadcasting between nodes that we were behind on last week so now that task is up to date. The only part I am behind on at the moment is the PCB design because before we thought we would be sending them out to a third party to be fabricated before we had the meeting about the in house manufacturing. That being said, we are prioritizing figuring out those details and finalizing what we would need to do to prepare for that to happen in a timely manner so we would need to push that back on our schedule a bit more.

Earlier in the week, I spent a lot of time working on the ethics assignment. I thoroughly read each of the two articles and dedicated effort to answering the required questions carefully. Then I reflected on the questions that we had relating to our project. Beyond just the ethics assignment, I wanted to ensure that I got the rest of the hardware we needed such as the remaining temp sensors, smoke sensors, and batteries since we made some minor design changes last week. The forms have all been sent out and approved and they all come from reliable suppliers so we anticipate for them to come in sometime next week.

Beyond just the logistics, Aidan and I spent a lot of time trying to figure out how to program out displays. Like I had mentioned last week, the Nextion display software can only be run on a Windows machine so we knew that we were going to have to work together. Earlier in the week, we were having difficulty figuring out how to interface with the code so we made a plan to keep researching separately and then set up meetings throughout the week to try what we had researched on the side. Yesterday, we were able to display a floor plan image of Wean on our display. At the beginning of the week we were unsure how we would be communicating with the display through our laptop as well as the ESP32 knowing that the microcontroller would be the one powering the display. After some more digging around, we found that we need to place the build file in micro sd card that is stored in the display board. The build file would also contain the image that we want to show once it is placed in the Nextion program. After, we power the display with the micro sd, we learned that we would then need to power it off and remove the sd card and restart for the image to be outputted to the display as shown below.

We wanted to keep experimenting with being able to interface with the display by writing code that would programmatically determine which image to show. In our test case, we wanted to be able to simply flip between two sets of images. We had found an example use of an ESP32 interfacing with a Nextion display while collecting various weather related data that would determine what image to show on the display. We altered this code a fair amount to simplify it for our test case, but we unfortunately were unsuccessful in getting the desired outcome of alternating images on a timer. We hope to keep working on this because for the sake of our project, within our pathfinding code we would need to be able to source through images of potential paths where the Arduino code would return some set of indices that are equivalent to the best path and have these indices relate to the image to display. Furthermore, to implement our complex design it would require more experience with the Nextion display software in terms of utilizing their other features besides images that could be of value to us when highlighting the best path on the image. 

In the upcoming week, I would like to keep experimenting with getting familiar with programming the display and continue the test case we started with. If the smoke sensors come in next week, I want to start testing them and see what the range is like for placing a candle in its vicinity. Furthermore, because we ordered just one breakout board just so we can figure out the pin layout for the sensors, I want to test with and without the board as eventually we will be moving toward PCBs in which case the breakout board for the smoke sensors will be unnecessary. That being said, I want to make more progress on my Eagle research or look into what Professor Mukherjee had mentioned about making the in house PCBs with the copper boards during our weekly meeting this week. 

I am a bit behind schedule in terms of working with Jason to receive and handle messages from the pathfinding. We are behind on a bit of the networking aspects like talking between nodes and being able to send alert messages to other nodes. With this, we are going to push these tasks to the following week and make them a priority as these are the first step in integrating our multiple moving parts to be able to work together. 

This past week our team has spent the majority of time working on our design report. We realized that in writing our sections, that some required a lot more detail and consideration than others. For example, we wanted to ensure that we had a thoughtful trade studies section as we had iterated through multiple design choices and we wanted to explain our thinking process behind those decisions. We also wanted to work on improving based on the comments we received from our design presentation with regards to describing the 2 MVPs: the LED nodes and LCD nodes as well as working on improving our block diagrams. We also knew that because we have a lot of moving parts, we wanted to be specific about our system implementation and testing sections so we spent extra time there. 

Beyond just the report, I worked on interfacing with the ESP32. When doing a lot of research on the best ways to program, it was actually recommended to utilize the Arduino IDE. This made it a lot easier and decreased the learning curve. I also researched other IDEs that are compatible with the ESP32 so we have others that we can use, but because our team has the most experience with Arduino, it makes the most sense to start there. It took a little bit of time resetting and rebooting the ESP32s to be in the correct mode but once I got past that issue it wasn’t too bad. I made documentation on setting up and using the ESP32 for the first time so that the rest of my team can follow those steps without difficulty. That is something we are trying to work on as time is making good documentation for issues that we run into so that we can save our other teammates time in the future and not waste time on repeating the same mistakes. Now that I was able to set up the ESP32, I tried to collect temperature data once again but this time with the ESP32 as our microcontroller instead of the Arduino. Attached we have a photo of how we wired up the board to our temperature sensor. 

We also received our displays last week and wanted to start interfacing with them as soon as possible. When Aidan and I were doing research on how to program them, we found that the software necessary is only available on Windows. Because I have a Mac, I might need to look into virtual machines or just work together with Aidan to ensure that we are able to figure out how to wire it up and work with them quickly. We also decided to use MQ2 sensors for our smoke sensors. We received them last week as well and they are not quite what we expected. They are a lot bigger and unfortunately, do not even have a datasheet to know which pins are what. We found its use in one circuit which makes use of another chip so either we figure out if we need to order those chips as well or just use a reliable MQ2 sensor that we will order quickly so we can test and implement them into our nodes. 

In the upcoming week, I want to figure out how to program the display and figure out what pins on the ESP32 are necessary to do so. I want to be able to get more comfortable with using the display so when it comes to integrating the pathfinding instructions, we can do so without so much difficulty. I also want to ensure that we order the rest of our temperature sensors and smoke sensors by Monday because we really need to start interfacing with them and building our nodes. I also want to utilize the LEDs to experiment with how we want to display our path directions and use the ESP32 to specify arbitrary NESW commands that reflect what the LEDs are doing. With all of these separate hardware components, I think it would be great to start planning our the PCB design as well or at least start designing it and learning more about Eagle.

My schedule was a bit pushed back as well due to the design report and I am mostly on track except for being able to figure out how to output to the display. In this task, I am a bit behind. This task will be a huge priority in the coming week in order to get back on track and not cause any more delays.

This week we spent a lot of time preparing for our design review presentation. We finalized a lot of details that we had spent the majority of last week researching. Now that the designs have been primarily finalized, we have placed orders for the Zigbee shields, ESP32-C3 development boards, displays, and batteries. We decided on the approach to just purchase 2 Xbee hats in order to show that in the event of a wifi outage, we have a plan for how we can rely on a source other than the local network which we can explain how to scale up. While presentations lasted two days and we didn’t have that class time, we all met outside of class to work on the hardware we already had, research new parts that had gone out of stock since we requested them, and send out new orders. 

This past week I started to plan out what should be included in the design report based on the provided guidelines. I went through a lot of different examples of reports from previous years and figured out what is most relevant and necessary to include regarding our specific project. For example, from the design presentation we learned that because we essentially have two MVPs: one for the node with the LEDs and another for the node with the display. With this information, we need to ensure that our design report goes into depth for the components that make up these different kinds of nodes. Furthermore, I think a good portion of our report is going to be dedicated to our design choices and how we got to our final design. This is because of all of the research and considerations last week that heavily influenced the design decisions we made for our presentation. With these in mind, I have a layout that I think makes the most sense to follow for our report. I believe I am on track with regards to our schedule and the next pressing item would be figuring out how to output to the display. While the displays have not come in yet that would be contingent on their arrival which I will touch on for my deliverables.

Regarding my deliverables for next week, on Friday, the ESP32s came in as well as the batteries and early next week we plan to see if we can interface with them. From the previous week we were able to test our temperature sensors with an Arduino, but now that we have our ESP32s it will be important to be able to interface with them and ensure that we know how to read and write data from our sensor readings. I anticipate there to be a learning curve but I am hoping that because of our extensive research into picking these boards we were able to prioritize the interfacing capability so that there would be documentation that we could follow. Ideally, our displays would arrive sometime before spring break and we can work on being able to display information that we program on the board. I anticipate this learning curve to be big as well despite choosing displays that are compatible with ESP32 so we would want to ensure that we plan accordingly while still being on track to complete our project. Regarding the nodes with the LEDs, that would depend on the output from our pathfinding algorithm as well but now that we have our ESP32s, we should be able to test that we are able to drive certain LEDs and not others instead of just testing with the Arduino like we had done last week. With these action items in mind, we will also be working on completing our design review report as the deadline is by the end of the week.

This week I spent a lot of time meeting with Kaashvi and the rest of our team to try and finalize the hardware that we want to order. This is because originally we were all under the assumption that the nodes would be made up of arduinos. After looking at the inventory, we realized that if we wanted to use arduinos, it would get really expensive really quickly. So, we decided to branch out to using other microcontrollers and we decided that NodeMCU ESP32 was our best option. Once we figured out this part, we started to move on towards finding the exact Zigbee shields that we needed after learning that these are actually quite expensive as well. Then we started to look for development boards that had Zigbee capabilities included and realized that either they were not released to the public just yet or they came from unreliable sources. As of now, we think our best option would be to use regular NodeMCU ESP32 development boards and buy a couple Zigbee shields just to prove that in the event that the wifi connection went out, we have a working solution for how to get around it when it comes to scaling up for our demo. We put in an order and hope to get them reviewed and sent out as soon as possible. Once we have the microcontrollers we also finalized decisions on the displays which we sent out as well. We wanted to ensure the displays we picked were big enough for users to read while being in a hurry to get out of the building but also compatible with the ESP32s and shipping from a reliable source. Trying to get a balance of these three components was a bit tricky but we think we found a good selection of displays and sent those out to be ordered as well. Further, we are still waiting on our smoke sensors as they were shipped from ebay which will take until March 1, but we were thinking of finding smoke sensors from a more reliable distributor so we can get and test them as soon as possible. Finally, our temperature sensors came in this week and on Friday we were able to use an arduino just to test its capabilities and thresholds using a lighter. We kept note of the delay of recognizing the temperature and how long it stays at a certain threshold before cooling down. We also added an LED to detect certain ranges and turn on/off at different cutoffs. All of these considerations will be present in our design review presentation.

According to the Gantt chart, my progress seems to be on track. It has been a little frustrating not getting the parts completely ordered but I’m glad we were at least able to test the temperature sensor as it aligns with our schedule. Ideally we could’ve tested smoke sensors as well and instead of using an arduino we could use the ESP32s but we only made that decision later in the week so we tried to keep up with our schedule in this way. We were also able to scope the battery requirements and send out a request for the batteries we want to use for each node which is on track with what we had planned. But those orders we placed will likely only go out next week. All in all, I am pretty much on track with what we had proposed but we anticipated a quicker turnaround time for all of the parts that make up the structure of our nodes.

In the coming week, I want to be able to find a good smoke sensor from a reliable source and start testing that immediately. I also want to figure out how we need to wire the battery to the rest of the node so we can be able to recharge it in the event of a power outage and allow this to be the source of power when necessary. Once we figure out how these circuits are configured and the layout of the ESP32s, we can utilize our Eagle research and plan how we want to design and fabricate our PCBs. We also know that our design report is coming up so we want to make sure that we have a finalized plan and can explain any design choices that we make and show the progress we have made towards those plans.

This week, the ECE courses I have been working on the most have been circuits as well as some software systems with the arduino/microcontroller programming (specific courses would be 18-220, 18-349). These courses aided in support for diodes to recharge batteries, arduinos to read data from sensors and power LED, and general decision making and design planning considerations regarding the research we have been involved with this week. Outside of these courses, we spent a lot of time researching online to learn about what is going to work best with our design (ie what sensors/displays are compatible with certain microcontroller, what batteries fit the design requirements, etc.).

This week, I gave our proposal presentation after all of us put together the slides where we made it a goal to focus on exactly where our use case requirements were coming from and how to best address them. While presentations lasted two days and we didn’t have that class time, Jason and I met after class to plan out how we should progress based on our schedule. We quickly met with Kaashvi to determine when we can order our parts as we planned to do so sometime this weekend or Monday. 

In regards to my own research, I started with the sensor research as they are hardware components that make up our node structure and we need to order these parts as soon as possible so we can start reading from them and testing the nodes individually. As for smoke sensors, I was doing research based on Arduino fire detection methods and came to the conclusion that the MQ-02 smoke sensor might be a good bet as it is low cost, sensitive to flammable gas and smoke, and available for different applications. Furthermore, I was debating between DHT-22 temperature sensor (low cost digital temperature and humidity sensor that measures surrounding air but it requires careful timing to grab data) and the DS18B20 waterproof temperature sensor which have good accuracy and works within the temperature range we want while being easily available to connect to an Arduino digital input. I definitely want to get some more feedback before placing the orders and finalizing the sensors. I was also looking into flame detection sensors which could be useful too. Ideally we can go over these choices with Kaashvi and Tamal early next week before putting in the order. 

In the coming week, we would want to ensure that we order the necessary sensors and hardware that make up our nodes. Furthermore, while we wait for them to come in we can do more research on Eagle so that once we start initially breadboarding our nodes, we can seamlessly use Eagle to prep for our PCB fabrication. I also want to do some research on the battery requirements so we have a more scoped out idea of how we will be addressing them. We also know that the design presentation is coming up and we can start planning out the slides and fixing any details that need to be considered from questions that were brought up in the proposal presentation. In regards to our schedule, I am on track with respect to the research but a bit behind with respect to ordering the sensors. We plan to get out on order on Monday so we can get back on track.