Weekly Status Reports

Team’s Status Report for 04/25/2026

The most significant risk to our project right now is the accuracy of the heart rate sensor. We are currently using a peak detection algorithm that needs refinement, as while it works well on the finger, it does not work well on the upper arm where we intend for the wearable to sit. To mitigate this, we may need to shift the position from the upper arm to the wrist. Another risk is the development of the messaging for the app that is still in progress. If we cannot get these working, we can downgrade to a simpler messaging system if possible. In the coming week we are looking to address those two risks, integrate our system into the armband, and test out system in the real world. While no official changes in our design have been made, as we still intend to work towards our original design for the demo, there may be some tradeoffs made in the interest of time.

Vidhi’s Status Report for 04/25/2026

This week I kept working on the direct messaging for the app. I did not expect this part to be as complicated as it is turning out to be, and I have spent a lot more time on it than I had intended. I also did some field testing with the app. I got people in different age groups to try it out on their phones and see if there were any features I could add to make it more user friendly. There was some overlapping feedback that I implemented while Emily and Sharia were working on integrating the hardware and firmware. I also worked with Emily to make sure that the app was getting readings from the sensors and we got all of that working. This coming week we need to work on the final system integration with the pcb sewn into the arm band and well as the poster and video for our final demo.

Sharia’s Status Report for 04/25/2026

This week, I helped Emily debug spi and i2c by helping her solder stuff, oscope, and narrow down some clock issues. Unit tests included testing for shorts and whether every individual circuit was working. I believe there is an issue with the ambient temp sensor circuit still, and I think I have the issue narrowed down. I’m just waiting on our last mouser package to arrive and will reflow the new pcb as soon as it does with the fixing changes. Progress seems to be good, I think we should have a couple days left for testing as main integration is complete. Next week, we hope to have our working final project with the video and chart.

Emily’s Status Report for 04/25/2026

This week, I prepared for the final presentation. I also debugged the SPI for the heart rate sensor and was able to get reasonable values for my finger. Next week I will primarily be working on tuning and testing that on the arm, as the design intends, to be able to get accurate readings. The sensor has a lot of different led configurations, and have implemented a find peaks function to detect heart rate, so those are the aspects that I will edit to refine the heart rate sensor implementation. 

I also integrated the firmware & hardware, with the software. Our system supports BLE and we were successful in sending our reading from the sensors and our state to the app. This was a major milestone in integration. The final thing we have left to do (other than refining the heart rate system) is to assemble the physical armband, and add in the power system (aka the battery) so that we don’t have to keep it hooked up to a power supply (which is how we have been currently debugging and testing).

Overall there have not been any changes to our design, but if we are not able to get the ambient temperature sensor working, we may forgo that part of the design and only use the body temperature sensor. Hopefully, we can pull together a final product in time for the demo.

Team’s Status Report for 04/18/2026

The most significant risk currently facing our project is the time we have left. While we have been making significant progress, debugging and testing requires a lot of time. To mitigate this we have all put in a lot of hours into this course over the past couple weeks.  We are currently debugging issues in pcb+firmware integration and hope to have all the parts working by the end of this week. There haven’t been any official changes in the design since last week, but if we are unable to get the ambient temperature sensor working we may exclude it as it is not vital for our project, but would be nice to have to make our system more accurate.

Emily’s Status Report for 04/18/2026

This week, Sharia and I integrated the firmware with the pcb. To test that everything was working accordingly, we started with isolated testing of our peripherals before flashing everything. I started with a gpio test by setting our motor enable high. Then once we confirmed that that was working, I tested the pwm signal for the buzzer, turning it on and off with the emergency button, also testing the button functionality. 

After that I attempted to integrate the sensors. I started with the 2 temperature sensors as they both used i2c protocol. I confirmed that my i2c was working on the dev kit while not on the pcb so we were able to find and fix a short on our SCL line. Our body temperature was successfully integrated with the firmware, however, the ambient temperature is not sending a ack upon receiving a write command for initialization. Sharia and I tried to debug this on the oscilloscope and it appeared that the sensor was trying to send the ack but was quickly pulled high again and unable to do so. We believe that the sensor may not have enough drive power to pull the SDA line low but we will continue to debug that in the coming weeks. Since we have the body temperature sensor, which is more important for our project, we moved on to start integrating the heart rate sensor that uses the SPI protocol. Not much progress has been made so this is what I will focus on next week. Once that is done, I should be able to integrate all the peripherals with my state machine logic that I have already tested with mock sensor values. 

