ECE477 Course Documents

Project Journal for James Neff

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

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

Date: 4/25/25
Start Time: 8:30am
Duration: 9.00 hours

With our issues flashing code, we were trying to figure a way to be able to flash code regularly
Need to solder conductivity circuit onto the PCB before demo
Once again began analyzing the whole PCB, checking voltages to try and find the issue

This was a very lengthy process
Were unable to find anything unusual that may be the source of the issue

Continued repeatedly attempting to flash with slightly different configurations in the terminal command, button presses, and trying to ground things properly
In the meantime we worked on connecting the flywiring circuit to the PCB
After connecting board we attempted flashing again and were able to flash successfully, as well as reset and start executing the code

Likely connecting the ground of the flywire board to our PCB did something to fix the issue

Our next task was to fit the design in packing
Basic layout was to have the battery and heart rate sensor on the bottom, taped down
The flywire board was sit on top of the PCB, and then the conductivity sensor was above that - taped to the roof of the packing, also needed to be super secure so liquid wouldn't enter the packaging
Had to resolder new wires onto heart rate sensor to get it to fit properly within the packaging

Header pins were a little long and made it difficult to close packaging properly, but not worth changing this close to the demo

We were able to successfully demo all PSDRs and one stretch, will make some adjustments before spark challenge mainly to do with packaging

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

Date: 4/24/25
Start Time: 11:30am
Duration: 8.00 hours

Today we started with continuing to debug the conductivity circuit
Since they circuits layout looked correct, Jonathan suggested examining the soldering of each piece, as there could be some faulty connections in relation to that
Resoldered some components to the board, a couple areas looked like they could have wires inadvertently touching and have a couple bad connections
We were able to get better values, appeared to fix the issue, could get voltage readings as desired, between 1.1 and 1.5V
Worked with alex to readjust the DAC wave we were producing, as we had to adjust the frequency and offset of the wave we were using

Used the AD2 to read the signal being produced and verify we configured it properly

We had Xiang help us desolder a microcontroller and then resolder it, because we were having issues on this board with our I2C communication with the heart rate sensor
Afterwards we begun testing flashing

We could flash, but were unable to run the code when reset was pressed, it would instead enter download mode

Started having problems with this board and flashing the code, issue seemed to be stemming from GPIO0 connected to the reset button
We checked voltage levels across the board to make sure they were correct
We could sometimes get it to run if the ground and GPIO0 on the micro were connected to the multimeter probes for some reason
Shivam suggested there may be an issue with our ground, that there may be multiple grounds on the board causing issues
Took data for the conductivity circuit to build logic to determine user's hydration levels

Used 3 salt levels, and averaged readings for each to get the thresholds
Created a line of best fit to determine what to correlate the voltage level to as a electrolyte concentration in the sweat

Tried flashing code again to board but now can't get it to flash – related to this problem with ground and potentially a floating pin
Need to figure out tomorrow a way to fix our problem, although it will be very hard as we can't flywire or anything given the configuration of our microcontroller

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

Date: 4/23/25
Start Time: 9:30am
Duration: 5.00 hours

Today we worked on testing the integration of heart rate sensor, microcontroller, and Bluetooth connection
We were able to connect the microcontroller on our PCB and the app – confirming the problem was the name

Edited the app to search for device named "HydraWise"

We were able to receive data on the app and display it properly
Matt soldered the conductivity circuit on the flywire board, but were having trouble getting the correct output as we did with the circuit Jonothan built on the breadboard
I spent a lot of time debugging this circuit

Checking all our resistors and capacitors were connected properly, and that they were in the right locations
Checked all the inputs and outputs to our op amps

Soldered on wires to supply our 3.3V rail and GND rail
Measured voltages at all nodes to ensure they were having the proper readings, and all seemed to be correct
Next steps will be to continue to debug the conductivity circuit, we need to get that working ASAP

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

Date: 4/22/25
Start Time: 9:30pm
Duration: 2.00 hours

After essentially ruling out all hardware issues related to the Bluetooth problems, we started looking into software issues
We first worked on creating a simple script to run just Bluetooth on the microcontroller
With this new script we were able to successfully advertise the device and pick it up on the NRF scanner, this lets us confirm the issue is within our code, as the Bluetooth is capable of successfully broadcasting
Next, we begun adding components of our Bluetooth code to the new script we had and continued testing after each additional implementation to see where it would stop working to find the issue
We added our services and our advertising function to the script

Script was able to still run successfully

Next we named the device from "ESP32-BLE" to "HydraWise-BLE-Server"

Device stopped appearing

Tried out old code with a shorter name and was able to see this as well

So it seems our problem just came from the device name being too long

Tomorrow will try to pair with the app, but this is a big hurdle to overcome and we can now focus on getting remaining hardware on the board working

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

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

Date: 4/18/25
Start Time: 11:30am
Duration: 2.50 hours

A TA helped to solder a new microcontroller on our 5th PCB, since our previous two had poor soldering
Today I soldered all the circuitry related to the microcontroller and the I2C lines
Were able to flash code successfully and connect with the heart rate sensor, indicating soldering was done correctly
Still had issues with Bluetooth, indicating it is not a hardware issue given how many times it has failed to work given the number of boards and controllers we have used
Began researching possible causes for the fault

In theory devboard and controller on PCB are pretty much the same, so currently it is unclear why it would fail to work on PCB if it does on the devboard

Inside of our Bluetooth file we have a few potential issues with our code

Not setting a couple of parameters properly

