Project Journal for Areej Mirani

=============== Week 15: =================

Summary: -----------------------------------------------------------------

Hours this week: 37 hours
Cumulative Semester Hours: 190 hours
Description of this week:
This week, I soldered on the Vpp circuit to the flywire board along with other components being soldered and desoldered as we experimented with the pcbs, created the simulated salt solutions, finalized packaging design in Fusion and prints at Bechtel, figured out the wristband situation at the Knowledge Lab, developed the user interface/experience for the HydraWise app, found multitudes of parts for the pcb boards, sat for hours trying to get the microcontroller to flash, with next steps focused on preparing everything for Spark Challenge after our demo went SO INCREDIBLY WELL I'M SO SO HAPPY!!!

Entry 3: -----------------------------------------------------------------

Date: April 25th
Start Time: 8:30 am
Duration: 9 hours

• Figured out how to solder conductivity circuit with PCB
• Soldered on the switch and the heart rate sensor
• Spent a lot of time desoldering components as well for iterative testing and integration
• Nathan taught me how to desolder through holes
• Mainly applicable to heart rate sensor module
• Sat with team to figure out why flashing wasn't working
• Involved hitting reset and boot multiple times
• Lots of reading into output code in terminal of herb's laptop
• Eventually determined we needed to finalize whole circuit so connected PCB with flywire completely
• Somehow flashing issue was fixed with this change
• Headed to Bechtel to get the 0805 led needed to indicate charging
• Went back and forth from the ECE shop trying to find wires and parts needed for the integration
• Final task of project involved fitting everything into the packaging
• Found wires in ECE shop that would make do as bolts to hold the PCB in place
• Taped up the heart rate sensor to the bottom face of the packaging
• Taped up the conductivity sensor to the top face of the packaging
• Battery was flush with the heart rate sensor, and the flywire conductivity circuit fit under the PCB
• USB-C port was aligned correctly and appropriately
• Wristband was looped through the holes and velcro was attached to the wristband to make it attach.
• However, the packaging still wasn't closing because the header pins on the heart rate sensor were too big
• Gustavo helped me desolder the current headers and put on angled headers thirty minutes before our demo with the teaching staff
• The original wires were threaded and thus we needed to break everything off and reattach new headers
• After this, we headed back to our station and made sure we had everything prepped for final demo
• FINAL DEMO WAS SO HYPE EVERYTHING WORKED!!
• Managed to get all five psdrs checked off
• Also got 0.5% extra credit for stretch!!!
• Next steps involve fixing the UI for the app and making all presentation materials for spark and final project archive.

Relevant Media See Dr. Walter's camera roll!

Entry 2: -----------------------------------------------------------------

Date: April 24th
Start Time: 10:00 am
Duration: 15 hours

• Printed Packaging at Bechtel
• Used new Bambu P1S printer - super fast only took like two hours to finish
• Meantime lasercut some logos for the team
• Headed to Knowledge lab to find wristband solution since fabrics lab at Bechtel was closed
• Found some velcro and a wristband that would work
• Used the velcro to attach the wristband to the packaging
• The velcro was temporary adhesive that would suit our prototyping purposes
• Other type of velcro was sewed on which would take more time than it would be worth and would be harder to undo to accomodate changes
• Created new salt solutions based on concentration measurements I determined.
• Based on papers I read and cross-checked with Herb
• Used same materials to create the solutions:
• Salt (Used Walmart Epson Salt)
• Distilled water
• Beakers
• Scale
• Aluminum Foil
• Paper Cups
• Methods:
• Measured out 1 L of distilled water
• Measured out 0.584 g, 1.753 g, and 3.506 g of salt using scale
• Mixed the salt into the water until dissolved
• 0.584 g/L - 1 L water; 0.584 g salt
• 1.753 g/L - 1 L water; 1.753 g salt
• 3.506 g/L - 1 L water; 3.506 g salt
• Placed the solution in a paper cup
• Created lookup table for the conductivity
• Used the freshly made salt solutions
• Measured the conductivity of each solution as it was placed on the conductivity sensor
• Gathered more data from the app after translation was done:
• 0.584 g/L - 1.165 V, 1.156 V, 1.166 V, 1.164 V
• 1.753 g/L - 1.326 V, 1.23 V, 1.21 V, 1.19 V
• 3.506 g/L - 1.395 V, 1.325 V, 1.266 V
• Made a line of best fit with desmos and averaging out the above data points.
• Wrote logic for app recommendations in if-else statements based on thresholds determined by line of best fit.
• Soldered on Vpp circuit to flywire conductivity circuit
• Headed to ECE shop to make sure with the TAs that everything that was soldered looked good and they improved some of the soldering
• Spent lots of time working with team to figure out why the microcontroller wasn't flashing properly.
• Asked Xiang to resolder the microcontroller chip multiple times in case the issue was with the hardware.
>
• Still had flashing issues after Xiang helped out.
• Shivam came by and suggested it may be a common ground issue but that would require finding every little ground in the PCB and everything to fix the issue which would've taken more time than it was worth.
• Concluded with thinking it may be a floating pin issue. Will try again tomorrow to figure out which GPIO may be floating.
• Next steps involve continuing to debug the microcontroller flashing issue so we can test out the recommendation algorithm in real life and actually start fitting everything into the packaging.


Relevant Media
• Help, ESP32 Micro Not Flashing



Entry 1: -----------------------------------------------------------------

Date: April 23st
Start Time: 10 am
Duration: 13 hours


• Updated Packaging:
• Changed height from 88 mm to 95 mm
• Changed wristband opening from 8 mm to 10 mm
• Repositioned clasps to open and close the package
• Repositioned USB-C opening to align with the pcb
• Began process to create lookup table for the conductivity
• Used the salt solutions we made last week
• Measured the conductivity of each solution as it was placed on the conductivity sensor
• Baseline: 1.1 V without ESP chip, 1.3940 V from AD2
• Started extensive research to determine where thresholds come from for the lookup table
• Based on current iteration of James's code that he sent me, I started cleaning up the user interface of the app
• Based on tutorials and stackoverflows that I lost the links of, I figured out the hex codes and syntax to mess with alignment and aesthetics of information
• Figured out how to add logo to the homeView, make the heart rate pulse and made it cute
• Made sure all these changes worked in the preview version of XCode
• Next steps involve figuring out how to use salt conductivity data to make our lookup table in the app correlate with hydration recommendations, and also print the packaging, and also integrate my UI changes with the actual XCode app.


Relevant Media
• Hydration Status, Fluid Intake, Sweat Rate, and Sweat Sodium Concentration in Recreational Tropical Native Runners
• Sweating Rate and Sweat Sodium Concentration in Athletes: A Review of Methodology and Intra/Interindividual Variability
• Sodium ion concentration vs. sweat rate relationship in humans



=============== Week 14: =================

Summary: -----------------------------------------------------------------

Hours this week: 18 hours
Cumulative Semester Hours: 153 hours
Description of this week:
This week, I tuned the conductivity sensor filters to attempt to achieve a cleaner waveform, practiced soldering, finalized fly-wire design, updated packaging design, and learned filtering principles, with next steps focused on testing conductivity data, finalizing packaging, and preparing the final presentation materials.

Entry 6: -----------------------------------------------------------------

Date: April 18th
Start Time: 10 am - 11:30 am, 2:30 pm - 4:00 pm
Duration: 3 hours


• Went in to try to find protoboards for flywiring.
• Started new print at Bechtel.
• Jonathan came in and helped me figure out the conductivity circuit flywiring.
• Passed along drawing we made to team since I needed to host events for the rest of the weekend.
• Still need to figure out how to move the conductivity sensor to fit with the PCB.
• Next steps involve hopefully coming back to a soldered flywire circuit and testing with the conductivity sensor. I also need to recreate the salt solutions and fix the UI on the mobile app.
Detailed Description: I went into lab this morning to find more boards for the flywiring. I picked up hella from the ECE shop and hopefully they will work. However, I'm not sure if they will work yet. Then I went to Bechtel to start the packaging print with all the new changes. I then came into lab around 2:30 ish to meet up with Jonathan and figure out the flywiring stuff. I've never fly wired before and everyone I talked to yesterday scared us hella saying that flywiring is the toughest thing in the world, like practically impossible, and we should be dialing up all of course staff right now to figure out how to order new PCBs. Luckily, Jonathan knew exactly what to do. Thank you so much for your help fr. We started mapping out all the connections from the breadboard to the tiny flywire protoboard once we figured out which protoboard to use out of my extensive collection. After we made the sketch, I had to dip for my other committments so I sent the diagrams to my team to figure out how to solder everything. Next steps involve hopefully getting the final flywire board from Matt and testing with salt solutions that match human sweat more closely.

Relevant Media
• Conductivity Circuit Jonathan
-->



Entry 5: -----------------------------------------------------------------

Date: April 17th
Start Time: 5:30 pm
Duration: 2 hours


• Jonathan came in and helped me figure out the conductivity circuit flywiring.
• Still need to figure out how to move the conductivity sensor to fit with the PCB.
• Next steps involve figuring out how to do the flywire circuit and testing with the conductivity sensor. I also need to recreate the salt solutions and fix the UI on the mobile app.
Detailed Description: I came into lab today with a slightly panicked mindset considering how so little things are done with only two weeks left. In my mind, I was thinking about how I needed to get the PCB and the conductivity sensor working together. I also needed to figure out how to do the flywire circuit and test it with the conductivity sensor. I also needed to recreate the salt solutions and fix the UI on the mobile app. Alongside this, we needed to fix all the microcontroller flashing issues that were happening, especially with the BLE. I first made a task list to put all these thoughts on paper. I asked everyone around me to help me learn how to solder since we were no where near done with that and someone had to do it. Krish got me started by teaching me how to do the resistors on the pads. Next steps involve fixing everything mentioned above and focusing heavily on the conductivity circuit to make sure it works. I set up a meeting with Jonathan for tomorrow to figure everything out. He sent the conductivity circuit schematic below so hopefuly we can start building it.

Relevant Media
• Conductivity Circuit Jonathan



Entry 3: -----------------------------------------------------------------

Date: April 16th
Start Time: 12:30 pm
Duration: 5 hours


• Headed to Mechanical Engineering building to pick up print.
• Had Matt clean out the print from the supports.
• Worked with team to determine if components would fit.
• Determined new changes to the packaging listed below.
• Learned we needed to conduct conductivity checks on PCB board, fix the BLE configuration on the software, and fix the I2C problem.
• Headed to Whetherill to make salt solutions with my Chemistry major friend.
• Started figuring out how to fix conductivity circuit with Jonathan's help.
• Next steps involve finalizing packaging CAD and testing the salt solutions on the conductivity sensor.
Detailed Description: During this session, I developed the packaging further and started experimenting more with the conductivity sensor. First, in terms of packaging, I picked it up from the ME lab with my friend's help. This TPU filament was a neon green, which I thought was an interesting choice. I took it to ManLab and started tearing out the supports. I got basically everything out except for the hinge openings. I had Matt take them out with clamps. Then we started placing all the components in like the wires and battery and PCB and stuff. Everything seemed to fit but we talked about making a few more changes for flexibility and the layout of the PCB. I also added the heart rate sensor cutout since we decided to keep this on the packaging box and not the wristband as was originally planned by me. Below are images of attempting to fit everything in. Here are the main changes made:
• Added heart rate sensor cutout
• Added more space for the battery
• Added more space for the PCB
• Added more space for the wires
• Added more space in the wristband hole cutouts, from 2 mm thickness to 4 mm thickness, for the wristband to fit in the packaging
• Changed length from 88 mm to 90 mm so antennae on ESP32 doesn't bulge up.
• Moved mounting holes towards the switch side.
• Moved the usb-c charging port to the conductivity sensor half of the packaging.


In ManLab, we learned as a team how to approach a few things. These are listed below:
• We need to conduct continuity checks on the PCB board to ensure it is working properly.
• We need to fix the BLE configuration on the software side.
• We need to fix the I2C problem with the sensors. This involves figuring out the general GPIO in making it high and low, then going back and testing as the actual I2C.
• We need to make the conductivity circuit.


The last-ish thing I worked on today was making salt solutions with my chemistry major friend. I headed to Whetherill and she helped me find all the materials. In total, we needed:
• Salt (Used Walmart Epson Salt)
• Distilled water
• Beakers
• Scale
• Aluminum Foil
• Plastic Cups
We made salt solutions of NaCl following the methods of the paper Jonathan provided. We scaled their solutions down to 50 ml distilled water instead of 1 L. I think initially we may have done the math wrong, but these are the solutions we ended up making:
• 50 mL water; 0.25 g salt
• 50 mL water; 0.5 g salt
• 50 mL water; 0.75 g salt
I learned that the conductivity sensor is not working properly because the wave is not being generated correctly. I also learned that the wave is not being generated correctly because the capacitor values are not set correctly. I will be working with Jonathan to fix this issue tomorrow. The next steps involve finalizing the packaging CAD model and testing the salt solutions on the conductivity sensor to determine dehydration thresholds.
Relevant Media
• Bechtel Design & Innovation Center
• Conductivity Paper Jonathan