Next steps also include integrating the pcb with the BLE which is currently integrated by the firmware and software levels as of right now. I also will need to sew up the physical armband which will be the culmination of our project and make it ready for real word testing. 

As I have designed, implemented, and debugged mainly the firmware for this project, I have found AI, specifically cursor to be very helpful in generating tests for each of the peripherals, including configuring settings for each separate build. This work can be very tedious and unintuitive when done by hand, so this has allowed me to focus more of my time on actually finding where things went wrong. Because it is so easy to to do this, I have learned to modularize my testing, testing each component in isolation to be sure there is no conflict from other parts of the system. I have also learned a lot of skills in firmware over the course of the semester through the research I have been working on. Although that project uses a different mcu and focuses more on UART communication which we don’t use in our project, I think the process of programming, integrating with hardware, and debugging is largely the same and best improved with practice, and getting better at it slowly over time. Lastly, my knowledge coming into this course from 18-349 was very helpful.

Sharia’s Status Report for 04/18/2026

This week, I finished up the pcb fully. There were some hardware issues that I fixed and tested voltages and can assume the pcb works for now. It is almost the last week so I’m mostly trying to help out wherever I can in testing other aspects of the project while we finalize integration. As a result of designing and testing my part of the capstone, I feel like I’ve learned a lot. Firstly, I can say my soldering/reflowing skills have significantly improved from soldering so many boards and I better understand what to look for when designing pcbs. One significant design flaw in the boards I made was that I didn’t make it super testing friendly, I wish I had included a debug LED and testpoints for easy access, things that I overlooked in my eagerness to have the design ready ASAP.  Another mistake I made was that I chose really small parts in my attempt to make the pcbs as small as possible. In hindsight, I realize that the tradeoffs between ease of assembly and having a really small pcb is a significant consideration. Some learning strategies I found useful were youtube videos of people designing certain types of circuits on Altium. Even though our use cases were different, I was able to take inspiration from their thought processes behind choosing certain components etc. I also referred to online forums for general knowledge pcb questions and design considerations.

Vidhi’s Status Report for 04/18/2026

This week I worked on fully integrating the BLE on both the firmware and hardware sides. I also worked on getting the emergency messages sent, but I have not been able to make much progress. This is a feature of the app that I did not foresee taking as long as it is taking. As a result of designing and implementing my part of the capstone, I have learned very much. I was never too comfortable with software, especially high level coding languages. Writing an app was quite out of my comfort zone and I had to do a lot of research before I could even begin my part of the project. As a result, I have become a lot more confident in my coding skills. I have also gained a more holistic view on how hardware, firmware, and software interact. I also have learned to work in small parts and build up, instead of just tackling a project as it is. I learned a lot from online forums like StackOverflow and even Reddit. A lot of people have done personal projects and have wonderful documentation of how they built their project, mistakes they made, things they wish they knew earlier, etc. I also learned a lot from the Apple developer website. Lastly, I learned to learn as I go. I was constantly hitting road blocks because at first I did not know what I was doing. But I learned from each mistake so even though the progress started slow, I was able to proceed at an exponential rate.

Team Status Report for 04/04/2026

The most significant risk currently facing our project, remains the same as last week. Our delayed integration with the pcb with ultimately eat away at our time for testing, even though we gave ourselves buffer time. We have continued to mitigate this by trying to modularly test our subsystems. No changes have been made in our design since last week.

Emily’s Status Report for 04/04/2026

This week, I worked on understanding how the syntax of the overlay file needed to configure all the gpio, i2c, and spi devices, that the nordic mcu requires. While I have not been able to test my drivers on the pcb, they are definitely ready for testing. Since the rest of my firmware has also been tested I am waiting on the pcb to start more comprehensive tests. In the coming weeks I will hopefully be able to start testing my firmware with the pcb and also work with Vidhi to implement and test the bluetooth between the firmware and the app. I also plan to start working on the physical setup of the armband.