Channels are zeroed out, so advertising is happening on 0 channels instead of the default 3 channels
Worked on the devkit because it likely uses a helper to initialize these built-in parameters to default values before we accidentally set them to

Next steps will be to make some adjustments to our code and test again

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

Date: 4/16/25
Start Time: 9:00am
Duration: 5.00 hours

Went to ECE shop and got the new board X-rayed

Looked much better than previous one, all of the connections looked solid according to people at the shop

With Alex we soldered on resistors and capacitors necessary for microcontroller operation as well as buttons needed to flash code to the microcontroller
Attempted Bluetooth connection again

Once again failed to connect on app and also failed to read anything on the NRF scanner
Indicates there is a problem in the initialization, as no signal is being broadcasted

Tried again with the I2C connections and still had trouble

Getting weird voltage reading across pins on the sensor

Power pin was around 1 volt (should be 3.3V)
SDA and SCL lines were around .5 volts below 3.3V

TA pointed out that the connection could be faulty between the sensor and the board

Used helping hand to ensure a solid connection at all the pins
Read better voltages at all pins but failed to resolve the issue

Used oscilloscope to monitor the SDA and SCL lines

SDA line was communicating, but SCL line was idle at around 2.7V

We tested on old board again with new technique to connect the sensor with the helping hand and we were able to achieve successful connection

Probably hardware error on other board
Confusing because in theory this board has very poor connections and the other one has much better ones

After a lot of trial and error, we were finally able to achieve successful I2C communication, which is one of our PSDRs
Jonathan helped us build a new circuit for our conductivity sensor

We should get a reading more similar to a sine wave

Next steps will be to continue debugging the Bluetooth, also will need to work on fly wiring our new conductivity circuit

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

Date: 4/15/25
Start Time: 2:00pm
Duration: 3.25 hours

Today we tried out some of the fixes recommended to us
Tried booting again without the resistors, still not working – so problem is probably somewhere on micro
Went to ECE shop and had the board get X-rayed, it showed there were pretty poor soldering connections on numerous pins, notably the 3.3V pin
Worked with a friend with more soldering experience to put a micro on new board
Tried to bake board but did not make good connections
Tried again for longer duration and still did not work so ended up hand soldering
With new micro next step will be to verify this board is soldered on well and test again and see if we can boot and check for I2C connection

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

Date: 4/14/25
Start Time: 11:00am
Duration: 2.50 hours

Went to lab with Alex with the goal of getting the heart rate sensor communicating with the micro via I2C and also connect the micro on the PCB to pair with our phone app via BLE
Attempted to connect app w PCB

Failed to detect Bluetooth signal
Couldn't see it from app or the NRF scanner

Attempted to connect heart rate sensor w micro on PCB via I2C

Failed to read FIFO buffers
Part of reason is possibly that we are yet to put our external pull up resistors from schematic on the board

These are connected to the I2C lines

Soldered on 10k pull up resistors on the I2C lines
Now have issues flashing code

Determined part of problem is the buttons are now connected, so pressing reset button causes enable button to go low, so when trying to flash it puts micro back in boot mode

Talked with Shivam and he recommended trying smaller resistor values for the pull up resistors
We will need to continue debugging and check out the soldering to make sure there are no issues

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

Date: 4/13/25
Start Time: 3:30pm
Duration: 2.00 hours

Today I tried rebuilding the conductivity circuit

Made some adjustments to our design

I tested using the AD2 to create a sine wave like the wave we are going to produce with the DAC
Moved potentiometer to be immediately after the wave

Will be used to control the amplitude of wave

Set up our high pass followed by the low pass filter

Then the wave will enter op amp circuit

Got some readings – voltage would change based off what was in contact with the sensor indicating we were getting real readings
Next step will be to try to adjust the circuit to get more consistency

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

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

Date: 4/10/25
Start Time: 8:00pm
Duration: 1.00 hours

Worked with Alex on trying to flash code to ESP32 with our USB-UART adapter that we will need to use on final PCB rather than the usb port on devboard
Having several issues when trying to flash the code
Found issue in wiring set up we were using

Paired Tx and T0 and Rx and R0 – not Tx and R0 and T0 and Rx
This is also an issue in PCB design we realized – will need to fly wire it to be able to flash our code to the micro

Checked other potential issues

Button press – hold the enable first and then press reset – consistent with what we are finding on internet

He has selected correct port and COM – so unsure what else the issue could stem from
Reviewed Areej's packaging design

Going to house PCB on underside of the top of the housing

Top will open and hinge on one of the short sides to facilitate access inside the housing
Heart rate sensor will sit on floor of the housing and we will need long enough wires to reach the sensor when the door the housing is swung open and board is further away from the sensor

Need to keep trouble shooting the issue with flashing the code
Areej will print a new housing soon, need to get next version ASAP so we can see if it works/what else needs to get adjusted

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

Date: 4/9/25
Start Time: 11:30am
Duration: 2.50 hours

Received check off for displaying data received from micro (PSDR 5)
In Xcode I worked on developing a display for battery life left on the HydraWise device

Battery levels are sent via Bluetooth to phone
Display will live on home page

Adjusted home page organization

Previously, when the device was searching for pairing, the screen would only show that

Basically, user would not be able to access anything if the device was not paired

Adjusted this screen so that towards the bottom of the screen it will indicate the status of the connection

Also when device is connected – this display will then also show battery life

Created function to extract battery life data when this type is sent via Bluetooth

Similar to the conductivity and heart rate functions

Also had to create variable for this and adjust some functions for data processing