Entry 2: -----------------------------------------------------------------

Date: April 15th
Start Time: 3:30 pm
Duration: 4 hours


• Headed to Bechtel to fix CAD model and print.
• Ran into issues with aligning mounting holes with PCB.
• Another staff member said the hinge isn't feasible to print in place.
• Had Johnny help me fix the mounting hole supports.
• Learned about different waterproofing alternatives.
• Headed downstairs to consult about wristband materials and learned about what the fabrics lab at Bechtel has.
• Started print for packaging at the ME 3d print lab with my friend.
• Next steps involve finishing fixes on CAD model and starting preparation for the senior design demo.
Detailed Description: During this session, I focused on working on the packaging. I visited Bechtel to get help with the mounting holes design and luckily found Johnny. I finalized the hinge design and aligned all the mounts. When I was getting ready to print, another TA Gabe came in and started critiquing everything about the hinge functionality, saying the print in place wouldn't work because of the way the machine would be putting filament in a floating manner, which is not possible since the design works on supports only. I was a little frustrated since I had spent hours watching YouTube videos and everything to create the hinge. After this whole explanation and asking why I was using TPU and doing the whole design in the first place, the staff member started listed alternatives in case I decided to print with the non-waterproof PLA instead. Pictured below is the seal product he recommended. Since I still had to make a few changes to my design, I left the lab to do this on my own time.

Before leaving Bechtel, I went down to the fabrics lab to explore what they have. Turns out they had velcro and waterproof tent-like material that we could use. The materials are pictured below. I will return when we reach the point of final product assembly.

Later on, I ended up having my mechanical engineering friend review my design. He verified the print in place would work and had me tweak a few things in the model. We began the print around 7 pm at the mechanical engineering place. Next steps involve picking up the design tomorrow and preparing for the senior design demo.
Relevant Media
• Bechtel Design & Innovation Center



Entry 1: -----------------------------------------------------------------

Date: April 13th
Start Time: 3:30 pm
Duration: 4 hours


• Fixed conductivity sensor code with microcontroller and low pass / high pass filter system.
• 1.9 V offset in wavegen to account for ESP32 voltage.
• Flash microcontroller commands are similar to BLE process but must be in root directory.
• After meddling with filters, reset to .47 uF and 2.2 uF to get ideal wave.
• Generated baseline values with distilled water from lab.
• Next steps involve creating salt water to find dehydration threshold. Also need to consult with Jonathan about wave.
Detailed Description: During this session, I focused on finalizing the conductivity sensor code and filter settings for HydraWise. I learned that the ESP32 operates at 3.3V, so I adjusted the wavegen offset to 1.9V to ensure proper signal levels with the conductivity sensor circuit involving the op amps and the LFS1107. I also discovered that flashing the microcontroller requires placing the commands in the root directory, similar to the BLE process. The specific commands I used are listed below:
• source ~/esp/esp-idf/export.sh
• idf.py build
• idf.py flash monitor
After experimenting with various filter settings, I reverted to using a .47 uF capacitor for the low pass filter and a 2.2 uF capacitor for the high pass filter, which produced an ideal waveform for conductivity measurements. The meddling involved changing .47 uF to 100 uF which resulted in peaks that were far too smooth with additional lag. I changed the 2.2 to .22, .47, and 100 to test out different values and still didn't get the right wave. Ultimately I switched everything back to the normal .47 and 2.2 microFarads. I learned that this aimed to keep the signal in the range of 0 to 3.3 V. Next I searched for distilled water from the lab sinks that had a dropper so it would be easy to get a clean drop of water. Then I generated baseline values using distilled water from the lab, which will serve as a reference point for future tests. I sent an email to Jonathan to try to verify if the waves I was getting was right. He responded saying that everything looked completely wrong. We set a time for tomorrow to fix everything with the conductivity sensor. The next steps involve creating salt water solutions to determine dehydration thresholds and consulting with Jonathan about optimizing the waveform further.
Relevant Media
• Conductivity Testing
• Conductivity Paper Jonathan



=============== Week 13: =================

Summary: -----------------------------------------------------------------

Hours this week: 21 hours
Cumulative Semester Hours: 135 hours
Description of this week:
This week, I finished the Bluetooth implementation with ESP32 microcontroller's ESPIDF and the iOS mobile app, followed by intensive work on the final housing design which involved learning how to create a print-in-place hinge and next steps involve integration with the actual pcb along with printing the housing component at Bechtel.

Entry 9: -----------------------------------------------------------------

Date: April 11th
Start Time: 9:00 pm
Duration: 3 hours


• Continued to make the hinge feature.
• Went to Bechtel to get help in placing mounts in the opening part of the piece and schedule a print time.
• Added latches to the print and debugged why there were random mystery bodies with Johnny's help.
• Next steps involve starting my print on Monday and picking it up Tuesday hopefully.
Detailed Description: During this session, I dedicated time in finalizing the hinge mechanism for the HydraWise packaging design. I continued building off the print-in-place hinge tutorial, refining the hinge alignment, pivot clearance, and overall rotational behavior to ensure that it would function correctly after 3D printing. I then headed to Bechtel, where I met with Johnny to debug multiple issues. Mainly there was the unexpected appearance of mystery bodies in the model that were interfering with part placement and slicing. With Johnny's guidance, I cleaned up unnecessary elements and re-fixed the latches to the appropriate faces of the main body. I then added internal mounts on the lid section of the housing so that components like the PCB could eventually be secured from both halves. Johnny and I went back and forth about how to do this. Initially Matt, James, and I thought we should do a pillar type situation that would allow the bolts to go through so the pcb wouldn't wobble. Johnny proposed having rods integrated into the design so the pcb could slide right through. However, after further discussion, Johnny and I decided this may be less stable after all and I went ahead with adding the pillar-like supports instead so the washer and bolts could be used to attach the bolts. I also incorporated a latching mechanism that complements the hinge, allowing the housing to be easily opened and snapped shut. After refining the model, I coordinated with Bechtel staff to schedule a print time for Monday, aiming to pick up the printed iteration by Tuesday for testing and fit assessment. I learned during this conversation that the TPU housing component wouldn't be waterproof in the sense that we would be able to dunk the entire thing under water, but it would rather be splash resistant so that a little water getting on the product wouldn't hurt it too much. I also learned about a conformal coat that could make the pcb waterproof but after a quick google search we found out it doesn't actually waterproof anything. The design is now in its most complete form yet, integrating hinge, latch, and mounting features that address all prior user feedback. I only hope that there is enough space between the pcb and back half for all components to sit comfortably.
Relevant Media
• Print-in-place Hinge Tutorial



Entry 8: -----------------------------------------------------------------

Date: April 10th
Start Time: 9:00 pm
Duration: 2 hours


• Began attempting to make the hinge feature.
• Consulted with Johnny about how to do this in the design and learned about print-in-place hinges.
• Followed YouTube video in creating hinge.
• Also went to lab and discovered we switched to a bigger battery so changed dimensions to accomodate for this change. New dimensions:
• Length: 88 mm
• Width: 56 mm
• Height: 25 mm
• Next steps involve continuing to iterate on packaging by making the hinge open and heading to Bechtel to start the print.
Detailed Description: During this session, I focused on implementing a functional hinge mechanism for the HydraWise packaging, enabling the enclosure to open and close for easier access to internal components. I consulted with Johnny yesterday, who introduced me to the concept of print-in-place hinges, which are designed to be 3D printed as a single movable assembly without requiring post-print assembly. With this approach in mind, I began restructuring the CAD model and followed a YouTube tutorial that walked through step-by-step hinge creation techniques using Fusion 360. I carefully modeled the hinge geometry with proper tolerances to avoid fusion during printing, ensuring rotation would remain possible. This is a critical feature for user accessibility and practical assembly of HydraWise. However, I'm still a little worried that the packaging won't close and latch all the way as this is what the comments said under the video. The next steps involve finalizing this iteration with a functional hinge, then heading to Bechtel to begin printing the updated prototype, testing the fit and movement of the hinge mechanism in real life.
Relevant Media
• Print-in-place Hinge Tutorial



Entry 7: -----------------------------------------------------------------

Date: April 9th
Start Time: 10:00 pm
Duration: 3 hours


• Worked on A11 - Ethical and Environmental Concerns Report.
• Learned all the ways that HydraWise could harm the environment and how to mitigate these situations.
• Learned all the ways that HydraWise could be unethical to users and brainstormed ways to mitigate these items.
• Next steps involve verifying all ideas and thoughts with reputable sources and adding citations.
Detailed Description: During this session, I worked on finishing A11. I consulted with the team about where our PCB was created to ensure it is environmentally sound in creation. I also brainstormed all the ways HydraWise may be ethically or environmentally unsound. All the different processes of the lifecycle of HydraWise had something new to dive into. Manufacturing had how all the pieces were created. Normal use considered how any person would affect HydraWise's engagement with the environment and the user themselves. For example, the user could be shocked or electrocuted or burnt if the device decided to malfunction at any point. Additionally, the device may not be ethically sound if it is not accessible to say the blind or anyone with low technological literacy. There are also the FDA and governmental approvals that go into the fact that HydraWise is a medical device. That's why it needs to have a ton of disclaimers saying it is more of a fitness tracker instead of something that should be seriously considered as a medical device. Writing this assignment was a ton of fun. All I need to do tomorrow is determine all the reputable sources that may verify or combat my idea so that I can submit all the right information about how HydraWise is environmentally and ethically.
Relevant Media
• JLCPCB
• A11 - Ethical and Environmental Analysis



Entry 6: -----------------------------------------------------------------

Date: April 9th
Start Time: 12:30 pm
Duration: 4 hours


• Modified packaging based on team and teaching staff feedback.
• Learned that pcb won't be directly centered and we need mounting holes to ensure the pcb is stable in the packaging.
• Added mounting holes in middle of packaging after sketching out its dimensions.
• Team agrees to attach the pcb with bolts and washers as opposed to having grooves in the holes since the 3D print may not spit these out in the cleanest way (might be excess filament).
• Next steps involve continuing to iterate on packaging by fixing mounting situation and adding hinge feature so packaging can open and close to put the pcb and other components inside, then be able to latch closed.
Detailed Description: During this session, I focused on modifying the HydraWise mechanical packaging based on recent feedback from both our team and the teaching staff. One major insight we confirmed is that the PCB cannot be perfectly centered within the enclosure due to the spatial layout of sensor connections and wire routing. To address this, I added four mounting holes to the internal structure of the housing, positioning them carefully based on precise sketches and PCB measurements to ensure alignment. After discussing with the team, we agreed to use bolts and washers to fasten the PCB instead of 3D-printing grooves or standoffs, as those features often result in excess filament or imperfect fits on lower-resolution prints. Additionally, these features would be tougher to implement in the CAD sketch, and since the mounting holes are 2mm in diameter, it likely wouldn't turn out great in real life print-wise. This mounting strategy will improve mechanical reliability and prevent component shifting during movement. Dr. Walter and the team also went back and forth about packaging being a multiple-person job and determining how the sensors would be situated. Honestly, having the heart rate sensor in the wristband part would be far too complicated to ensure it would be secure and waterproof. I am working on finding a solution in having this sensor stay inside the packaging although it may not output the best reading at this stage of prototyping. The next steps are to iterate on this new packaging version by implementing a hinge system, allowing the housing to open and close for easier assembly and maintenance. I'll also begin prototyping a latching mechanism to securely close the housing once the components are installed, making the design more robust and user-friendly.
Relevant Media



Entry 5: -----------------------------------------------------------------

Date: April 8th
Start Time: 2:30 pm
Duration: 2 hours


• Visited Bechtel for consultation and editing design for final housing.
• Learned about fabrics lab to figure out wristband situation.
• Edited new housing design to match the requirements Matt and I talked about yesterday.
• New Dimensions:
• Length: 51 mm
• Width: 25 mm
• Height: 88 mm
• Next steps involve making the lid open and close and figure out where to put the wristband opening.
Detailed Description: During this session, I visited the Bechtel Design and Innovation Center to refine the final housing design for the HydraWise wearable. I consulted with Bechtel staff on improving the mechanical enclosure and began implementing the updates Matt and I discussed the previous day. The process invovled figuring out where the heart rate component would go (on the housing or in the wristband) and measuring out the dimensions with the pcb, battery, and components living on the pcb being stacked. The final thickness or width we decided should be 25 mm to allow for wiggle room while fitting everything compactly. Overall I adjusted the housing size for better fit around the internal components. I revised the model to the following dimensions: 51 mm in length, 25 mm in width, and 88 mm in height, ensuring more space to accommodate the battery, PCB, and sensor leads without compromising compactness. Lily told me about Bechtel's fabrics lab downstairs to figure out how to secure the housing with a wristband, as this component has been a recurring design challenge—especially given the need for comfort and secure fastening during motion. The revised CAD design is now closer to completion, but still requires the addition of a functional lid mechanism to allow access to internal components, and strategic placement of wristband connection points for integration with off-the-shelf straps or a custom band. The next steps will involve iterating on this updated model to implement the lid and finalize wristband openings, preparing it for the final 3D print.
Relevant Media
• Bechtel Fabrics Lab