Sharia’s Status Report for 04/04/2026

This week, I finished up reflowing the pcbs except for the one IC that I’m waiting on. Project is a little behind schedule as I should have started testing by now. I will try to catch up next week by working on the verification part. By next week, I hope to have most of the pcbs tested for voltage and signal integrity. For verification of my subsystem, or the pcb, I plan on first double checking for soldering shorts and making sure everything is electrically separated. Then, I plan on connecting the pcb to a power supply and seeing if all the voltage levels are as I expect, pre and pose ldo and buck boost converters. If all voltage levels are as expected, I will continue by flashing the mcu with our firmware and using an oscope to study the signals being sent over the i2c and spi rails. Then test to see if the components are able to reliably send signals over and talk to each other.

Vidhi’s Status Report for 04/04/2026

This week, I began to work on the BLE protocol, but I have not yet gotten the opportunity to do much testing. I always was able to figure out how to get the app to send messages to other people. The next step is integrating all the subsystems together. I have done some research on implementing the BLE protocol but we will do that together during lab time this coming week. After that, we will test the device on people as they do different levels of exercise to see if it malfunctions/sends out false positives, etc.

 

Team’s Status Report for 03/28/2026

The most significant risk currently facing our project is the delay in our integration which will lessen the time we have to actually debug issues with our system. We’re trying to mitigate this by individually testing whatever subsystems we can so that we can narrow down issues later while we wait for other subsystems to be ready for integration and testing. No changes were made to the design since last time, we’re just continuing to work on the same things as last week.

Emily’s Status Report for 03/28/2026

Sharia’s Status Report for 03/28/2026

This week, I started reflowing the pcbs with what I could using the parts that have come in. I still have to reflow the main pcb since we’re missing some parts for that but they should arrive early next week. I think I am a little behind schedule and plan to catch up the following week by just working on reflowing the pcb until I’m done with all of them. I also anticipate there to be issues with shorts since the components are small and pads under the components instead of visible pins. By end of next week, I hope to have all three board reflowed and verified to work with reliable soldering.

Team’s Status Report for 03/21/2026

The most significant risk currently facing our project is our collective lack of experience with the BLE configuration, which could delay integration. To manage this, we are focusing our effort to testing all the other firmware modules so that we can develop the BLE functionality without having to worry that there are other issues. Additionally to mitigate the delays in getting our components, we have decided to start implement mock testing and overall keep our testing modular to isolate the problems that we encounter. No major changes were made to our system. Another major challenge that we encountered was that we lost a lot of code because Vidhi’s computer had to be wiped. This has set back the timeline of the app development, although Vidhi is confident that the second time around will not take a lot of time as she has already familiarized herself with Swift, and she believes the app should be completed by the Interim demo. In the coming week we will continue to re-develop the app, modularly test the firmware, and start reflowing the pcb when it comes.

Vidhi’s Status Report for 03/21/2026

This week I had to do quite a lot of work on the project. My laptop had broken and I lost a lot of the code for the app so I spent time rewriting it. I also worked on the firmware implementation of the PSI algorithm. The app will be done in its entirety by the end of Monday, and then I will implement the timing module in the firmware. Once the pcb comes, we cant focus on testing the BLE configuration, because that it something none of us have experience in.

Sharia’s Status Report for 03/21/2026

This week I was not able to get as much done since the components are not here. I began working on gpio config firmware and hope to be done with that by the end of the weekend. I’m behind schedule since the parts are not here yet but once they arrive I will get to work immediately, reflow them so we can start testing right away. By next week, i hope to finish up the pcbs completely and have majority of the firmware done to test.

Emily’s Status Report for 03/21/2026

Teams’s Status Report for 03/14/2026

The most significant risks are the ones associated with the dalay in ordering parts because that shortens the time we have for integration before the interim demo deadline. We plan on mitigating the risks from this by working on and finalizing everything else while we wait for the parts to come in: firmware, testing and app. That way, as soon as the parts come in we can assemble the pcb and get to testing asap. We haven’t made any changes to the design from last time, all of it is pretty much the same. The updated schedule shows that pcb testing has been pushed back a week, leaving less time for our interim demo preparation on the 30th.