In function looking for characteristics had to add statement to set notifications if the battery UUID is detected so newly received data is pushed automatically (this makes sure the data displayed is updated whenever a new value is received)
Adjusted function that's reads the data to call correct function whenever battery life data is sent so it gets extracted properly

The battery display and data transmission work toward our first stretch PSDR
The next steps as far as this is concerned will be to edit displays and screens for a better visual appearance

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

Date: 4/8/25
Start Time: 12:45pm
Duration: 2.00 hours

Worked on setting up conductivity circuit to interface with microcontroller

Need to test with actual microcontroller DAC wave – not AD2
Also need to read values sent to the ADC that is voltage reading

Worked with Alex to properly configure the wave that the DAC would produce
Adjusted the frequency to be within the proper range

Hoping for frequency of around 150 Hz, in testing we were able to build one that is consistently producing around 138 Hz – which is good enough as it is well within the range the sensor can operate with

Set up the circuitry we are using to filter the wave and center it around zero before having it enter the sensor

We are using a low pass and high pass filter to filter noise and center wave around zero as well as a potentiometer to adjust the amplitude

Had issues with producing the correct wave after the filters – sometimes the wave would be cutoff and sometimes shape would be altered
This is confusing because we had used exact same set up with the AD2 prior to test our design
Need to do some further testing/troubleshooting to figure out how to correct this problem

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

Date: 4/7/25
Start Time: 12:45pm
Duration: 3.00 hours

Worked with Alex to successfully run through device functionality

Once paired, ESP sends heart rate BPM value every 10 seconds, and value is displayed on its page and updated whenever new values are sent
When button on hydration page is pushed, DAC successfully generates signal for 10 seconds to generate reading – which is processed by the ADC and sent to the app and successfully displayed there
This ensures most all of the software is integrated properly

Created files on Xcode to store data received in JSON format

Conductivity entry and Heart rate entry files
Made a struct for each file for the data entries – each contains two fields
Heart Rate:

BPM – int
Timestamp

Conductivity:

Value – Double
Timestamp

For both files I also created manager classes to manage the files and add new entries as data is sent from the micro and received by the app

In both made functions that will save a new entry to the files

Call the functions in the Bluetooth manager inside the function which reads the data sent from the microcontroller

This saves the new data into the files when it is received

Print the url to the files into the terminal as well to access them after for testing

After setting up the files and doing some debugging, we tested this with the microcontroller by continuously sending data

Were able to access the json files after we finished testing and we were able to see the data being stored successfully

This pretty much completes our PSDR 4
Next steps are to map the hydration sensor readings to electrolyte concentration levels in the sweat, and give a hydration recommendation
Also we need to create a display for the historical data saved on the files

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

Date: 4/6/25
Start Time: 1:30pm
Duration: 2.00 hours

Continued debugging in Xcode
Fixed issue with the heart rate view page

Was missing a "."

Changed line from foregroundColor(.red)
Now is .foregroundColor(red)

When pairing app and micro – having issues recognizing all the UUIDs
Was able to detect the 16-bit UUIDs

Heart rate
Battery percentage
Button press

Switched hydration characteristic from 128-bit UUID to 16-bit UUID to see if this would solve the issue of failing to detect it

0x272B – electric conductivity

With this new UUID, we were able to successfully recognize all characteristics now
We then tried sending dummy data when paired with the ESP32

With the new UUID, the app was able to successfully receive and display data received from ESP for the hydration readings on the hydration page on the app

Next steps on app side will be to interpret that voltage on app before displaying now

Also to store the data

On the hardware we need to set up the conductivity circuit and ensure we are creating the correct wave out of the DAC

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

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

Date: 4/4/25
Start Time: 2:00pm
Duration: 4.00 hours

Transferred app onto phone to attempt Bluetooth pairing process
Adjusted some of the logic of homeview file so user can be aware when the device is searching for Bluetooth connection

Previously when app starts up, there's no way of knowing device's state – it would just load the home page
Created an isScanning variable in Bluetooth class

When device is scanning on startup, it displays a page stating its searching for Bluetooth devices

Adjusted the service and characteristic UUIDs
Had trouble finding the ESP from device, even though it can be seen from third party scanning apps
Adjusted logic when scanning for peripherals to test if Bluetooth was working properly

Instead of scanning for specific services, scanning for all devices
Was able to find devices, and would connect, so know the scanning is working, just need to figure out how to identify device we want

Different method from using UUIDs would be by using device name

If the device name matches what we've set the ESP to, begin connection process, otherwise continues scanning through devices

This method worked, was able to successfully connect to the ESP through the app
Am able to successfully navigate to hydration page and press button to start hydration reading

Will need to set up a UUID for sending the notification – haven't done this yet so pressing the button doesn't actually send anything to the ESP yet

Trying to go to heartrate page causes app to crash and not sure why

Debugger says its trying to access memory it shouldn't
Same error occurs when using mockbluetooth manager on preview mode within xcode
Likely due to use of Bluetooth manager class

Accessing memory it shouldn't – could be from trying to display heart rate data that is meant to be sent, but since the ESP isn't sending any data yet this causes the problem?
Added a guard to the extract heart rate function which takes the data from packet received from Bluetooth, and if its not large enough size to return 0 because the data is too short, instead of attempting to return a value which doesn't exist

Use similar logic and syntax in the hydration file as well as heartrate

Replaced using the real data to be displayed on the heart rate page with dummy data hardcoded in, but still suffer the same error