Entry 4: -----------------------------------------------------------------

Date: April 7th
Start Time: 4:00 pm
Duration: 1 hour


• Discussed placement of components with Matt.
• Learned where usb-c receptacle and power switch would be on housing.
• Added slots for power switch and usb-c receptacle to housing design.
• Next steps involve going to Bechtel to consult with people about where to put wristband straps and where to go to make the wristband attachment.
Detailed Description: During this session, Matt and I went back and forth to figure out how to configure the packaging of HydraWise. I learned where the power switch and USB-C charging receptacle was located on the PCB. I originally thought we were doing a micro-usb situation and had no real power opening in the packaging so far. After I figured out these placements, Matt and I grabbed a ruler and started ensuring there would be enough space for parts like the antennae of the ESP32 to be protected in the packaging since this component sticks out from the PCB size. We also determined how much room to leave for the wires to loop around the pcb to connect the sensor modules. I determined around a 1 cm gap all around for these components. Next steps involve fixing the mounting holes and overall pcb placement relative to every other component that would be included in the packaging, along with figuring out how the heart rate sensor would be housed in the wristband part of the packaging.

Relevant Media
-->



Entry 3: -----------------------------------------------------------------

Date: April 6th
Start Time: 1:30 pm
Duration: 2 hours


• Met at lab with Herb and James to finalize button implementation.
• Fixed button after debugging by changing the cb variable from read to write in the button characteristic.
• Fixed hydration readings by changing the UUIDs from custom to assigned numbers in BLE's database.
• Got readings from hydration dummy data of 1.23%.
• Fixed heart rate to continue reading alongside hydration measurements so the two can be simulataneously updated in the mobile app display.
• Learned to use resources to debug and implement changes.
• Next steps involve integrating this dummy implementation of bluetooth with our actual microcontroller code so it takes in readings from the actual sensor modules and displays them on app.
Detailed Description: During this session, Herb and James and I met up in the lab to finalize the Bluetooth button and sensor characteristic implementation for HydraWise. After extensive debugging, I resolved a major issue with the button characteristic by updating the callback variable (cb) from read to write. This involved extensive research with why the GATT profile for hydration wouldn't show on the iOS side or get readings when James clicked the button on his phone. Eventually, I found out it was because the characteristic should be able to write, not read, and this change enabled proper communication between the iOS app and ESP32. Now the mobile app successfully sends commands to the microcontroller. Next, I tackled an issue with the hydration sensor readings. Initially, the custom UUIDs I made were not recognized by the app or nRF Connect to be able to verify that the characteristic was found and/or being transmitted. To fix this, I updated the hydration characteristic to use a Bluetooth SIG-assigned UUID (0x272B) for electrical conductance, based on official documentation from the Bluetooth Assigned Numbers database. The service id stayed the same. This allowed a successful transmittance of dummy hydration data, which correctly displayed as 1.23% on the iOS app. I also addressed a lingering bug where heart rate data wasn't updating alongside hydration. By modifying the conn_handle_event variable, I enabled both sensor readings to transmit simultaneously and update in real-time on the mobile app's dashboard. Finally to wrap up the day, I added a battery readings GATT profile and had dummy data send 88% as a reading to the app. Through this process, I deepened my understanding of BLE service/characteristic configuration, callback functions, and proper use of standardized UUIDs. The next steps involve replacing the dummy data with real-time readings from the actual MAX30101 and conductivity sensor modules, fully integrating the microcontroller-side code with sensor input and ensuring that accurate, live values are displayed on the iOS app interface.

Relevant Media
• Bluetooth SIG-assigned Numbers



Entry 2: -----------------------------------------------------------------

Date: April 5th
Start Time: 7:00 pm
Duration: 1 hour


• Created new draft for HydraWise packaging.
• Learned we need new placement ideas for strap situation and to finalize materials.
• Need to figure out how to mount PCB on housing securely.
• Ran into issues placing everything in right spot relative to each other.
• Next steps involve going into lab to take measurements of different components heights from PCB board like the headers and pins along with MAX30101, battery, and conductivity sensor placements.
Detailed Description: During this work session, I focused on creating a new draft for the final HydraWise packaging design in preparation for the Spark Challenge. This iteration centered on refining the mechanical enclosure and internal component layout, particularly addressing the strap configuration and mounting strategy for the PCB. I quickly realized that although the main housing dimensions were close, I still needed a secure method to mount the PCB onto the interior shell, especially considering the varying heights of components like the headers, MAX30101 sensor, and battery leads. I brainstormed whether we could use a fabric covering or elastic sleeve to keep the board in place post-insertion but determined that a more robust mechanical solution would be required. Additionally, the need to be waterproof and sweat-wicking hold major priority in developing this housing component. Materials such as silicone or hot glue to keep the wires and pieces aligned and away from each other is crucial. Placement of internal components relative to one another also became a major challenge, as aligning sensor windows (like for the MAX30101 or conductivity leads) required tighter tolerances than the current CAD allowed. I also realized we need to finalize which material (e.g., Elastic 50A vs TPU) would best support both flexibility and structure while holding the components in place. The strap placement remains an open question—it's unclear whether it should be embedded or attach externally, and whether the design will support Apple Watch-style slide-in bands or use Velcro-based alternatives. The next steps involve heading into the lab to physically measure the height and footprint of components mounted on the PCB, including the conductivity sensor, MAX30101 module, and battery, so I can update the CAD model accordingly and potentially consult with Johnny at Bechtel on practical solutions for mounting and strap integration.


Relevant Media
• Potential Waterproof Sealant



Entry 1: -----------------------------------------------------------------

Date: April 5th
Start Time: 1:30 pm
Duration: 3 hours


• Established button connection from the iOS mobile app to the ESPIDF microcontroller.
• Learned that the code had duplicate UUIDs.
• Cleaned up code from duplicate UUIDs and generated an alert state for the button characteristic and service.
• Ran into issues with button characteristic and service not being seen in iOS side. Hydration characteristic also not being seen.
• Next steps involve making sure the button GATT profile and hydration characteristic is actually seen in the nRF Connect app and the iOS terminal.
Detailed Description: During this work session, I successfully established bidirectional communication between a button in the iOS mobile app and the ESP-IDF microcontroller via Bluetooth Low Energy (BLE). The objective was to allow the app to send a signal that would be recognized by the ESP32 and trigger an alert state within the system. Initially, the setup failed to function correctly because the codebase contained duplicate UUIDs for multiple GATT services and characteristics, which caused conflicts in the BLE advertising and prevented proper service discovery on the iOS side. I conducted a thorough cleanup of the BLE GATT configuration by removing the redundant UUIDs and restructuring the custom service definitions. Specifically, I referenced official BLE specifications and updated the code to correctly use the Phone Alert Status Service (UUID: 0x180E) and Alert Status Characteristic (UUID: 0x2A3F), both of which are officially recognized by Bluetooth SIG standards.

After cleaning up the code, I restructured the BLE profile to include a clearly defined button characteristic within its own service, and I programmed the ESP32 to trigger an alert state upon receiving a write command to this characteristic. However, I encountered a new issue where neither the button characteristic nor the hydration characteristic appeared on the iOS app or in the nRF Connect app. This suggested that either the services were not being properly advertised or the characteristics were not being registered correctly within the BLE stack. To resolve this, the next steps involve carefully verifying the registration and advertising of both characteristics in the ESP-IDF GATT profile and ensuring that the iOS app is configured to scan for and subscribe to these UUIDs. I'll use both nRF Connect and the XCode Bluetooth terminal logs to confirm visibility and debug characteristic recognition from the mobile side. I think the issues lie in making sure that the UUID's are the same on both the app side and the ESP microcontroller side. Next steps involve debugging this aspect of the BLE integration.


Relevant Media
• Bluetooth Assigned Numbers for Services and Characteristics



=============== Week 12: =================

Summary: -----------------------------------------------------------------

Hours this week: 10 hours
Cumulative Semester Hours: 114 hours
Description of this week:
This week, I continued coding the actual implementation of BLE with Espressif IDE and ESP32, which involved learning about the different data types in the BLE data structures for heart rate and conductivity whilst transmitting these data structures to Bluetooth scanner apps, and next steps involve working more with James to finish the XCode app and BLE Server integration to accommodate for user input and the actual data being received from the sensor components.

Entry 4: -----------------------------------------------------------------

Date: April 4th
Start Time: 2:00 pm
Duration: 3 hours


• PCB arrived today!! Grabbed currently printed mechanical prototypes and saw that the PCB's fit!!!.
• Learned that the shell thickness is a little too think in the TPU housing so that needs to be adjusted size-wise. The Elastic Resin works a lot better in fitting the PCB.
• Finally got James at the lab to work on fixing the XCode for our actual HydraWise app.
• Ran into issues in debugging trying to find HydraWise-BLE-Server on the scanner.
• Finally fixed issue after lots of research.
• Next steps involve fixing the button from the iOS app side to talk to the BLE Server code on my side.
Detailed Description: During this session, the PCB for HydraWise finally arrived, marking a major milestone in hardware development. I picked up our currently printed mechanical housing prototypes and was super excited to find that the PCB physically fit inside the Elastic50A resin version of the shell. However, I noticed that the TPU print still had issues. The shell thickness made the interior a little too tight for the PCB's width dimension of 44.7 mm. This meant there needed to be some force to in sliding the PCB into the TPU version of the print. As a result, if we want to go with TPU, the width will need to be a little bigger. Herb and I looked through the sensor placement as well. I determined that the conductivity and the heart rate will be wired through everything so there doesn't need to be a specific hole in the housing component to accomodate for these sensors. I need to take out the E-ink display hole as well since we're not doing that at all.


The next task of the day was to work on the software with James to finally begin fixing our actual iOS app in XCode. We aimed to integrate BLE communication, specifically ensuring the app could detect and connect to the ESP32's BLE. I had the device name be broadcasted as "HydraWise-BLE-Server". Initially, we faced issues getting the app to scan and detect the BLE server. After significant troubleshooting with Apple CoreBluetooth documentation, installing LightBlue, and help from ChatGPT, we resolved the scanning issue and the app could connect to the ESP32 in its scanner in XCode. To fix this I also researched BLE communication patterns using sources like the Nordic iOS nRF Toolbox GitHub repository, which helped me understand how to configure CoreBluetooth scanning and make it work to satisfy the iOS requirements for bluetooth. It was a huge win when the device finally connected basically instantly after flashing to the XCode HydraWise mobile app.

Another aspect of the software work was working on the transfer from XCode preview to actually putting the app on James's or my iPhone. We found a video to help us with this process. After troubleshooting with Developer permissions and password things, we finally got the app to be hosted on our iPhone. This gives us a great headstart for the actual demo that will be coming up in like two weeks.

The next steps are to link the BLE connection to a user-triggered button in the app. Currently nRF Connect and LightBlue have buttons that send the notifications so nRF Connect can read data received from the client to the ESP32 server. We need to figure out how to implement this in code for our HydraWise app on XCode.

Relevant Media
• NordicSemiconductor IOS-nRF-Toolbox
• Best Practices for Interacting with a Remote Peripheral Device - Apple Developer
• Peripheral Example Code from Apple
• Run Your App on Your iPhone or Simulator



Entry 3: -----------------------------------------------------------------

Date: April 3rd
Start Time: 4:30 pm
Duration: 1 hour


• Determined data types for conductivity sensor and heart rate sensor.
• Learned what would be transmitted from the conductivity and MAX30101 to the app.
• Began drafting code to accomodate for these insights with help from chatGPT.
• Next steps involve testing this code with James after he fixes our actual app on XCode.
Detailed Description: During this session, discussed data types with Herb. I learned that the conductivity sensor would return a float with voltage as raw data. The heart rate sensor returns bpm as an integer. This helps me in formatting the fields in the BLE transmission. With these insights and chat, I started figuring out how to write the code that structures and sends these values. Chat helped me format the GATT characteristic updates and integrate sensor readings into the existing NimBLE server logic. Next steps involve meeting up with James to get the XCode functionality working and somehow make it so the bluetooth device is recognized by the XCode apps.


Relevant Media
• Conductivity Sensor Datasheet for Data Type



Entry 2: -----------------------------------------------------------------

Date: April 2nd
Start Time: 12:00 pm
Duration: 3 hours