Emily’s Status Report for 03/14/2026

I was hoping to have a finished draft of the firmware by the end of this week, but I am still working on finishing up the battery management module and have yet to configure the gpio pins. For the coming week I plan to have the firmware completed and ready for testing. I will also hopefully, with help from Sharia, be able to run a mock test to make sure the state machine is working correctly, and use similar sensors to our from TechSpark to test to see if I am able to get readings and process them correctly. I think that regardless of when the pcb comes, we should test the firmware separately to make integration as seamless as possible. This week I also started to design how exactly the physical armband is going to be made and am planning on ordering the materials for that next week.

Vidhi’s Status Report for 03/14/2026

This week I was not able to get as much done as I had hoped since I had a lot of technological issues. I used the time without my laptop to do further research about the PSI and how it has been used in the past to detect heat exhaustion. I came up with a strong testing plant for our device. I need to use the next week to refine the app because right now it is not user friendly. I also need to finish implementing the algorithms in the firmware.

Sharia’s Status Report for 03/14/2026

This week, I submitted the BOM and fixed some issues on the pcb order. Progress is behind as we should have had the pcb some time early next week, but I’m not sure if it will arrive by then. Since there’s not much to do hardware-wise until the parts arrive, I plan on helping out with firmware so we can be as ready as possible for when the pcb does arrive. By next week, I hope to have the pcb reflowed and ready to be tested and flashed.

Team Status Report for 03/07/2026

One of the main risks to the project is delays in receiving hardware components such as the PCB and sensors, which are needed for system integration and testing. To manage this risk, the team is completing firmware and application development in simulation so testing can begin immediately once hardware arrives. Another risk involved the confidence algorithm used to interpret sensor data, which required redevelopment to improve reliability and caused a slight delay. However, this change was necessary for more accurate system performance and only added development time rather than hardware costs. Overall, the project remains close to schedule, with the core firmware structure, sensor interface, and a simulated version of the mobile application already completed.

Week 4 Questions:

• Part a (written by Vidhi):

The VitaBand addresses the growing global need to protect outdoor workers, particularly those exposed to high-temperature environments. As global temperatures rise and heat waves become more frequent, outdoor laborers, such as construction workers, face increasing risk of heat exhaustion and heat stroke, particularly in regions where continuous medical monitoring is unavailable. Because the risk calculations run directly on the device firmware and communicate via low-power Bluetooth rather than relying on constant internet connectivity, the system can function in remote or low-infrastructure environments and remain accessible to users with varying levels of technological familiarity. By combining embedded sensing, on-device risk algorithms, and system haptics for intuitive alerting, VitaBand offers a scalable solution that can improve heat-safety monitoring across diverse global working conditions.

• Part b (written by Emily):
  Cultural factors influence how people perceive and interact with health-related technology. The project considers these factors by aiming to present information and alerts in a clear and intuitive way that does not require specialized knowledge. Simple feedback mechanisms, such as haptic alerts and straightforward app communication, help ensure the device can be understood across different cultural contexts where expectations around medical monitoring, technology use, and communication styles may vary. The design also emphasizes user control and transparency in how data is used, which aligns with differing cultural attitudes toward privacy and personal health information.

 

• Part c (written by Sharia):

Environmental factors were considered in the design of our product by focusing on minimizing environmental impact throughout its lifecycle. Electronic devices can contribute to electronic waste (e-waste), which can harm ecosystems if materials are not properly disposed of, so the design prioritizes the use of standard, widely available components that can be easily replaced or repaired rather than requiring full device replacement. This helps extend the usable life of the product and reduces unnecessary waste. The design also considers energy efficiency by using components and system architectures that minimize power consumption during operation, which reduces overall energy demand when the device is used over time. Additionally, the design avoids unnecessary material usage by keeping the circuit board compact and limiting excess components, helping reduce the amount of raw materials required during manufacturing. These considerations ensure that the product meets its functional goals while also reducing its environmental footprint during production, use, and disposal.

Sharia’s Status Report for 03/07/2026