Next steps will be to continue debugging, figure out what is wrong with heart rate page
Need to create pop up message warning when the battery level is low
In meantime can still also adjust button to send signal to ESP to start conductivity reading

Will need to create new UUID as well for this data type

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

Date: 4/2/25
Start Time: 11:00am
Duration: 3.00 hours

Work on data processing of heart rate data

Convert the fifo buffer to a bpm value

Steps:

Set sample rate (currently set to 100Hz)
Set threshold (Set to 20000)
If a data point in buffer is above the threshold, check to see if it is a larger value than previous and next data points, if it is, then it is a heart beat
Use indices to calculate time between heartbeats

E.g. if sample rate is 100Hz: (Index2 – Index1) * .01 = time between beats

Then convert to BPM

BPM = 60 / time between beats

A way to get a more accurate reading is probably by getting the average over a longer period

Alternative method

Take sample of set period of time (say ten seconds)

If a data point is above the threshold and larger than its neighbors, then it is heartbeat
Count number of heartbeats over that window of time

(Number of peaks / time window) * 60 will give bpm

Need to test function itself to ensure it is working properly
Then will need to integrate it with the rest of code for capturing heart rate data

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

Date: 3/30/25
Start Time: 7:00pm
Duration: 1.50 hours

Worked on setting up data packets for transfer from ESP to phone
Cleaned up some of the code and errors

Had multiple UUIDs for some functionalities

Set up dummy data to practice sending to NRF scanner to see try to test sending actual data (also receiving data – will need to receive data for triggering the interrupt to begin conductivity reading)
Had issues with testing – values were not matching when they were transmitted
Could receive data successfully from NRF scanner
Next steps will be to test pairing with app

Try to send data between app and ESP rather than scanner – also ensure accuracy of data

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

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

Date: 3/28/25
Start Time: 3:00pm
Duration: 3.50 hours

Worked on finalizing Bluetooth from app perspective so we can try to pair device and esp with the app rather than NRF scanner

Had to refamiliarize with the app and Bluetooth class

Adjust UUID to scan for when searching for device

Both service UUIDs and characteristic UUIDs

Adjusted the start up page to be the home page – this way when app launches it instance of the Bluetooth manager class will be created, and Bluetooth pairing process can begin
Adjusted Info.plist file

Configuration file not a part of my Swift source files

Need to adjust this so that the app will ask for permission use Bluetooth, allowinsg device to connect to the ESP

Difficulty finding the Info.plist file

Found in info tab under general HydraWise folder

Set 'Privacy – Bluetooth Always Usage Description'

Allows Bluetooth scanning or advertising in both foreground and background

Had to adjust some files to remove instances of dummy variables

Heart rate page had dummy data – adjusted it to bluetoothmanager

Difficulties trying to preview on phone rather than with simulator

Kept saying waiting to reconnect to phone, then wound up crashing

Next step will be to successfully display app on phone, and try to connect with the ESP

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

Date: 3/27/25
Start Time: 3:00pm
Duration: 1.50 hours

Worked on setting up characteristics for esp to advertise

UUID for heart rate and battery level are 16 bit since they are pre-defined by Bluetooth SIG

https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Assigned_Numbers/out/en/Assigned_Numbers.pdf

When connecting phone to ESP32 with espressif ide – connection almost immediately times out and not sure why
After setting UUIDs for the device we were able to maintain connection with the device

Heart rate UUID – 16 bit
Battery management UUID – 16 bit
Conductivity – 128 bit (use UUID gen online to create it)

We were able to send data from the NRF scanner app to the ESP device and the device was able to recognize it - Basically we need for data app to micro wise since we will just be sending signal to trigger the interrupt
Next main focus will be to get the app Bluetooth functional so we can try to pair the app with the ESP rather than through the NRF scanner

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

Date: 3/26/25
Start Time: 12:30pm
Duration: 2.00 hours

Tried to figure out how to address dependencies for modules being used for Bluetooth communication

Need to add files to the requires section of CMakesLists file
Some like freertos are included on ESP32 hardware – but show as missing until code is flashed

Worked on generating the dac wave for conductivity sensor with espressif

Going to use a cosine wave rather than a sine wave as initially planned

For whatever reason built in functions espressif has works way better for cosine

Trying to get it set to the correct voltage

Need to set it to keep Vpp low, to put less importance on potentiometer and also save power
Filters will adjust the offset DAC will produce to center around zero – don't need to worry about that for now.

Need to build circuitry for the DAC and connect it to ESP to make sure we get wave of the right values that we want
Should be good with dependencies for BLE, were able to flash the code successfully and see device on NRF scanner

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

Date: 3/26/25
Start Time: 8:30am
Duration: 3.00 hours

Worked on setting up BLE using Espressif IDE
Watched a few videos to get familiar with process

https://www.youtube.com/watch?v=EIo5aZ3c89Q&list=PLtFHvora00y-41Das1NKDMMSL2dI-UMVs&index=12

Initialize

NVS flash – nonvolatile storage
Generic access profile

Determines how device is broadcasted, connects, and interacts with others
Creates handles for characteristics so other devices can see them

Generic attribute profile (GATT)

Registers gatt service
Will need to configure and queue all the services

ble_gatt_svc_def - for defining services

Will need four

Heart rate data
Conductivity data
Battery data
Receive notification to start conductivity reading

Initialize application
Will need to create thread at end to run the BLE

Event handler
Next will need to implement these changes to our BLE.c file and test if we can detect the ESP on the NRF scanner

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

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

Date: March 14th
Start Time: 12:00pm
Duration: 2.00 hours