• Debugged reason behind extra fields in nRFConnect output with the "No Contact Supported" and "27756 kJ" fields.
• Determined changes needed to housing component based on teaching staff feedback.
• Learned how nRFConnect data fields are configured and ways to configure my own heart rate data fields.
• Learned how to solder with Brandon's team.
• Next steps involve figuring out integration with the current BLE setup and the iOS app.
Detailed Description: During this session, I dove deep into debugging the BLE heart rate data transmission by first figuring out what the extra fields were from the nRF Connect output. I sent a 0x00 payload which I learned is supposed to tell the app that all other fields are invalid except heart rate. This is accurate in the sense that the body sensor field outputs "No Contact Supported" but the energy emitted field is putting out an unrealistic 255+ kJ energy value. This is the outcome of the research I did for the fields of nRF Connect. I discovered that nRF Connect automatically parses standard heart rate characteristics (0x2A37) into predefined fields, so that if any extra bits are misaligned or not explicitly zeroed out in the characteristic payload, the app will display garbage data in the additional fields like the energy expended or sensor contact support, even if those fields aren't intended to be active. Next I explored BLE specification formatting, particularly how flags bytes control which data fields are parsed, and how crucial correct byte alignment is when crafting the BLE packet.


Beyond the BLE debugging, I learned from the teaching staff how to improve the housing component and mechanical design. I need to get the actual measurements of the PCB. James was saying it would be like four inches long, which is basically three quarters of my forearm. Shivam was proposing multiple straps to attach the component to the wrist. Dr. Walter talked about the glove design again and using fabric to make the design more comfortable for users. I'll need to do a lot of brainstorming and back and forth with Bechtel to accomodate these new changes.

The last fun item of the day was learning how to solder. I ran into Brandon and he was learning how to solder. I joined him at the desk and we learned from the TA how to apply flux, the tiniest bit of solder, and the process of cleaning the hot part before applying it to the chip that we solder. I practiced on a random chip and motherboard to figure out what bridging was and how to align the pins and stuff. Gustavo helped me a little in learning what bridges are and stuff. This knowledge will directly support future assembly of our heart rate and hydration sensor modules.

The next steps involve reworking the BLE heart rate packet structure to strip out unintentional data fields and begin testing integration with the iOS app for real-time display of heart rate values. I need to meet with James to get the XCode working so that app works with the BLE instead of spending time trying to configure the fields in the nRF Connect.

Relevant Media
• Reddit debugging
• GitHub example of Heart Rate BLE
• ESP32 | BLE Client (Heart Rate Monitor with OLED and MQTT)
• GitHub with Heart Rate on OLED display to fix display configuration



Entry 1: -----------------------------------------------------------------

Date: March 30th
Start Time: 7:30 pm
Duration: 3 hours


• Cleaned up UUIDs for services and characteristics in BLE configuration.
• Sent data via BLE to app nrfConnect.
• Successfully returns "101 bpm, Contact Not Supported, 27756 kJ" as data in nRFConnect app, but this data is wrong since I sent 75 bpm.
• Attempted to set up a random heartbeat generator with esp_random but I learned that the data read still spits out garbage values.
• Next steps involve figuring out what the extra information is.
Detailed Description: During this session, I headed to lab with James. Our goals were to complete setting up the heart rate so that it would send data from the ESP32 to the phone. I'm using nRFConnect to verify connectivity and data values. Since we were confused about the structure of the code, I began by cleaning up the code and commenting in which UUIDs were characteristics and what were services. I cleaned up the extraneous code I had commented out that hadn't worked as well. Then I made sure all the UUIDs matched up, like using 0x180D everywhere for the heart rate and 0x2A37 everywhere. I also removed duplicate instances.
Next, I figured out how to send the 75 bpm reading. The line of code that corresponds to setting values is


uint8_t hr_data[2] = { 0x00, 75 }; // Heart rate measurement (75 bpm)

and can be modified by changing the length and everything. I also learned that the esp_random function is not working as expected. I was trying to set up a random heartbeat generator with esp_random but I learned that the data read still spits out garbage values. I also learned that the data read is not in the correct format. I was able to send the data via BLE to the app nrfConnect. I successfully returned "101 bpm, Contact Not Supported, 27756 kJ" as data in the nRFConnect app, but this data is wrong since I sent 75 bpm. I don't know where the extra information like the Contact Not Supported and the kJ stuff is coming from.

Then I attempted to see if the value would change as readings got sent. I attempted this by asking chat, and it told me to start using the esp_random library and a command like

uint8_t random_bpm = (esp_random() % 40) + 60; // random between 60 and 99 uint8_t hr_data[] = { 0x00, random_bpm }; // 0x00 = simple 8-bit HR format

But this didn't work. I think the issue is that the esp_random function is not working as expected. I also learned that the data read is not in the correct format. I need to figure out what the extra information is. The next steps involve figuring out what the extra information is and how to get the esp_random function to work correctly, potentially.
Relevant Media
• Random Number Generation



=============== Week 11: =================

Summary: -----------------------------------------------------------------

Hours this week: 10 hours
Cumulative Semester Hours: 104 hours
Description of this week:
This week, I began coding the actual implementation of BLE with Espressif IDE and ESP32, which involved learning about how to set up the ESP32 and Espressif IDE along with UUID's, characteristics and services, and next steps involve completing the characteristics and merging the BLE connectivity by sending data from the phone to the microcontroller.

Entry 3: -----------------------------------------------------------------

Date: March 27th
Start Time: 2:30 pm
Duration: 2 hours


• Created characteristics for heart rate, conductivity, and battery management modules.
• Learned about how the characteristics interact with services and the different UUID profiles.
• Generated UUIDs for all the new characteristics.
• Next steps involve figuring out how to connect this initial BLE setup with the iOS mobile app.
Detailed Description: During this session, I continued working on the ESP-IDF and ESP32 BLE configuration with Ashish Saini and more. I first connected the device to the ESP32 microcontroller and checked with the nRF connect app to ensure connectivity. Then I began setting up characteristics for the heart rate, conductivity, and battery management modules. I learned about how the characteristics interact with services and the different UUID profiles. I generated UUIDs for the new characteristics, mainly conductivity, using a custom UUID generator. The conductivity UUID needed to be a 128-bit randomly generated hex string. Heart rate and battery management already had set global UUIDs that were 16-bit in size. I also learned about the different types of characteristics and how they are used in BLE communication. All these modules are currently able to read and write data. Conductivity is still showing as an unknown characteristic on the app. After some research, I determined this is because of the custom UUID in which I would have to change the whole profile and assign a name to the UUID for it to be shown as conductivity characteristic on the nRF connect bluetooth scanner app. This is a later problem for when we figure out how to connect it with the iOS mobile app. The next steps involve figuring out how to connect this initial BLE setup with the iOS mobile app and ensure that the data is being sent and received correctly. Additionally, the button communication needs to be determined to figure out what value the microcontroller will receive to toggle heart rate and conductivity measurements at the input of a user.


Relevant Media
• Custom UUID generator
• ESP32 BLE Data Exchange Tutorial with ESP-IDF: Menuconfig and Code Implementation Explained
• UUID and characteristics rundown by Nordic



Entry 2: -----------------------------------------------------------------

Date: March 26th
Start Time: 8:30 am
Duration: 6 hours


• Began directly prototyping bluetooth with Espressif and the ESP32 by rewriting code and flashing with ESP32.
• Learned about the menuconfig to switch to the Nimble Bluetooth framework and debug all dependency/library errors.
• Successfully flashed the ESP32 microcontroller with rough skeleton code and verified connectivity with nRF connect bluetooth scanner app.
• Next steps involve creating characteristic profiles for heart rate, conductivity, and battery management modules.
Detailed Description: During this session, I began installing all the libraries I needed to actually build and flash and monitor the code. I had to install Espressif and tried the extension from VSCode, but this extension didn't work for our purposes. First I had to connect the Espressif IDE and ESP32 framework, like esp-idf, to make the code work, and later I learned from Herb's journal to use the following commands to build, flash, and monitor the code:

• source ~/esp/esp-idf/export.sh
• idf.py build
• idf.py flash monitor
After this, I was able to flash the code and monitor the output. However, my code still wasn't working. This is when I learned about the menuconfig piece of software where I had to go in and switch the Bluetooths. To do this, I ran

idf.py menuconfig

to get into the menu. Then I went to component config -> bluetooth -> bluetooth -> host, and switched the bluetooth from blueDroid - Dual mode to nimBLE so that it would work with the code structure I was creating. Now when I ran the idf.py commands, everything worked! Flashing the initial code skeleton from the video returned favorable results after finding the device with my nRF connect app that found all bluetooth devices and ensured they were working. HydraWise-BLE-Server was found and connected to, and the characteristics were present. Next steps involve further developing the bluetooth module by adding the specific sensor characteristics and connecting with the iOS mobile app.


Relevant Media
• Install esp-idf for ESP32
• ESP32 BLE Data Exchange Tutorial with ESP-IDF: Menuconfig and Code Implementation Explained



Entry 1: -----------------------------------------------------------------

Date: March 25th
Start Time: 3:00 pm
Duration: 2 hours


• Began preliminary research for directly prototyping bluetooth with Espressif and the ESP32.
• Learned about the modules and programs I need to install to get the connections established.
• Determined the different parts that go into characteristics and services.
• Next steps involve taking the initial code I started and working to flash it onto the ESP32 chip in lab.
Detailed Description: During this session, I started the pivot from Arduino prototyping to Espressif prototyping that would connect directly to the ESP32 chip. I began by watching the video tutorial by Ashish Saini. He goes into how to create a basic connection with read and write attributes and one characteristic. I learned about the menuconfig setup as well. I started coding up the process but didn't have a way to test it since I wasn't at lab to flash the ESP32 chip. Therefore, next steps involve heading to lab to flash the chip and test the initial setup of BLE.


Relevant Media
• ESP32 BLE Data Exchange Tutorial with ESP-IDF: Menuconfig and Code Implementation Explained



=============== Week 10: =================

Summary: -----------------------------------------------------------------

Hours this week: 0 hours
Cumulative Semester Hours: 94 hours
Description of this week:
Spring Break :)

=============== Week 9: =================

Summary: -----------------------------------------------------------------

Hours this week: 8 hours
Cumulative Semester Hours: 94 hours
Description of this week:
This week, I focused on continuing the Bluetooth tutorial by MoThunderz, which involved learning about how to set up the ESP32 and Arduino IDE and next steps involve completing the tutorial with Arduino before moving on to the actual Bluetooth and phone connection with HydraWise.

Entry 2: -----------------------------------------------------------------

Date: March 13th
Start Time: 5:00 pm
Duration: 5 hours


• Started prototyping with Arduino and ESP32 using the YouTube.
• Learned how to set up Arduino IDE with phone and ESP32.
• Ran into some trouble getting the software to recognize ESP32 and Arduino as Bluetooth devices.
• Researched how to work through the connectivity issues and solved them.
• Next steps involve working on completing the tutorial by MoThunderz.
Detailed Description: During this session, I headed to lab to finish up the Bluetooth tutorial by MoThunderz. I started prototyping with Arduino and ESP32 using the YouTube video. I learned how to set up Arduino IDE with phone and ESP32. I ran into some trouble getting the software to recognize ESP32 and Arduino as Bluetooth devices. The port wouldn't get recognized and the ESP32 kept going in and out of connection. I had to install Arduino IDE and the ESP-IDF library as well, in which the many versions and different download methods messed with the system. After a few tries, I finally got the right software so that the Arduino was able to run the check on the ESP-IDF notify example code. After debugging the code issues, I finally got to uploading the code to the ESP32. I researched how to work through the connectivity issues with the ESP32 since this connection also kept glitching. After a few reads through reddit and help from chatgpt, I solved this flashing issue as well. The next steps involve working on completing the tutorial by MoThunderz to set up client and others. I also need to begin the actual bluetooth connectivity with an iPhone and the ESP32-WROOM-32.


Relevant Media
• BLE with ESP32 tutorial part 1: The Server



Entry 1: -----------------------------------------------------------------

Date: March 12th
Start Time: 12:30 pm
Duration: 3 hours


• Began looking into the Bluetooth Interface Component of HydraWise.
• Learned about how to begin setting up the BLE connection from ESP32 and the phone from YouTube videos.
• Decided to go one level down and start prototyping with Arduino instead.
• Next steps involve flashing code to the microcontrollers to test connectivity and the interface.
Detailed Description: During this session, I began looking into the Bluetooth Interface Component of HydraWise. I learned about how to begin setting up the BLE connection from ESP32 and the phone from YouTube videos. I decided to go one level down and start prototyping with Arduino instead. This was a good decision because I learned that the ESP32 is a bit more complicated than I thought. I also learned that the ESP32 has a lot of different modes and settings that can be used to optimize the connection. Alongside starting the ESP32 - Arduino - BLE connection, I began learning about UUID and all the things that go into interfacing BLE. The next steps involve flashing code to the microcontrollers to test connectivity and the interface.


Relevant Media
• ESP32 BLE Data Exchange Tutorial with ESP-IDF: MenuConfig and Code
• BLE with ESP32 tutorial part 1: The Server



=============== Week 8: =================