This week, I completed the design and layout of the three PCBs for the project and placed the manufacturing order (shown below). This included finalizing routing, verifying component footprints, and running design rule checks before generating the fabrication files. My progress is on schedule, and we expect the PCBs to arrive early next week. Once they arrive, I plan to reflow the boards and begin basic hardware testing to verify power behavior and ensure the boards function correctly before integrating the rest of the system.

 

Emily’s Status Report for 03/07/2026

This week I focused on firmware development. I completed the sensor interface and made progress on several additional modules, including the battery/power interface, BLE data transfer, and alert signaling through the state manager and haptic drivers. My progress is currently on schedule with the Gantt chart. The core firmware structure is in place, which should allow the remaining functionality to be implemented before hardware arrives so we can begin testing when the PCB and other components are available. Next week I plan to finish implementing the battery interface, BLE data transfer and alert signaling, so the firmware supports full sensing, processing, and communication.

Vidhi’s Status Report for 03/07/2026

This week, I focused more on implementing the necessary algorithms on the firmware. I am a little but behind schedule because I needed to re-develop the confidence algorithm. However, I will use the next week to finish implementing that and move forward with the user interface of the app. I currently have the app working in simulation, but I want to make it more visually appealing and more user friendly. Once we receive our sensors, we can also begin unit testing.

Teams’s Status Report for 02/21/2026

The biggest thing on our radar right now is just making sure we get the PCB layout finished and the order sent out before for spring break, but we expect to put in the order soon. Not much has changed in our design plans of the firmware and software, and we have made progress in both those areas. One change we made this week was that we decided on integrating two different temperature sensors to be able to get more accurate body temperature readings. This has added a bit of complexity, but we expect it to make our system more accurate at detecting heat stroke.

Vidhi’s Status Report for 02/21/2026

This week, I focused on building the user interface for the app. I established the core screen architecture and implementing real-time display components for the different alert states. I structured the UI to support future BLE data streaming and PSI-based warning logic. I also did further research on developing the risk algorithm and began coding it into the app. It will later be coded onto the nRF52840.

Emily’s Status Report for 02/21/2026

This week I focused on transitioning from an outlined structural firmware design to an integrated multi-sensor architecture using the Zephyr RTOS on the nRF52840 platform. The primary goal was establishing a modular driver suite and a centralized state management system for the Capstone project.

Sensor Drivers:

• Heart Rate  (MAX30102): Finished the code that reads heart rate data. Added a power-saving feature that detects if the band is being worn (in proximity with an “object”: a built in feature of the device) before turning on the sensors for data collection.

• Body Temp (TMP117): Wrote the driver for our high-precision temperature sensor. This sensor is accurate enough for clinical use and will track the user’s body heat.
• Ambient Temp (SHT3x): Wrote the driver for a third sensor that tracks the temperature and humidity of the air around the user. This helps the band distinguish between a fever and just a hot room.

System Logic:

I developed a centralized state manager that processes sensor data into a 1-to-10 risk scale (algorithm still to be implemented), allowing the band to automatically switch between four safety levels. This setup ensures the wearable knows exactly when to trigger an alert based on the user’s vitals without cluttering the main code.

Sharia’s Status Report for 02/21/2026

This week, I managed to complete the schematics and send them to get design reviewed so I can finish up the layout. I’m a little behind but the pcb is still on track to be sent out this thursday, before spring break. I will catch up on it by working extra hours tomorrow to finish the layout and send it out soon enough to get reviewed. Deliverables to be completed by next week are the complete pcb and finalized order.

Teams’s Status Report for 02/14/2026

Currently, we think the significant risks are in the pcb design which we plan on mitigating by holding thorough design reviews and justifying every aspect of the pcb: current calcs, part selection, datasheet suggestions etc. Some changes we made to our overall design are removing the fall detection and and dehydration features. We made this decision bearing the time we have and the complexity we’re already dealing with. Our schedule remains the same.

Week 2 Questions:

• Part a (written by Sharia):