Reviewed updates Alex made to PCB
Edited PCB further to address more of the feedback from staff

Verified USB-c charging receptacle placement
Worked on adjusting circuit for voltage regulator – found the recommended layout and component values on Webench

Added an image to the journal entry for better visualization

Issues with ground plains and plain on the inductor

Had difficulties with adjusting the vias under the microcontroller to one large one

Kept getting errors and unsure why

Need to submit the PCB to staff to get more feedback or approval to order

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

Date: March 13th
Start Time: 8:00pm
Duration: 2.00 hours

Worked on revisions to PCB with Alex
Reviewed feedback from course staff and identified needed changes

Change small vias under micro to a large one in order to avoid having to use hotplate
Add ground around screw holes
Flip USB-C charging receptacle
Add 0805 Ferrite Bead
Add vias for conductivity sensor if we need to adjust sensor's circuit later on
Fix the circuitry for voltage regulator following the datasheet recommendations

Begin revising circuitry for the regulator in KiCad

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

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

Date: March 7th
Start Time: 2:00pm
Duration: 2.00 hours

Researched ESP32 Bluetooth set up for ESP-IDF
Used online documentation as well as a good YouTube tutorial to set up Bluetooth

https://www.youtube.com/watch?v=EIo5aZ3c89Q

Gained understanding of how to initialize BLE on the ESP
Wrote some preliminary code using ESP-IDF framework to configure device
Was able to establish foundational BLE setup for the device
Learned how to structure BLE applications on ESP32
Setting up the BLE connection between ESP32 and phone is essential for data transmission for the device
Next steps will be to implement advertising functions and connectivity tests, not just prototyping connections

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

Date: March 3rd
Start Time: 2:00pm
Duration: 2.00 hours

Found layout information for critical power-management components for the PCB – mainly the voltage regulator and charging circuitry
Found information on SnapMagic

TPS63001 Buck-Boost Converter
BQ21040 Battery-Charger

Used the datasheets to verify pinouts, footprints, and recommended component values
Downloaded the footprints and imported them to KiCad
I learned the steps in verifying and selecting PCB footprints and ensuring that each component aligns correctly within our PCB layout software (KiCad), this step was crucial to prevent placement errors later in the design stage
Next steps are to integrate the footprints into the PCB design

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

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

Date: February 28th
Start Time: 10:30am
Duration: 3.00 hours

Worked on building the other circuits to test if they had improved accuracy over the simple one built previously
Had a lot of difficulty interfacing Arduino with board without Matt's laptop – code was not functioning properly

Shifted to just using AD2 and waveform generator to produce the wave and not use filters to adjust the wave

Started with building the instrumentation amplifier, then the sensor current circuit
Had difficulty figuring out how to debug circuit, were not sure where inside of circuit to figure out if the parts are working correctly
Were unable to produce results similar to the simpler circuit we previously used
Hopefully will be able to look at circuit with Matt later given his hardware skills and can figure out what is wrong with the circuit and can see if we can produce any results that look more promising than what we got from the other circuit

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

Date: February 26th
Start Time: 6:30pm
Duration: 2.00 hours

Started by working on a simplified circuit to get the output voltage from pin
Simplifying the instrumentation amplifier and the current measurement circuit for now

Replaced both with an op amp as shown in the general circuit idea

Used LM324N chips for all op amps

Matt was able to produce a sine wave using the DAC from Arduino to get a reading from the circuit

Wave will be: .5 Vpp @ 150Hz

Constrained to < .7 Vpp and 100-300 Hz

Used low and high pass filters to get wave centered around 0 as needed by sensor and to make wave smoother

Sensor was able to get a reading that looked similar to the study

Voltage reading changed based on what the sensor was in contact with

Water, air, skin etc. changed voltage – indicates sensor provides data that will be useful from this configuration

Data was pretty noisy – looking like it could be easily accounted for with just taking an average

Next we want to build the more complicated parts and compare how they perform

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

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

I read and analyzed the LS1K0 Study sent by Jonothan which is a detailed report on a conductivity sensor developed for water purification applications

https://www.diva-portal.org/smash/get/diva2:1436882/FULLTEXT01.pdf

The study demonstrated a practical approach to correlating sensor output with water conductivity using sodium chloride solutions.
It provided experimental data showing the sensor's performance, including error margins (around 15% in some cases) and the challenges in maintaining a constant voltage across the inner electrodes.
Was able to understand important aspects of sensor

Understanding the sensor's reliance on precise calibration—particularly how the cell constant and input voltage affect accuracy.
Insight into circuit components (such as the sensor driver, transimpedance amplifier, and peak detector) and their roles in signal processing.
The importance of addressing issues like signal decay and voltage stabilization to ensure reliable sensor performance.

Will next need to work on building circuitry for device

Integrate the lessons learned from the study into our sensor design, focusing on achieving stable voltage levels and accurate calibration.
Adjust our circuit prototypes to mitigate issues such as signal decay, as highlighted in the report.
Conduct targeted experiments to validate modifications based on these insights.

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

Date: February 23rd
Start Time: 4:00pm
Duration: 3.00 hours

I continued developing the code for the conductivity sensor by refining the ADC setup and data extraction functions.
ADC Initialization:

Adjusted the initialization function for ADC1 to configure channels 0–3.
Assigned each channel to a specific signal: V+, V–, Temp1, and Temp2.

Data Extraction Functions:

Created two distinct functions:

Voltage Reading