Summary: -----------------------------------------------------------------

Hours this week: 8 hours
Cumulative Semester Hours: 86 hours
Description of this week:
This week, I focused on preparing the Midterm Design Review Presentation and refining the functional block diagram by using various sources on the internet to confirm my numbers and ensuring the block diagram was visually appealing and easy to understand.

Entry 3: -----------------------------------------------------------------

Date: March 5th
Start Time: 1:00 pm
Duration: 5 hours


• Shifted gears to the Midterm Design Review Template that Dr. Walter provided in the Brightspace assignment module.
• Looked into and added the rest of the major component modules.
• Learned about all the different alternatives that could go into the microcontroller, sensors, battery, buck-boost converter.
• Figured out we needed to color code and rework the block diagram so spent time with Herb to figure that out.
• Looked up datasheets to ensure I was getting the right specifications for each of the parts and the alternative components.
• Next steps involve researching other alternatives for the next couple components tomorrow.
Detailed Description: During this session, I shifted gears to the Midterm Design Review Template that Dr. Walter provided in the Brightspace assignment module. I looked into and added the rest of the major component modules, including the microcontroller, sensors, battery, and buck-boost converter. Adding these components involved extensive research in finding the specific voltage levels, current levels, accurate sizes, and more. I learned about all the different alternatives that could go into these components and how they would affect our design. Next, I realized from the other presentations I had seen while reviewing that we were missing a whole bunch from our presentation, including the color-coded functional block diagram and the various specifications that went into the pcb such as via widths and the presence of planes.

I headed to lab and decided to work on updating the functional block diagram. I color coded all the specific modules: power, sensors, microcontroller, and the app module. In lab, I consulted with my teammates about the layout of the block diagram and how to ensure that the modules were all up to date with out current project specification. In the end, Herb helped me route all the wires to the specific components to make the block diagram visually appealing. I also researched all the different interfaces to ensure I had the correct bus sizes and the correct communication interfeces between everything.it more visually appealing and easier to understand. Adding in all the different components to the block diagram was crucial in ensuring that our design is robust and flexible enough to accommodate any changes in components, and easy to communicate to everyone who reviews our presentation on. The next steps involve adding these updates to the presentation and locking everything in before tomorrow. March 6th is our huge presentation date.

Relevant Media
• tps63001
• bq21040
• ESP32-WROOM-32 for Bus Widths
• Understanding I2C Bus Widths
• BLE Interface Bus Widths
• A5 - Component Analysis
• Updated Slide Deck



Entry 2: -----------------------------------------------------------------

Date: March 4th
Start Time: 10:00 am
Duration: 2 hours


• Continued working on the slide deck.
• Looked into and added Battery Selection modules.
• Learned that the battery we are actually using wasn't the one that I had originally documented so I switched gears to the DTP502535.
• Looked up datasheets to ensure I was getting the right specifications for each of the parts and the alternative components.
• Next steps involve researching alternatives for the next couple components tomorrow and enhancing the tables with current specifications.
• Also need to refine the functional block diagram for our project by adding a color code key and the power module.
Detailed Description: Continuing work on the Midterm Senior Design Review slide deck, I focused on the process of adding the major components to the slide deck, specifically the Battery Selection module. I looked into the different alternatives we had on the Component Analysis document and added the specifications listed to the slide deck. Initially, I referenced our Component Analysis document, which detailed three potential lithium-ion polymer batteries with variations in power capacity, physical size, and current limits. However, I realized that the battery we had originally documented as the two alternatives in the slide deck was not the one we were actually using in the design. This was after I visited the lab and found the parts on the lab bench. This realization prompted me to shift focus to the DTP502535. This specific battery offers a nominal voltage of 3.7V, a power capacity of 400mAh, and a current limit of 400mA, making it a compact and efficient choice for our wristband-style wearable device. Since size is the biggest constraint, I verified that the DTP502535 battery's dimensions (0.98”W x 1.38”L) fit within our PCB housing without compromising the form factor or interfering with other components. Additionally, I cross-referenced datasheets to ensure that the cycle life, chemistry, and rechargeability of the battery matched our power requirements. The small power capacity is offset by our ultra-low power system design, ensuring the device functions optimally for several hours before requiring a recharge. By updating the slide deck with the correct battery specifications, trade-offs, and justifications, I improved the accuracy of our power management analysis. Next steps involve researching additional alternative components for the next set of system-critical modules to further strengthen our risk assessment and design flexibility. Additionally, upon glaces at the previous midterm design review presentations I was a peer reviewer for, I quickly realized how behind we were in terms of other parts we needed on the slide deck, such as the schematics, pcb, and block diagrams. I urged my team to lock in on these parts and also realized I need to work on color coding the functional block diagram since I was uninformed of the prototyping progress.
Relevant Media
• MIKROE-4474
• LP503562JU+PCM+2 WIRES 50MM
• DTP502535
• A5 - Component Analysis
• Updated Slide Deck



Entry 1: -----------------------------------------------------------------

Date: March 2nd
Start Time: 4:00 pm
Duration: 1 hours


• Created slide deck template for Midterm Senior Design Review.
• Referenced previous documents to find major components and their listed alternatives.
• Learned that a few components were missing alternatives.
• Added everything already present in the component analysis document.
• Next steps involve researching other alternatives for the next couple components tomorrow.
Detailed Description: I began working on the Midterm Senior Design Review slide deck by selecting a template from Slides Carnival. I sent an email to Jonathan to ensure it would meet course standards. I modified it to the senior design presentation template examples. I started adding the PSDRs, mission, and vision of the project. The next big section to add was major components. I referenced the Component Analysis document stored in our team's project folder to see what we had already documented as parts for HydraWise, checking to see if each part was documented with its function and specifications. I realized that a few components were missing alternative options and sections in general, particularly key electronic elements like sensors and power modules. This gap in information led me to cross-check previous documentation and verify if alternative components had been discussed in past meetings or files, like the product ideas document and the manlab notes document. After ensuring all available data was transferred into the slides, I planned the next steps, which involve conducting further research to identify alternative components for those that lack backup options. This research will be crucial in strengthening the risk assessment and feasibility sections of our midterm review, ensuring our project remains adaptable.

Relevant Media
• A5 - Component Analysis
• Beginning Slide Deck



=============== Week 7: =================

Summary: -----------------------------------------------------------------

Hours this week: 10 hours
Cumulative Semester Hours: 78 hours
Description of this week:
This week, I focused on refining the HydraWise housing component, iterating between TPU and Elastic50A materials at Bechtel, and advancing the battery charger prototype. At Bechtel, I learned the curing process for Elastic50A to maintain material integrity. The TPU iteration needed to be reprinted. After successfully retrieving the TPU model, I brainstormed design improvements with Johnny, discussing concavity, power button design, and hinge integration to ensure enhanced comfort and responsiveness. At ManLab, discussions with the team highlighted Elastic50A's limitations for Apple Watch band attachment, leading to TPU being favored for the housing. With the mechanical design stabilized, I transitioned to prototyping the battery charger, researching GPIO-based power state monitoring, and pushing the initial charging module code to GitHub. Additionally, I started preparing the Senior Design Midterm Presentation, drafting slides and gathering information from Matt and Herb for the PCB design overview. Next steps involve testing the battery charger prototype, finalizing the mechanical design, and completing the midterm presentation.

Entry 3: -----------------------------------------------------------------

Date: February 26th
Start Time: 12:30 pm
Duration: 5 hours


• Visited Bechtel to pick up my TPU print from the X7 printer.
• Brainstormed with Johnny about how to improve the design through thoughts like concavity, power button design, and a hinge for the bottom.
• Learned how to make the design concave and fix the power button.
• At lab, discussed mechanical properties with team and learned how Elastic50A may not be great for apple watch band attachement.
• Shifted gears to prototyping the battery charger by looking up the datasheet and communication protocols.
• Learned that GPIO is used for the battery IC along with status pins to determine charge levels.
• Set up initial configuration and pushed code to GitHub.
• Next steps involve shifting gears from mechanical design to prototyping the battery charger by testing code.
Detailed Description: During this session at Bechtel, I picked up my TPU print from the X7 printer with Johnny. I took out the supports and started assessing the model's structural integrity and flexibility for the HydraWise housing design. I brainstormed with Johnny, discussing potential improvements such as adding concavity for better wrist fit, refining the power button design, and incorporating a hinge mechanism for the bottom compartment to enhance usability. Johnny guided me through Fusion 360 techniques to create the concavity using reverse filet methods. He helped me figure out how to make the power button design so that it would actually be hollow and move to click a button inside the PCB. He advised that it would be attached through pressure points. For the hinge, I'll look up tutorials on YouTube in the future to figure out that design. Unfortunately, he said it wouldn't be possible to use multiple materials to print a model. Therefore, we can't make the HydraWise housing component using both TPU and Elastic50A. This was interesting to learn for sure. These changes will ensure a more ergonomic and comfortable fit while also improving responsiveness.
At ManLab, I met with my team to evaluate the mechanical properties of the prints where I realized that Elastic50A may not be ideal for attaching Apple Watch bands due to its flexibility, leading us to hold TPU in higher regard as our potential housing component. With the mechanical component reaching a stable iteration, I shifted focus to prototyping the battery charger, starting with an in-depth review of the datasheet and communication protocols. I learned that the battery IC uses GPIO and status pins to determine charge levels and power state, allowing for precise monitoring and control of charging behavior. Using this knowledge, I set up an initial configuration for the battery charging system. I wrote and pushed the first version of the code to GitHub.
Next steps involve fully shifting gears toward testing and refining the battery charger code, verifying its functionality through hardware tests and ensuring seamless integration into HydraWise's power management system.
Additionally, I began looking into the senior design midterm presentation. I found a template and began filling it out. I learned that the presentation is 70 something slides and I will need to reach out the Matt and Herb for most of the PCB information. Next steps involve continuing to put together this presentation for next week.

Relevant Media
• Battery Charger Datasheet
• Battery Management System Code



Entry 2: -----------------------------------------------------------------

Date: February 25th
Start Time: 3:30 pm
Duration: 2 hours


• Visited Bechtel to Form Cure my Elastic50A resin print from the Form3B+ machine series.
• Learned the proper settings for curing Elastic50A from timings to material handling.
• Learned there was another printing error for the TPU version so the staff restarted the print for me.
• Next steps involve heading to Bechtel tomorrow to pick up my prints.
Detailed Description: During this session at Bechtel, I began the curing process for my Elastic 50A resin print from the Form3B+ series, ensuring that the material would reach its intended mechanical properties of flexibility and durability. The Bechtel staff guided me through the proper curing settings - 60 degrees Celsius for 20 minutes for the initial curing process. Before I was able to move my model, I had to put on a lab coat and gloves since Elastic50A is a little bit toxic when it is fresh out of the printer. We took out the documentation to figure out curing times and temperatures. They emphasized precise timing, temperature, and handling techniques for Elastic 50A specificially. I learned that this material, along with others, have very particular curing settings that need to be followed to receive the right form and preserve mechanical properties. I learned that the curing process involves exposing the print to controlled UV light and heat, which helps further polymerize the resin. This effectively strengthens its tear resistance, elasticity, and long-term wearability. These properties are critical for HydraWise's mechanical design.
After the initial curing was done, the Bechtel staff helped me move my print from the cure machine to the drying machine. Drying would take around thirty minutes since it had to air dry and solidify. I had to wear gloves for the moving part again and set the temperature and timer correctly. By this time, lecture was about to start so I left my print to continue drying and headed to BHEE.
While at Bechtel, I also checked on the TPU version of my print, only to discover that there had been another printing error, which caused the print to fail. Will helped troubleshoot the issue and generously cleaned out the X7 from the Onyx material, added the TPU, and helped to restart the TPU print. This delay in the TPU print reinforced the importance of iterating with multiple materials to determine the most effective option for our final design.
After lecture was over, I headed back to Bechtel to pick up my Elastic50A print. The staff was a little surprised at how sticky the material still was after the drying process and advised me to rinse it off with cold water to get the stickiness to go away. I worked with the staff to remove all the supports within the model. There was so much that they taught me how to use wire cutters and the tiny knifes to chop away at the supports without tearing the model. At some points, the staff assisted in ripping out the parts that were had to reach or really firmly attached to the model. Unfortunately this did result in a little bit of tear but not too much that the design would be changed a ton. We spent fourty minutes doing this but then my next lecture was coming up so I left Bechtel and continued to smooth out the model in lecture.
The next steps involve returning to Bechtel tomorrow to pick up the TPU print, assess the dual qualities and determine with material best meets the HydraWise design requirements for comfort, durability, and functionality.

Relevant Media



Entry 1: -----------------------------------------------------------------

Date: February 24th
Start Time: 12:00 pm
Duration: 3 hours