Vitaband is designed to keep the health, safety, and welfare of outdoor workers at a risk of heat-related illnesses in mind. Too often, workers working in extremely hot and stressful conditions overlook their symptoms and sustain serious injuries because they don’t catch warning signs early enough. By constantly tracking heat metrics and updating them on their smartphone apps, they can keep track of physiological precursors of heat strain and act accordingly. The emergency button aims to target safety, where if a worker feels threatened, they can push the button on their armband and workers nearby will be notified and can rush over. Lastly, welfare is also considered by making the band lightweight, rechargeable, and designed for all-day use to avoid disrupting a user’s lifestyle and work.

• Part  b (written by Emily):

In considering social factors, the design emphasizes usability, inclusivity, and trust. The system is intended to support diverse user groups, including individuals who may not have consistent access to in-person medical supervision. By enabling remote monitoring and data sharing, the product can strengthen connections between users, caregivers, and healthcare providers, supporting collaborative health management. Attention to data privacy, transparent data handling, and user control over information sharing is also central to fostering trust across different social and cultural contexts.

• Part  c (written by Vidhi):

From an economic perspective, the product is designed with cost-effectiveness and scalability in mind. Component selection, including the microcontroller and sensors, prioritizes affordability, low power consumption, and availability to support sustainable production and distribution. By integrating on-device processing, the system reduces reliance on expensive cloud infrastructure, lowering operational costs and making the solution more accessible to a broader population. Overall, the solution seeks to balance performance and cost, ensuring that production, distribution, and long-term maintenance remain economically viable while delivering meaningful value to users.

Sharia’s Status Report for 02/14/2026

This week, I started the schematic and architecture for the actual PCB and finalized the parts selection. I also managed to narrow down mitigation techniques for heat transfer in the pcb and noise reduction techniques/ and antenna design for robustness. I’m still a little behind on the PCB but I hope to be done with the schematic in around two more days and can finally start the layout and conduct design reviews so we can send the pcb out before spring break. Next week, I hope to be able to submit the full schematic and my progress with the layout.

Emily’s Status Report for 02/14/2026

This week, I focused on defining the overall firmware architecture. I created the core file structure and C interfaces needed to support peripheral drivers, data processing, state management, and Bluetooth communication to the mobile app. While much of the functionality is still to be implemented, the structural foundation is now in place to support incremental development and testing. In addition, I developed a detailed system diagram outlining the firmware modules and their interactions in preparation for next week’s design presentation.

Vidhi’s Status Report for 02/14/2026

This week I worked on the warning detection and critical condition alert algorithms. I had to do some research on the Physiological Stress Index and also develop a confidence algorithm for the alert logic. I also started making a very basic user interface for our app. I also finalized the BLE payload definition so that it works with the algorithms I wrote. By next week, I want to have to whole user interface done for the app.

Teams’s Status Report for 02/07/2026

We think the most significant risks are all the things that could go wrong with our project, such as a bug in our firmware/app or a pcb design mistake. We plan on mitigating these by having in-depth design reviews with each other and others who are familiar with the respective fields. We’ve had some changes from the abstract phase to the proposal phase; we’ve decided to get rid of the dehydration level sensors to allow us more time and resources to test and debug our system.

Sharia’s Status Report for 02/07/2026

This week, I mainly worked on part selection and started working on the circuit design for our pcb. I’m a little behind schedule because I thought that I would have a much more solid design set before starting on the schematics, but I plan on making up for it by spending majority of my day tomorrow working on this and having a more thorough design ready before next lab session so I can run it over with others. In the next week, I should have a mostly complete parts list for the pcb, a solid design plan and the mcu schematics done.

Emily’s Status Report for 02/07/2026

This week, I began familiarizing myself with the Nordic MCU that will be used for the firmware development. I spent time reviewing the documentation and development environment. This gave me a better sense of how firmware will be structured for the device and what peripherals and features are available to work with. Next, I plan to start setting up a simple test program to validate the setup and begin experimenting with basic functionality.

Vidhi’s Status Report for 02/07/2026

This week, I began doing research on BLE protocols and familiarizing myself with libraries to choose from. I did some research on BLE chips to use and started working on defining the BLE advertisement payload between the physical product and the app. I am realizing there is a lot more to this than I initially thought, so some further research is required. I will soon be done with the initial payload contract and once I finalize the BLE chip to use, I can start writing the code.