Retrieved the raw ADC value using a dedicated "get raw" function.
Normalized the value by dividing by 4095 (due to the 12-bit resolution).
Scaled the result by multiplying by 2.2V (matching the ADC's 0–2.2V input range).

Temperature Reading:

Utilized the voltage reading output.
Applied a resistance-based equation to calculate temperature, leveraging the fact that resistance changes with temperature.

Added Constants for Calculations:

Defined constants A, B, C, and R0 for the resistance equation.
Set the RTD current parameter for accurate temperature computation.

Initial code for sensor now set up

The ADC now correctly initializes channels 0–3.
Both voltage and temperature extraction

These updates are a critical step in ensuring the sensor system provides reliable and accurate data. By fine-tuning the ADC and its associated data processing, I've laid the groundwork for future sensor calibration and integration tests
What are the next steps?

Test the ADC functions with live sensor data on to verify accuracy.
Adjust the temperature conversion algorithm based on experimental results.
Integrate these modules with the rest of the sensor system and validate overall performance.

Need to set up dac – the sensor need AC current, will be provided with a dac wave
Two ESP pins have dac

GPIO25 – DAC1
GPIO26 – DAC2
Both have very similar performance, both 8-bit resolution

Will use GPIO25 instead of GPIO32 to provide input current to sensor now, since it needs AC current

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

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

Date: February 21st
Start Time: 12:30pm
Duration: 1.50 hours

Realized all the output pints for the device will need an ADC channel – not just the one, the device doesn't do onboard data processing

Will need 4 ADC channels, two for measured voltages and two for the temperature sensors

Could instead just use channels 0-3 on ADC1

Labeled sensor pins

GPIO functionality on those is locked at very least

Need to verify that those pins can be configured for ADC use

Need to determine where to do calculations for finding resistance

Can be done on micro or on app
Phone has more space and will be easier probably, but having to transmit multiple data types over Bluetooth will make that process much more complicated

Next step will be to verify that ADC1 channels 0-3 can be used

Will need to configure those pins

Shouldn't be very difficult as it should be the same process as I already did for the first ADC channel

Also will need to determine best place to do calculations

Given one simple equation to find resistance – leaning towards doing that on micro, sending over one value and having the phone make hydration decision based off that value and other data

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

Date: February 19th
Start Time: 11:30am
Duration: 5.00 hours

Conductivity sensor research

6 pins

2 Current input pins
2 temp reading pins
2 voltage reading pins

Formula on data sheet to read the resistance
When Bluetooth transmits from phone, will send a interrupt
Can use GPIO pin (could also use PWM to get desired voltage but less stable signal) to send current to the sensor

Need voltage divider to drop voltage within range of the sensor – 3.3V too much

Also can use an IO pin as ADC – sensor produces analog data so will need to convert it
32K_XP&32K_XN are right next to each other

Can use GPIO on one and ADC on other – pins use GPIO32 & ADC1_CH5

Sensor set up and initialization

Wrote function to initialize 32K_XP has GPIO output

Disable pull up/down resistors
Disabled interrupts

Our interrupt comes internally
This setting is for receiving interrupts if GPIO pin was an input

Initialized 32K_XN for ADC

ADC1 Channel 5
Set channel width and attenuation

Not entirely sure what to set these to, but given the sensor handles up to 1.7V, don't need attenuation of 0-3.3V, so for now set it to DB_6 so it is good for 0-2.2V

Wrote function to read ADC data

Unsure exactly what data will look like as of now
For now, use ADC driver built in function to read data from the ADC1 channel we are using
Just return raw data

Have to set up hardware to test the sensor

Sensor itself is pretty simple – only the 6 pins, but some additional hardware is required for setting up sensor if we are using GPIO
Need voltage divider to lower 3.3V output by GPIO pin to something under 1.7V as required by the sensor

Next step is to build hardware necessary to start testing

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

Date: February 17th
Start Time: 11:30am
Duration: 1.50 hours

Researched materials for hardware encasing

Two main materials we're considering are flexible resin and thermoplastic polyurethane (TPU) – both are 3D printable, which is how we plan on making the encasing
Flexible resin

Rubber-like material

Designed to be bendable and impact resistant

Smooth, making it comfortable for wearable devices (like ours)
https://sybridge.com/know-your-materials-flexible-resin/#:~:text=The%20term%20%E2%80%9Cresin%E2%80%9D%20can%20refer,are%20relatively%20soft%20and%20malleable.

Highly flexible and elastic
Impact resistant
Water and chemical resistant
https://www.gantrade.com/blog/what-is-thermoplastic-polyurethane

In comparison

In general, TPU seems to be better suited for wearable device applications
TPU is more durable than the flexible resin
TPU withstands UV exposure better

Exposure to UV light makes flexible resin brittle over time – not ideal for a device that is expected to be worn outdoors frequently

TPU generally seems to be better option

However, prototype Areej 3D printed using TPU seemed to be pretty rigid

Could be due to prototype thickness, design, etc.
She is going to print one of each and we can compare them to make a decision

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

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

Date: February 11th
Start Time: 1:00pm
Duration: 2.00 hours

Developed a few more Bluetooth functions in Xcode

Autoreconnect function

If person wearing device walks away from phone for example, the device will automatically reconnect when in range

Function sending command to device to start hydration reading

Hydration reading will be on command from user, they will press a button on the app to start hydration reading
This function sends a command over BLE to the ESP32, and expects a response (Hydration reading)

Started implementing Bluetooth module in the front end

More complicated than initially expected
Updated the app homepage code to create an instance of the Bluetooth module class
Pass it into the heart rate view and hydration view so they can display data from the instance of the class

Next steps will be to figure out testing for the Bluetooth

More complicated than previous testing done on front end displays

While Xcode can simulate iPhone, does not have hardware to simulate Bluetooth pairing, so will need to plug in phone and run off phone

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

Date: February 10th
Start Time: 10:30am
Duration: 3.00 hours

Continued to work on the Bluetooth module in XCode

Built functions that discover services device transmits and identifies them

For our application this will be the heart rate monitor data and hydration data, each will have a separate UUID, and this is how the phone app will know what type of data it is receiving

Built a function to automatically push the received data to the app

This means that when a new value gets sent from the ESP32, the app will update the value for whichever data type it is
Next will have to implement this in the front end so that the value displayed is constantly update when new values arrive and are processed
Goal is to display most up to date information to the user

Built functions for reading sensor data and extracting it

Acts as the step before pushing data to user
Reads UUID of the BLE GATT package to determine data type (heart rate or hydration)

Calls appropriate function to extract data from packet
Heart rate will extract an int called bpm
Hydration will extract a float called level

Have a good amount of the data transfer and processing down now

Need to get data displayed and connect front end with bluetooth transmission

=============== Week 4: =================

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

Date: February 6th
Start Time: 1:00pm
Duration: 2.00 hours

Started researching and developing implementation of BLE system using ChatGPT and Apple Core Bluetooth documentation

https://developer.apple.com/documentation/corebluetooth
Created a Swift file called BluetoothManager.swift for handling BLE communication of device and phone

Define BluetoothManager class

NSObject – Needed to interact with Apple's Bluetooth API's
ObservableObject – Allows SwiftUI to observe changes in Bluetooth data
CBCentralManagerDelegate – Allows managing Bluetooth connections
CBPeripheralDelegate – Allows receiving data from the device

When app runs it will create an instance of the class

If Bluetooth is enabled on phone it will start scanning for devices with the device's UUID
If not enabled it will state Bluetooth unavailable

When device is found the device will be stored and be connected, scanning will stop to save power
Next will be to create functions to discover services device offers
When characteristics (hydration and heartrate) are found, enable notifications to receive data updates
Then there will be functions to extract the data and convert it to a float to be presented to the user

Next step is to implement the methods and class developed to into the existing files so that they can be utilized by the app properly

May have to add a few new methods as well

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

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

Tried to get the better idea of the mechanical design of the wearable device

Made a sketch of potential configuration
General idea was originally to have the hardware on the underside of the wrist rather than on top

https://www.health.harvard.edu/heart-health/want-to-check-your-heart-rate-heres-how
After looking around on internet think wearing it traditionally on the top of the wrist is more effective

While feeling pulse is easier on bottom, the heart rate monitor uses green light to see how it reflects off bloodstream, and the radial artery which is the most easily detectable be sensors is on top of wrist going towards the thumb

Have the heartrate sensor under the microcontroller to have direct contact with skin
Have conductivity sensor on the top to be able swipe across the forehead or other body part to collect sweat when doing a hydration reading
Have the battery to a side of the microcontroller and a charging port out the side of the band

Still need to determine the material of the whole device and how the electronics will be contained securely

Probably will need to make a visit to the lab in WALC to figure that out

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

Date: February 4th

Start Time: 12:00pm

Duration: 2.50 hours

Continued setting up our pages for the app in Xcode

Built new interfaces and also set up navigation between them
Was able to put some dummy data into displays to get an idea of what pages could look like when operational
Built file setting up a preliminary struct for the data our app will display

Currently only has heartrate and hydration (which will likely be water concentration %)
Was able to put some dummy data into displays to get an idea of what pages could look like when operational

Need to make button on hydration page functional

Its purpose will be to sent Bluetooth signal to microcontroller to start a hydration reading

Next steps are figuring out mainly back end and data transfer / processing stuff, although some stuff will likely be changed on stretch PSDRs

There will probably be minor tweaks to the displays regardless

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

Date: February 3rd

Start Time: 11:00am

Duration: 2.50 hours

With the framework of the Apple dev tutorial I've been working on I started making the frontend software of our HydraWise app by converting some of the files to fit our needs in an Xcode folder

As I progressed, I encountered challenges due to the high level of dependencies among the structs and files. Many components within the tutorial were interconnected, making it more complex than I initially anticipated to isolate and modify individual elements without causing compilation issues.
Was able to make a few pages for the application

Built homepage and heartrate page

The homepage serves as the main navigation hub for users
The heartrate page will later integrate with the device's sensor data to provide real-time heart rate tracking

Been able to verify files are built correctly with preview mode

Through this phase of development, I have gained a deeper understanding of SwiftUI's structure and how Apple's development framework handles data flow between views. I also learned the importance of properly managing dependencies and organizing files to prevent unnecessary complexity.
The immediate next steps will be to continue building interfaces and adding functionality to the app

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

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

Date: January 28th

Start Time: 10:30am

Duration: 1.50 hours

Continued with Xcode tutorial

Was able to make more interfaces and the ability for user to interact with screen and move between some of them

Added fuctionality to the buttons on this display, allowing the user to navigate to other pages and back to this one

Learned how to display data on screen
Learned how to use simulator

Can run iOS device and simulate using the device like a user would

Basically have down the basic elements of the front end software we will need
Need to do a lot of research into the backend algorithms and data processing now. Also need to figure out how to display data live – only know how to display static data as of right now

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

Date: January 28th

Start Time: 12:15pm

Duration: 2.50 hours

Begun Xcode intro
https://developer.apple.com/tutorials/app-dev-training/

Apple Dev tutorial – worked on building an application following the tutorial
Learned some syntax and structuring (mainly front end)

HStack for placing items horizontally
VStack for placing items vertically
How to place buttons, text, etc.
Learned how to create structs to store data in specific formats

Will be useful for storing heart rate and electrolyte data, will likely have several fields for our data

Will be able to use interfaces / functionalities built in tutorial as a template for our app, also now more familiar with Xcode and swift
Next will need to continue to learn features of the environment and learn how to implement other functionalities we will need for the project

Researched battery

Want a battery with Battery Management system (BMS) so that we can have accurate reading of battery life and display it to user

If we cannot get a battery with a BMS, will have to create own system

A recommended method for Lithium Ion batteries is an amp hour (Ah) meter counting amps in and out of battery

https://www.synopsys.com/glossary/what-is-a-battery-management-system.html#:~:text=Battery%20management%20system%20(BMS)%20is,time%20against%20expected%20load%20scenarios

We need to know battery life so user can be aware if they need to charge
After manlab, we were recommended to use battery with IC stored internally
Next we need to look into batteries with an IC, and then will need to learn how to transmit data to the phone, probably will be done in a method similar to sensor data

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

Date: January 27th

Start Time: 2:00pm

Duration: 2.00 hours

Looked into process of Bluetooth transmission of data, how to send it to app
ESP 32 sends data packets in GATT format

https://www.espressif.com/sites/default/files/documentation/esp32_bluetooth_architecture_en.pdf
https://community.silabs.com/s/article/ble-master-slave-gatt-client-server-and-data-rx-tx-basics?language=en_US
Packet structure:

Opcode (Type of operation)
Handle (Characteristic or descriptor)
Payload (Data value being sent)
Error Codes

Client (phone) will request data
ESP will then send day to the phone

Still need to know the type of data being sent across to be able to do data analysis
Will probably use libraries available (maybe CoreBluetooth) for coding the Bluetooth transmission process

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

Date: January 25th

Start Time: 2:00pm

Duration: 5.00 hours

Researched heart rate algorithms using chatgpt – found method to get heart rate data
Data sent from most heart rate devices will be in a sine wave

Peaks represent heartbeats

Can use derivative method to detect them, when slope changes from positive to negative (slope = 0)
Measure time in between the peaks to find bpm
Also can use sliding window to take average of beats over span of 5-10 seconds to get more accurate readings

This will allow us to transfer the data measured from the sensor into something that is useful for the user
Next we will have to figure out all the details of transferring the data from sensor to device, and the process of storing it, data structures it will use, etc.

Worked on developing a diagram of a device we could build to measure water concentration in sweat – given the difficulty we have had finding an electrolyte sensor that could be used in a wearable device

This device would be small enough to fit in the watch and would be able to interface with the ESP32 through an ADC
Salt water is more conductive than fresh water

https://www.britannica.com/video/current-solution-electrolytes/-174966#:~:text=Salt%20water%20is%20much%20more%20conductive%20than%20pure%20water
So general premise is that we could read the voltage and it would tell us how much salt is in the water

If this device is practical, would give us a sensor to measure hydration

Next steps are to prototype the device

Also, had trouble finding data to use as benchmark, so we would likely have to go to a lab and test voltage readings with distilled water and water with varying levels of salt to be able to understand what readings are

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

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

Date: January 23rd

Start Time: 12:30pm

Duration: 2.00 hours

Met with team to begin work on A2, review PSDRs to edit them
Discussed prior research done with team regarding app
Talked about design of device

Considering a wristband like device with heart rate sensor against skin and sensor for electrolytes on outside of band so user can rub against them somewhere to get a reading (like against their forehead for example)

Having difficulty finding an electrolyte sensor

Difficult to find a sensor that actually measures electrolyte level

Lots of devices we are finding measure specific chemicals (salt, potassium, etc.)
Devices are also very expensive and size may prove to be difficult to deal with

Planning on using an ESP32 variant

May measure it in a different way

Commercial product Hdrop measures water concentration in sweat and figures out electrolyte level based off that. Bsaically finding it an inverse way

Started looking into heartbeat sensors to use

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

Date: January 22nd

Start Time: 12:30pm

Duration: 2.00 hours

Met with course staff and received feedback on PSDRs

Modified PSDRs to include power of device, discusses potential methods to power device (wireless, wired, replaceable battery, etc.). Leaning towards wired charging Li battery

Researched potential microcontrollers to use

Want one with Bluetooth to connect to phone using app to see the data
Planning on using an ESP32 variant

Started looking into process to record electrolyte levels

https://www.horiba.com/usa/water-quality/applications/human-health-care/measuring-sodium-and-potassium-concentrations-in-athletes-sweat/

Started looking into heartbeat sensors to use

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

Date: January 22nd

Start Time: 9:00am

Duration: 1.50 hours

Continued research into iOS app development - looking specifically at health apps

https://developer.apple.com/documentation/healthkit

Looked into Xcode and other iOS development platforms

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

Date: January 21st

Start Time: 8:00pm

Duration: 1.50 hours

Begun researching app development for our product, leaning towards iOS app

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

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

Date: January 17th

Start Time: 1:00pm

Duration: 2.0 hours

Met to discuss roles and responsibilities
Completed assignment 1 and begun research into design of project

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

Date: January 15th

Start Time: 12:30pm

Duration: 2.00 hours

Tour of lab
Started setting up website