• Visited Bechtel to remove my Elastic50A resin print from the Form3B+ printer.
• Learned the process of maintaining the form of the print and why we need to cure the Elastic50A material before it is ready to use.
• Scheduled Form Cure to cure the material for Tuesday.
• Scheduled TPU print.
• Next steps involve heading to Bechtel tomorrow to start to cure the printed model.
Detailed Description: During this session at Bechtel, I carefully removed my Elastic 50A resin print from the Form3B+ printer, ensuring my model remained intact throughout the extraction process. With guidance from the Bechtel staff, I learned the right way to handle my model so it wouldn't get deformed since Elastic50A is initially super soft and malleable straight out of the printer. The team explained that without post-processing and curing, the material remains in a semi-cured state, making it suceptible to unwanted stretching or warping or even finger prints. To maintain structural integrity, I was advised to handle the model gently and keep it in a stable environment until the Form Cure machine was ready. Unfortunately, it had back-to-back appointments today so I would need to come back tomorrow to initiate the Form Curing process. I stored the model in a secluded space on the lab benches in the printing center.
After I removed my model, I talked to the Bechtel staff some more to learn about the ins-and-outs of form curing. The Form Cure machine uses UV light and controlled heat to further polymerize the material, solidifying its properties and acheiving the intended durability, flexibility, and elasticity required for HydraWise's wearable design. Without proper curing, the material may not exhibit its full mechanical properties such as tear resistance and rebound elasticity with contribute to the comfort and longevity of the design.
After discussing the curing requirements, I scheduled a Form Cure session for Tuesday, setting up a time to complete this final stage of post-processing. The next steps involve returning to Bechtel tomorrow to begin the curing process, ensuring the material reaches its optimal mechanic performance.
Additionally, I wanted to see how my new design would fare with TPU. I created a reservation in the OS1 system to get my model printed with X7 machine. I sliced my model with Eiger and will return tomorrow to pick up my print hopefully.
After Bechtel, I headed to lab to see the team's progress. After talking with my team the resolution was that I would work on the battery IC charging module along with the presentation for next week. Next steps involve setting up the slides and getting the datasheet for the charging component from Matt.

Relevant Media
• Scheduling Platform at Bechtel



=============== Week 6: =================

Summary: -----------------------------------------------------------------

Hours this week: 8 hours
Cumulative Semester Hours: 68 hours
Description of this week:
This week, I focused on refining and printing the HydraWise housing component, integrating feedback on sensor placement, adding an E-Ink display slot, and switching to Elastic 50A resin for improved flexibility. Despite unexpected delays in the printing process due to errors and printer unavailability, I worked with Lily, Johnny, and Bechtel staff to resolve these issues, ensuring that the model was successfully restarted. Meanwhile, I developed flowcharts for A8, analyzing Herb and James's code, and verifying the software logic using Draw.io. Next steps involve curing the printed model, testing flexibility and sensor fit, and refining the mechanical and software components based on prototype feedback.

Entry 4: -----------------------------------------------------------------

Date: February 21st
Start Time: 3:00 pm
Duration: 1 hours


• At Bechtel, showed up for my Form Cure appointment.
• Found Johnny!! Unfortunately my print still had 3 hours 43 minutes remaining.
• Discussed materials with Johnny some more.
• Advised to return tomorrow at noon for the Form Cure appointment.
• Next steps involve heading to Bechtel tomorrow to start to cure the printed model and continuing work on A8.
Detailed Description: During this session at Bechtel, I arrived at Bechtel for my Form Cure appointment and found Johnny!! I hadn't seen him in forever. But unfortunately, my HydraWise print still had 3 hours and 43 minutes remaining, delaying the curing process. While waiting, I had a productive discussion with Johnny and the Bechtel staff about different material properties and their suitability for our wearable design, gaining valuable insights for future iterations. Based on his recommendation, I was advised to return tomorrow at noon for the Form Cure appointment once the print was completed. In the meantime, the next steps involve heading back to Bechtel tomorrow to cure the printed model and continuing work on A8, ensuring steady progress on both the mechanical and software components of the project.

Relevant Media
• Flexible Resin at Bechtel



Entry 3: -----------------------------------------------------------------

Date: February 20th
Start Time: 10:30 am
Duration: 4 hours


• At Bechtel, showed up for my Form Cure appointment.
• Distraught to find my model was never printed! :((
• Learned that there was an error in printing and staff had to cancel.
• Since they didn't have my model, they couldn't restart it yesterday.
• Lily generously offered to start my model again after she took hers out at 8:30 pm that night.
• Meanwhile, I developed flowcharts for A8 by understanding Herb and James's code.
• Next steps involve heading to Bechtel tomorrow to start to cure the printed model and continuing work on A8.
Detailed Description: During this session at Bechtel, I arrived at Bechtel for my scheduled Form Cure appointment, only to find that my HydraWise model was never printed due to a printing error, which led the staff to cancel the job. Unfortunately, since they didn’t have my model saved in the queue, they were unable to restart the print the previous day, causing further delays. Despite the setback, Lily generously offered to restart the print after removing her model at 8:30 PM, ensuring that my design would be processed overnight. She had me send my .stl file to her via email. I ensured that she was able to open it in PreForm before I left Bechtel that night. While this unexpected issue disrupted my timeline, it provided an opportunity to verify the printing workflow and troubleshoot potential issues for future iterations. The next steps involve returning to Bechtel tomorrow to begin the curing process once the model is successfully printed.

In the morning, I made progress on A8 by filling out all the software components and starting on the flowchart diagrams. I used draw.io to generate these diagrams and confirmed with James that what I had was correct. Results are below. Next steps involve working on the Battery IC flowchart for embedded and perhaps a flowchart for the pages of the iOS app. I also plan to start XCode tutorial videos so I can contribute to the software and processing software of HydraWise.

Relevant Media
• Draw.io flowchart maker



Entry 2: -----------------------------------------------------------------

Date: February 19th
Start Time: 11:30 am
Duration: 1 hour


• At Bechtel, sliced second iteration of HydraWise for Form3B+ printer with Elastic 50 using PreForm software.
• Set up Form3B+ by taking out old filament and adding Elastic50.
• Started the printing process on the printer.
• Next steps involve heading to Bechtel tomorrow to start the cure of the printed model.
Detailed Description: During this session at Bechtel, I prepared the second iteration of the HydraWise housing component for 3D printing using the Form3B+ printer with Elastic 50 resin. Using ProForm software, I carefully sliced the model, ensuring proper support structures and orientation for optimal print quality. Before initiating the print, I removed the old filament from the printer and loaded the Elastic 50 resin, a flexible material chosen for its durability and suitability for wearable applications. Once the setup was complete, I started the printing process, monitoring the initial stages to confirm proper adhesion and print stability. The next steps involve returning to Bechtel tomorrow to begin the curing process, which will solidify the resin and finalize the model for testing and evaluation.
Relevant Media
• Link to Overall Pre Form Software Website



Entry 1: -----------------------------------------------------------------

Date: February 18th
Start Time: 2:00 pm
Duration: 2 hours


• Reiterated HydraWise housing component on Fusion.
• Added place for e-ink display.
• Moved around sensor openings based on feedback from James and Matt.
• James added a USB-C port for charging but it didn't translate to my version so I recreated it.
• Went into Bechtel to try to print it. Told to return tomorrow when printer is free.
• Created new proposal with Lily and set up a time for printing.
• Next steps involve heading to Bechtel tomorrow to start printing.
Detailed Description: During this session, I refined the HydraWise housing component in Fusion 360, incorporating key design changes based on team feedback. I added a dedicated slot for the E-Ink display, ensuring proper placement for visibility and usability. Additionally, I adjusted sensor openings according to feedback from James and Matt, optimizing their positions for better accuracy and functionality. James had proposed moving the heart rate sensor so that it would be positioned over a certain vein on the wrist that, from his research, had the best readings of pulse. Matt and James both went back and forth with me about how the conductivity sensor should be on the outside of the watch so that the sweat would be collected from the forehead, especially since so little would be present on the wrist. James had initially added a USB-C port for charging, but the modification did not transfer correctly to my version, so I manually recreated it in Fusion to ensure proper integration. I also decided to move from TPU and test out a more flexible material that Bechtel had in stock: flexible resin. When I headed to Bechtel, Lily and Michael proposed Elastic 50A as a more flexible material. They also proposed that I make the shell thinner than 5 mm. After finalizing these design changes, I went to Bechtel to print the new iteration but was informed that the printer was unavailable, requiring me to return the next day. To streamline the process, I worked with Lily to create a new print proposal, securing a scheduled time for printing. The next steps involve heading back to Bechtel tomorrow to initiate the 3D printing process for the updated housing component. New Dimensions:
• Length: 50 mm
• Width: 26.09 mm
• Height: 80 mm
• Thickness: 3 mm

Relevant Media
• Bechtel Design and Innovation Center



=============== Week 5: =================

Summary: -----------------------------------------------------------------

Hours this week:15 hours
Cumulative Semester Hours: 60 hours
Description of this week:
This week, I focused on refining the HydraWise housing component in Fusion 360, incorporating changes like adjusting sensor placement, adding a display slot, and modifying thickness for improved functionality. I collaborated with the E-Ink team, gaining insights into their display module and gathering resources on potential LCD integration, power requirements, and circuit complexity. Next steps include printing iteration 2 at Bechtel, finalizing the display module setup, and discussing feasibility with team before integrating it into the design.


Entry 4: -----------------------------------------------------------------

Date: February 14th
Start Time: 3:00 pm
Duration: 4 hours


• Reiterated HydraWise housing component on Fusion.
• Continued discussion with E-Ink team about parts and their circuit setup.
• Received a couple links and pointers of how to integrate a display for HydraWise.
• Results of discussion in links below.
• Next steps involve printing iteration 2 at Bechtel and beginning to set up the display module.
Detailed Description: During this session, I reiterated on my HydraWise housing component design. I moved the conductivity sensor opening to the front and deleted extraneous parts. I also added a slot for the display. I changed the thickness of the shell to be 3mm instead of 5mm. I sent the file to James so he could add it to his Mechanical Design Overview. Next steps involve heading to Bechtel to get this second iteration printed. I met up with a member from the E-Ink team to discuss how they implemented their display module. I learned that in their perspective, E-Ink doesn't necessarily need to be connected to the pcb, although I need to check up on this with Matt. I got a couple links for the dev board and the display they were thinking of using. I also learned that their display uses around 13V of power and has a refresh rate of 1 to 2 seconds, but this is produced from the buck converter they're using. The circuit is also really complicated, but they said they could give me pointers when I start prototyping it. Next steps involve discussing what I learned with Matt after finalizing the parts that I think will work best with HydraWise. New Dimensions:
• Length: 50 mm
• Width: 26.01 mm
• Height: 80 mm

Relevant Media
• Potential LCD Display
• Potential LCD display 2.54 inches
• Favorable LCD display 1.54 inches 3 colors



Entry 3: -----------------------------------------------------------------

Date: February 12th
Start Time: 11:30 am
Duration: 3 hours


• Visited Bechtel to pick up printed prototype from TPU machine.
• Removed supports from printed prototype at Bechtel using pliers.
• Received feedback from Bechtel expert about how to improve design.
• Received feedback on project from Johnathan and Professor Walter.
• Went back and forth with teaching staff about the possibility of an LCD display .
• Continued discussion with team about adding an LCD display and how it would affect our project.
• Reached out to E-Ink team members about how their LCD display works.
• Results of discussion in image below, where Matt and I brainstormed what would go into the LCD display.
• Next steps involve iterating on my prototype to reflect Bechtel expert's and team discussion insights.
Detailed Description: During this session, I headed to the Bechtel Design and Innovation Center to pick up my printed housing component. I found that the bottom of the prototype had been a little messed up by the filament creation in the TPU machine. I discussed the printed housing component with the Bechtel experts about how to make it more flexible and suitable for HydraWise. We found that to make the buttons functional, I would need to make it thinner in tolerance and hollow. To make the overall object softer, I would need to find less stiff material or make the tolerance thinner. A flexible resin printer may suit my needs in this aspect, or finding softer TPU from somewhere. I took out the supports with pliers before heading to lab. In lab, we recieved feedback from our teaching staff. We still need to update our functional description to explicitly say buck-boost and detail a few more aspects of our design. I believe the mechanical component is still missing. I showed everyone the prototype I had printed and got lots of feedback through discussions. As a team we decided we needed to make it bigger for now to be able to fit our current ESP32-WROOM-32 devboard and the sensors. James said that the heart rate sensor would need to be in a specific position to capture pulse from a specific vein. Matt said the conductivity sensor would be on top of the product so the user could wipe sweat from their forehead to get a conductivity reading. With the teaching staff we discussed using apple watch wristbands as the band for HydraWise, with my design having the inserts to accomodate the bands. Results of this feedback were plenty. I know how to improve my design further, which is the next step. Additionally, I wanted to incorporate a display for the user to actively receive feedback from the watch itself that it was on. I discussed this with the teaching staff and my team. Matt and I brainstormed what would go on the screen. James thought about how it would impact the Bluetooth aspect of his code. Herb was worried about getting all the parts working. We left the discussion at that for now and Matt has notes about the implementation brainstorming. I began reaching out to the E-ink team to discuss their implementation and how it would fit for HydraWise based on this suggestion from the teaching staff. Next steps involve finding parts and researching how the LCD would be interfaced and integrated into the whole project.
Relevant Media



Entry 2: -----------------------------------------------------------------

Date: February 11th
Start Time: 9:30 am
Duration: 5 hours


• Continued relearning Autodesk Fusion.
• Visited lab to get exact measurements of esp-32 dev board, sensors and parts.
• Enhanced prototype on CAD software to suit the measurements of our parts.
• Visit Bechtel to make final changes to CAD file with experts at printing station.
• Filed a proposal and began the 13-hour print for the first iteration of my design.
• Results in orbital view below.
• Next steps involve returning to lab to pick up my design from the TPU machine.
Detailed Description: During this session, I visited ManLab to get the exact measurements of HydraWise's components that would fit into the housing diagram. I then went to WALC to change my design to reflect the new constraints. After my class I visited Bechtel to get my first prototype reviewed, sliced, and printed. First, Lily and I went back and forth on how my design would fit all the components needed for HydraWise. We decided we would have a hole at the bottom to insert the components, and then in a future iteration make it into a flap so it can be closed after the components are inserted. Lily also helped me make my design hollow using the Shell tool in Fusion. Then we went ahead and sliced the design in Eiger to get it ready for printing. Once the previous user came in and removed his print, he helped me set up the settings for my design to get printed on the TPU machine. Results of the revised prototype is in the video below. Next steps involve returning to Bechtel to see how my design ended up in real life.
Relevant Media
• Software for slicing Fusion prototype
• Material Used for Prototype Printing: thermoplastic-polyurethanes-tpu



Entry 1: -----------------------------------------------------------------

Date: February 10th
Start Time: 3:30 pm
Duration: 3 hours


• Continued relearning Autodesk Fusion.
• Enhanced prototype on CAD software through following apple watch tutorial.
• Visit Bechtel to see Johnny at TPU printing center.
• Results in orbital view below.
• Next steps involve developing a new model with the dimensions chatgpt has given me.
Detailed Description: During this session, I continued the tutorial of the apple watch in Fusion. I added the clasp and the battery compartment on the back. After finishing the modeling basics of this tutorial, I have a very good skillset of how to operate AutoDesk Fusion. I hope I can finish prototyping before my 30-day free trial runs out. Once I finished the final apple watch modeling, I headed to the Bechtel Center to see Johnny. Johnny looked at my sketch for me and gave me a few pointers of how to enhance the design for our purposes. He proposed the following:
• Develop only the compartment that will hold our sensors, pcb, and other various devices.
• Order a whole bunch of apple watch wristbands - $12 for 16 pack, link in relevant media.
• Use extrusion and shell and similar tools in Fusion to make the model fit our things.
• Come back at 2:30 pm tomorrow to get it printed for Show Me a Thing on Wednesday's lab!
Once I complete the new prototype for HydraWise, we will have a working mechanical prototype and an iterable CAD model in Autodesk Fusion. Next steps involve developing a model to fit our components, including cross checking with our parts once everything comes in.
Relevant Media
• Autodesk Fusion: Apple Watch Tutorial
• Silicon Watch Band



Entry 5: -----------------------------------------------------------------

Date: February 7th
Start Time: 9:30 pm
Duration: 5 hours


• Continued relearning Autodesk Fusion.
• Continued development of wristband design based on initial sketch using tools in Autodesk Fusion and tutorial from YouTube.
• Used chatgpt to get total dimensions of packaging of hardware components.
• Results in orbital view below.
• Next steps involve iterating on this model by adding HydraWise-specific dimensions.
Detailed Description: I continued relearning Autodesk Fusion 360, refining my understanding of advanced modeling techniques such as parametric constraints, lofting, and filleting to improve the structural design of the HydraWise wristband. Building upon the initial sketch, I further developed the 3D model with the YouTube tutorial for the goal of integrating more precise component housings, ensuring that the internal hardware—such as the ESP32-WROOM-32E, battery, sensors, and Bluetooth module—would fit securely within the wristband casing. To achieve accurate measurements, I utilized ChatGPT to estimate the total dimensions of the hardware packaging, ensuring that the device's layout was compact while maintaining accessibility for assembly and future modifications. Additionally, I refined the ergonomic curvature of the wristband, considering user comfort and durability, while testing different material thicknesses to accommodate TPU/flexible resin for flexibility and water resistance. The orbital view of the updated design highlights the current iteration of the model, showing refinements in both form and function. The next steps involve iterating on this model, further optimizing dimensions for component placement, adding fastening mechanisms, and preparing the design for 3D printing and real-world testing.
Relevant Media: ChatGPT's regurtitation of dimensions

Dimensions of Components

AMS1117-3.3 Voltage Regulator (SOT-223)

Length	Width	Height
6.34 mm	3.44 mm	1.61 mm

LFS1K0.1107.2I.B.070-6.S Sensor

Length	Width	Height
16.9 mm	9.9 mm	0.65 mm

PIM438 MAX30101 Breakout Board

Length	Width	Height
19 mm	19 mm	3.2 mm

ESP32-WROOM-32E Microcontroller on Devboard

Length	Width	Height
58.4 mm	26.0 mm	4.5 mm

Total Dimensions (Assuming Stacking)

Total Length: 58.4 mm (ESP32 devboard) + 19 mm (PIM438) + 16.9 mm (LFS1K0 sensor) + 6.34 mm (AMS1117) = 100.64 mm

Total Width: The widest component is 19 mm (PIM438 breakout board and ESP32 devboard).

Total Height: 4.5 mm (ESP32 devboard) + 3.2 mm (PIM438) + 0.65 mm (LFS1K0 sensor) + 1.61 mm (AMS1117) = 10.96 mm

Final Total Dimensions (Stacked on Top of Each Other)

Length: 100.64 mm
Width: 19 mm
Height: 10.96 mm

This gives you a rough estimate of the total stacked dimensions of the components with the ESP32 microcontroller board included.

• Autodesk Fusion: Apple Watch Tutorial



Entry 4: -----------------------------------------------------------------

Date: February 7th
Start Time: 4:30 pm
Duration: 2 hours


• Began relearning Autodesk Fusion.
• Created initial wristband design based on sketch using tools in Autodesk Fusion.
• Results in image below.
• Next steps involve iterating on this model.
Detailed Description: I began relearning Autodesk Fusion 360, revisiting key modeling techniques such as parametric design, extrusion, filleting, and assembly constraints to ensure accuracy in creating a functional and ergonomic wristband for the HydraWise device. Using the initial prototype sketch as a reference, I applied these tools to construct the first iteration of the wristband design, focusing on form factor, structural integrity, and component housing. I incorporated features such as a curved ergonomic fit to enhance comfort, slots for sensor placement, and a snap-fit clasp mechanism to ensure secure wearability. The model was refined through multiple adjustments to dimensions and curvature, resulting in a preliminary 3D design ready for further testing and evaluation. The next steps involve iterating on this model, incorporating flexibility simulations, testing potential material thickness variations, and ensuring compatibility with TPU/flexible resin for durability and comfort in real-world use.
Relevant Media:
• Wristband Tutorial
• Watch Band



Entry 3: -----------------------------------------------------------------

Date: February 7th
Start Time: 2:30 pm
Duration: 1 hours


• Visited Knowledge Lab and Bechtel Innovation Center.
• Browsed materials and parts with help from experts.
• Discussed prototyping HydraWise.
• Determined that TPU/flexible resin from Bechtel is ideal.
• Next steps are creating CAD prototype in Fusion.
Detailed Description: I visited the Knowledge Lab and the Bechtel Innovation Center to explore available materials and components for prototyping the HydraWise device. With assistance from lab experts, I browsed various materials, including different types of plastics, flexible resins, and adhesives, to determine the most suitable option for our wearable hydration sensor. During discussions about the HydraWise prototype, we considered factors such as durability, flexibility, and water resistance, which are essential for ensuring user comfort and device longevity. After evaluating multiple materials, I determined that thermoplastic polyurethane (TPU) and flexible resin from Bechtel would be the best choices, as they provide the necessary flexibility for a comfortable fit while also offering durability and water resistance to protect internal components. This decision helps ensure that the final design is both functional and wearable. The next steps involve creating a CAD prototype in Fusion 360 to model the housing structure before moving forward with 3D printing and physical testing.
Relevant Media:
• Espressif ESP32-WROOM-32E Datasheet
• Espressif ESP32-H2-MINI-1 Datasheet



Entry 2: -----------------------------------------------------------------

Date: February 6th
Start Time: 11:00 am
Duration: 3 hours


• Continued researching microcontrollers via internet.
• Added findings to A5.
• Chose ESP32-WROOM-32E for our project.
• Next steps involve ordering ESP32-WROOM-32E.
Detailed Description: During this session I continued researching microcontrollers through various online sources, comparing different models based on processing power, power efficiency, wireless communication capabilities, and compatibility with our project requirements. My findings were added to A5: Component Analysis, detailing specifications such as clock speed, memory capacity, power consumption, and peripheral support for each microcontroller considered. After evaluating multiple options, I selected the ESP32-WROOM-32E as the best fit for our project due to its dual-core processor, built-in Wi-Fi and Bluetooth Low Energy (BLE) capabilities, and low power consumption, which aligns well with our wearable hydration sensor’s need for efficient data transmission and power management. Additionally, its extensive support for IoT applications and availability of development resources made it a strong candidate. The next steps involve finalizing procurement and ordering the ESP32-WROOM-32E to begin hardware testing and software integration.
Relevant Media:
• Espressif ESP32-WROOM-32E Datasheet
• Espressif ESP32-H2-MINI-1 Datasheet



Entry 1: -----------------------------------------------------------------

Date: February 5th
Start Time: 12:30 pm
Duration: 3 hours


• Received feedback: func. desc. & hardware PSDRs.
• Battery management system ideation w/ IC and a coulumb counter algorithm.
• Mechanical Design: detailed sketch w/ James on my iPad.
• Jonathan advice: materials for mechanical implementation.
• Next steps involve finalizing the mechanical design and exploring waterproofing materials.
• Microcontroller research for A5: Component Analysis
Detailed Description: During this session at ManLab, we received feedback on our functional description and PSDRs, focusing primarily on hardware components. We explored the idea of adding a battery management system with an integrated circuit and a Coulomb counter algorithm to improve efficiency. For the mechanical design, I worked with James to sketch an initial prototype on my iPad, using different colors and annotations to highlight each feature. Jonathan suggested using silicon-based glue guns or similar materials to waterproof our product. I also researched sources for mechanical prototyping, identifying WALC Knowledge Lab and Bechtel Design and Innovation Center as potential facilities. Additionally, I contributed to microcontroller research for A5: Component Analysis, evaluating different options before selecting one for our project. The next steps involve finalizing the mechanical design, exploring waterproofing solutions, and beginning the implementation of our chosen microcontroller. We also need to complete A5, the Component Analysis, as a team. I worked on the Microcontroller analysis.
Relevant Media:
• Potential IC
• STM32 Microcontroller from recent 362 classes



=============== Week 3: =================

Summary: -----------------------------------------------------------------

Hours this week:12 hours
Cumulative Semester Hours: 31 hours
Description of this week:
This week, I focused on refining the Software Development Report and improving system logic through flowcharts and state diagrams. I explored Bluetooth functionality, microcontroller interactions, and user input states, collaborating with peers and gathering insights from external resources to enhance our design. With feedback from mentors, I refined our PSDRs, developed structured diagrams, and set the next steps for finalizing software architecture and implementing power efficiency modes.


Entry 4: -----------------------------------------------------------------

Date: February 1st
Start Time: 7:00 am
Duration: 4 hours


• Roadtrip: finalized flowchart and state machine diagram sketches.
• Discussed functionality with team members to reduce overall flow to three concise diagrams
• Next steps involve implementing the logic from the final flowcharts we create.
• Contributes to Software Overview.
Detailed Description: During this session, I finalized all flowcharts required for the software overview. Through sources like ChatGPT, researchgate papers, and documentation from previous links I had visited, I made detailed sketches of what I envisioned the software to entail. The images are below. I used my iPad to sketch out these flowcharts after using the internet to confirm my ideas against what is already out there. The result of this was a deeper understanding of how Bluetooth works, how data processing will occur for HydraWise, and how all the components will communicate in terms of software. This contributed to the Software Overview of our project. Next steps involve beginning to implement the logic in these flowcharts and state diagrams to see what works and revise as needed.
Relevant Media:
• Espressif ESP32 Bluetooth Architecture
• An Intelligent Sensor Based System for Real Time Heart Rate Monitoring (HRM)



Entry 3: -----------------------------------------------------------------

Date: January 31st
Start Time: 12:00 pm
Duration: 4 hours


• ManLab: created initial state machine diagram sketch.
• I talked to groups who had created their state diagrams and learned they had one for each specific functionality (bluetooth, light sensing, motion sensing, APIs, etc.)
• Began exploring Bluetooth flow charts.
• Revised initial state diagram sketch on the whiteboard to the intermediate version attached in the image.
• Next steps involve developing the final state diagram and flow charts for the app and microcontroller including Bluetooth research I developed.
• Contributes to Software Overview.
Detailed Description: During this session, I created an initial state machine diagram sketch and engaged with other groups to understand their approach to state diagrams, learning that they developed separate diagrams for each specific functionality, such as Bluetooth, light sensing, motion sensing, and APIs. Using this insight, I began exploring Bluetooth flow charts and revised my initial state diagram sketch on the whiteboard, refining it into an intermediate version. This revision helped clarify the data flow and interactions between system components. The result of this session was a more structured approach to state diagrams, improving the organization and modularity of the software design. This work contributes to the Software Overview by providing a clearer understanding of system behavior and communication flow. The next steps involve finalizing the state diagram and developing detailed flow charts for both the app and microcontroller, incorporating the Bluetooth communication research I conducted.
Relevant Media:
• Bluetooth Overview
• States of Bluetooth
• Examples of Bluetooth Functional Flow



Entry 2: -----------------------------------------------------------------

Date: January 30th
Start Time: 3:30 pm
Duration: 2 hours


• Met at the lab before lecture to make progress on the Software Development Report.
• Split tasks up into researching data types, determining app user interfaces, determining Microcontroller user interfaces, and determining state diagram logic flow.
• I began researching methods of developing state diagrams for our project using ChatGPT to brainstorm sources to learn state machine diagrams and software flow charts.
• I devised three main categories: the microcontroller's data flow process, the app flow process, and a mini flow diagram for the bluetooth functionality. I also considered adding in an LED aspect to our band.
• I visited WALC's knowledge lab to gather a sense of what materials we could use to develop our wearable hydration sensor. I met with a few people and discussed the parts available that could fit electronic parts.
• Next steps involve relearning all the aspects of flow charts and state machine diagrams.
Detailed Description: Before lecture, our team met at the lab to work on the Software Development Report, dividing tasks into researching data types, app user interfaces, microcontroller user interfaces, and state diagram logic flow. I focused on researching methods for developing state diagrams, categorizing them into three key areas: the microcontroller’s data flow, the app’s flow process, and a mini flow diagram for Bluetooth functionality, while also considering an LED aspect for the wearable band. To explore material options for the hydration sensor, I visited WALC’s Knowledge Lab, where I discussed available electronic component housing with lab members. From this, I gained insight into potential materials and confirmed the feasibility of incorporating electronic parts into the wearable design. This research contributes to the project by laying the foundation for structured software logic and hardware integration. The next steps involve relearning state machine diagrams and refining the state flow for the microcontroller and app.
Relevant Media:
• Lucidchart: UML State Machine Diagram
• GeeksforGeeks: UML State Diagrams
• Visual Paradigm: Flowchart Tutorial
• GeeksforGeeks: Introduction to Flowcharts



Entry 1: -----------------------------------------------------------------

Date: January 29th
Start Time: 12:30 pm
Duration: 2 hours


• Received feedback from the teaching assistant, Professor Walter, and Shivam during week two ManLab.
• Advised to make the PSDRs more concise.
• Explored methods of flowchart and state machine diagram development for the Software Doc
• Brainstormed user inputs for optimizing hardware such as low power mode and high power mode.
• Next Steps: Refine PSDRs, explore low-power and high-power system modes, create flowcharts and diagrams for Software Overview
Detailed Description: During week three of ManLab, our team received feedback from Jonathan, Professor Walter, and Shivam which guided our approach to refining our PSDRs and overall functionality of HydraWise. Specifically, we received ideas of narrowing our PSDRs to one specific measurable bullet point attacking a core hardware or core software aspect of the project. After our feedback session we began brainstorming methods for developing our flowcharts and state machine diagrams. This involved processing feedback from our three mentors for user-input functionality like implementing low-power and high-power modes to optimize hardware efficiency. Results involved gaining a clearer understanding of system interactions. Next steps entail cleaning up our PSDRs, creating iterative drafts of the state machine diagrams/flow charts, and integrating the proposed power modes into our system design.



=============== Week 2: =================

Summary: -----------------------------------------------------------------

Hours this week:8 hours
Cumulative Semester Hours: 17 hours
Description of this week:
The team refined PSDRs, completed sections of A2, conducted sports science research, explored iOS development, and brainstormed technical aspects like power, sensors, and microcontrollers through meetings and collaborative efforts.


Entry 3: -----------------------------------------------------------------

Date: January 25th
Start Time: 3:30 pm
Duration: 4 hours


• Met on a call to work on and finalize A2, focusing on section four as a team.
• Researched sports science and sweat analysis to build a user story for the HydraWise device.
• Investigated the physiological significance of electrolytes (sodium, potassium, chloride) in hydration and athletic performance.
• Explored the Nernst equation to understand how ion-selective electrodes measure electrolyte concentrations in sweat.
• Bridged the gap between sweat science and practical applications, focusing on real-time hydration monitoring for athletes.
• Conceptualized how to present scientific insights to users through intuitive feedback, such as hydration scores and recommendations.
• Generated ideas for integrating hydration awareness and actionable science into the device's user story.
Detailed Description: Our team met on call for a couple hours to finish A2. I worked on researching the user story with a focus on the sports science section in theory of operations. We finished section four of A2 together. I dived into sports science and sweat analysis to build a foundational understanding for the HydraWise device's user story. I researched the role of electrolytes such as sodium, potassium, and chloride in maintaining hydration and athletic performance, emphasizing their physiological significance in preventing dehydration and optimizing recovery. Using the Nernst equation, I explored how ion-selective electrodes measure electrolyte concentrations in sweat, translating these values into actionable insights for users. This research bridged the gap between sweat science and real-world applications, focusing on how hydration monitoring can empower athletes to track their electrolyte levels in real time, optimize their fluid intake, and improve performance. I also considered how these scientific principles could be presented to users through intuitive feedback, such as hydration scores or personalized recommendations, making the device both educational and practical. This session concluded with ideas for integrating these concepts into the user story, highlighting the importance of hydration awareness and the science behind it.



Entry 2: -----------------------------------------------------------------

Date: January 23rd
Start Time: 2:30 pm
Duration: 2 hours


• Met at the lab before lecture four to work on A2 as a team.
• Completed the user needs section and began researching the sports science aspects of the project.
• Added bullet points summarizing the group's discussions as we reviewed the document for the first time.
• Searched for parts collaboratively, with a focus on finding a suitable electrolyte sensor.
• Explored iOS application development by consulting a friend and reviewing basic documentation.
• Conducted competitor analysis to understand their approaches, noting that hDrop uses reverse engineering to detect a lack of electrolytes rather than capturing their levels.
• Updated the software PSDRs with additional details based on feedback received during ManLab.
Detailed Description: Our team met up before lecture four at the lab. We worked on A2 first. I finished the user needs section and began researching the sports science behind our project. I added in bullet points of our group discussion as we went through the document for the first time. We continued searching for parts together, especially the electrolyte sensor. I also learned about how to develop the iOS application for our project through asking a friend for pointers and looking at the basic documentation. Additionally, I looked up more competitor analysis to see where they get their science from and to browse their documentation. I didn't really find anything in depth from our competitors. However, we did find out that hDrop reverse engineered the analysis of sweat. Instead of capturing electrolyte levels, they check for a lack thereof. Lastly, I updated the software PSDRs by adding more detail per the feedback we received during ManLab.



Entry 1: -----------------------------------------------------------------

Date: January 22nd
Start Time: 12:30 pm
Duration: 2 hours


• Received feedback from the teaching assistant, Professor Walter, and Shivam during week two ManLab.
• Advised to make the PSDRs more technical and measurable, focusing on the HOW's of the project.
• Improved the PSDRs by mapping out ideas for hardware and software PSDRs on the whiteboard.
• Created a To-Do list in bullet points for the lab session and weekly deliverables.
• Brainstormed functional aspects of the project, identifying research needs for power, sensors, and the microcontroller.
• Set a meeting time for the following day to continue researching and working on weekly deliverables.
Detailed Description: During week two ManLab, our team received feedback from our teaching assistant Johnathan, Professor Walter, and Shivam. We were advised to re-do our PSDRs to become more technical and measurable. They are the HOW's of our project while our project description is the WHAT. After our feedback session, we worked to improve the PSDR's to become more technical. I mapped out our big ideas on the whiteboard so we would have bullet points of everything we listed as hardware PSDRs and software PSDRs. Next I made a To Do list in bullet points for the rest of the lab session and weekly deliverables. Through brainstorming we decided that we needed more research on the functional pieces of our project involving power, sensors, and the microcontroller. We finished by setting a meeting time for tomorrow at 2 pm to research the points from our whiteboard and work on weekly deliverables.



=============== Week 1: =================

Summary: -----------------------------------------------------------------

Hours this week:9 hours
Cumulative Semester Hours: 9 hours
Description of this week:
The team kicked off with lab orientation, learning course logistics, touring resources like ESP32 microcontrollers, and setting up the project website. We completed A1 by drafting the project proposal, assigning team roles, brainstorming design requirements, and planning the budget through collaborative discussions.


Entry 3: -----------------------------------------------------------------

Date: January 19th
Start Time: 3:00 pm
Duration: 5 hours


• Created a shared OneDrive storage space for project documents on January 17th and shared access with team members.
• Developed a detailed software document outlining the tech stack for both basic and advanced system setups.
• Included frameworks, libraries, and cloud solutions for frontend, backend, sensor integration, and analytics in the document.
• Designed wireframes and mockups for the iOS app, highlighting features such as a dashboard, insights, notifications, and device pairing.
• Created a cohesive design document with potential logos, color schemes, and gradient suggestions for the HydraWise branding.
• Finalized ideas for the app’s core functionality and user interface to ensure an intuitive and user-friendly experience.
Detailed Description: I created a shared OneDrive storage space for project documents on January 17th and ensured it was accessible to all team members. During this session on Saturday, January 19th, I developed a detailed software document outlining the tech stack for both a basic and advanced system setup. This included frameworks, libraries, and cloud solutions for frontend, backend, sensor integration, and analytics. Additionally, I designed wireframes and mockups for the iOS app, along with a cohesive design document that included potential logos, color schemes, and gradient suggestions. The app design focused on features such as a dashboard, insights, notifications, and device pairing. I concluded with finalizing ideas for the app’s core functionality and user interface.



Entry 2: -----------------------------------------------------------------

Date: January 17th
Start Time: 11:30 am
Duration: 2 hours


• Met as a team to work on A1: Final Project Proposal.
• Completed sections of A1, including the functional description and initial Project Specific Design Requirements (PSDRs).
• Assigned team roles, responsibilities, and homework tasks for the project.
• Brainstormed parts required for the project budget and discussed their feasibility.
• Collaborated on each section of the document, adding input as a team to ensure completeness.
• Finished A1 and wrapped up the session with additional brainstorming for next steps.
Detailed Description: Our team met up to work on A1. We started filling out the A1 document. Completing A1: Final Project Proposal involved writing a functional description, deciding team roles and responsibilities, deciding homework assignment responsibilities, brainstorming parts for the budget, and mapping out our initial Project Specific Design Requirements. We ran through each section as a team, adding input to what would be typed as we addressed each section of the document. We brainstormed amongst ourselves to figure out what parts we needed and everything. Once we completed A1, we brainstormed some more then called it a day.



Entry 1: -----------------------------------------------------------------

Date: January 15th
Start Time: 12:30 pm
Duration: 2 hours


• Met at BHEE 007 for the first lab session and started at station 13.
• Attended a briefing with Professor Walter on course logistics and lab procedures.
• Participated in lab tours and TA introductions, learning about available resources such as ESP32 microcontrollers and heart rate monitors.
• Took team photos after completing the lab tour and materials overview.
• Introduced the project to teaching assistants and signed FERPA waivers.
• Set up the project website by mapping the drive and adding initial team and project information to .html files.
• Concluded the session by brainstorming project specifications as a team.
Detailed Description: Day One involved meeting up at BHEE 007 for our first lab session. We started off at station 13. When Professor Walter arrived, we all met in the middle and learned about the general course logistics. Next, the Professor split us up into lab tour groups and TA interview groups. Since Matt had to leave early for class, we got the lab tour first. We were shown where all the parts were that we could use and borrow. ESP32 microcontrollers, heart rate monitors, and more are available to us. After the tour of the lab stations and materials we took team photos. The second half of the lab inovled introducing ourselves to the teaching assistants and signing FERPA waivers. We gave them a run-down of our project. The last part of the day involved setting up the website. We mapped the drive to our system and began adding information in the .html files for our team information and basic project description. We finished with brainstorming the project specifications and called it a day.