Description: Debugged PCBs to get Microcontroller working again after they stopped working. Debugged conductivity circuit to get it to work. Finalized and made adjustments to ADC code. Tried to debug coulomb counter I2C. Final Demo worked for all PSDRs.
Date: April 25, 2025 Start Time: 00:00 am Duration: 18 hours
I dedicated the entire day to troubleshooting our PCB and working on the full integration of the project system. After a successful flashing session the previous night, I encountered major issues: the microcontroller (ESP32) would no longer accept new firmware uploads. To systematically investigate the problem, I began by extensively testing all voltage levels across the PCB. Using a multimeter, I carefully measured each power rail, checking at various critical points across the board. I repeated these measurements several times throughout the day to ensure no intermittent issues were overlooked. In addition, I checked for any unexpected voltage drops or shorts between lines that could hint at deeper electrical faults.
Following a suggestion from Shivam, I also conducted a ground loop investigation. I tested continuity between different ground pins and connectors to see if improper grounding could be introducing noise or unstable behavior during flashing. Although no strong ground loops were immediately apparent, re-securing the ground connections — particularly at the battery and USB interface — seemed to reduce instability. This pointed to the possibility that an intermittent ground issue may have been causing the UART connection failures when trying to program the device. I used continuity mode on the multimeter to ensure that all grounds tied back consistently to a single reference point without floating, broken, or poor connections.
In parallel with debugging, I worked on assembling all the parts of our final system. This included securing the battery into the project housing, mounting the PCB, and wiring the conductivity measurement circuit, which had to be carefully flywired to the board. This process involved detailed mechanical and electrical work, ensuring that all connections were reliable without stressing components or introducing new faults. I conducted incremental tests after each assembly step to make sure no new issues were introduced. For example, after conductivity sensor analog circuit was attached/soldered to pcb, I retested the PCB’s power system and communication lines before moving forward with the full integration.
After many hours of careful electrical testing, reworking ground connections, and reassembling the board, I successfully restored the ability to flash the ESP32 with Neff. This was a major turning point: the PCB started reliably accepting new firmware again at 115200 baud over UART. With the system back online, I thoroughly tested each module in our design. I verified the BLE heart rate characteristic updates, confirmed conductivity measurements were being acquired correctly, and ensured the battery monitoring circuit was functional. Power stability was checked again under full load with all peripherals connected. All tests passed successfully.
Finally, with everything assembled and functional, our group performed the final demo of the system. The demo showed live data streaming from the wearable PCB to the mobile app, including heart rate, conductivity readings, and battery status, with stable operation over BLE. This successful demonstration marked a major milestone, validating all the hardware debugging and integration work I conducted throughout the day. Overall, today’s intense debugging, assembly, and testing effort was critical to getting the project across the finish line in time for the final evaluation. Next steps is do the final presentation and do some tweaks on our device (e.g: change heart rate sensor headers) for the Spark Challenege.
Date: April 24, 2025 Start Time: 9:00 am Duration: 15 hours
Focused on debugging the flywired conductivity measurement circuit on our PCB, which is a critical part of our sensing system. This circuit, built using several discrete op-amps, was designed based on concepts similar to those found in established conductivity sensor architectures, such as those outlined in the referenced paper. The system operates by generating an AC excitation signal (sine wave) and measuring the resulting voltage drop across the conductivity sensor to estimate solution conductivity. Despite having previously validated this design successfully on a breadboard prototype, the flywired version on the PCB was not behaving as expected.
To begin the debugging process, I carefully mapped out the full analog signal flow using the schematic and compared it step-by-step against the physical wiring on the board. I verified that the sine wave generator was producing a clean signal at the expected frequency and amplitude. This involved probing critical nodes in the circuit using an oscilloscope and verifying waveform integrity at each stage, from the sine wave source through the excitation electrodes. Several inconsistencies were found early, including harmonic distortion,
indicating that one of the op-amps was not operating in its linear region. Next, I systematically tested the biasing voltages and supply rails for each op-amp stage. Some of the biasing resistors, due to long flywire connections, appeared to introduce unwanted parasitic capacitances, which likely altered the frequency response compared to the breadboarded version. To address this issues, we tried resoldering some connections to make sure it is properly secured and connected.
Throughout the process, I ran controlled experiments where individual stages were bypassed or isolated to confirm their independent behavior. For example, I shorted the input of the gain stages directly to a clean signal generator output to rule out upstream issues. By doing so, I discovered that the first amplifier was not outputting a waveform like I was expected (more noisy sine wave).
By the end of the session, I restored proper sine wave generation at the electrodes with correct amplitude, ensured that the signal chain through the analog front-end preserved fidelity, and significantly reduced unwanted noise. The debugging confirmed that analog performance was highly sensitive to layout and wiring practices, especially for AC circuits at moderate frequencies. This session highlighted the importance of careful analog design transfer when moving from a breadboard to even a temporary flywired PCB setup.
In addition, after conductivity sensor was working, while integrating I2C sensor I discovered I2C lines were not working properly and that the issue was most likely the microcontroller soldering. Therefore, with Xiang help, we desoldered microcontroller and solered a new one in this board. With the new microcontroller, I started running tests on it, and the flshing was working, but the code would not run when pressed reset (entered download mode). I conducted then several test, checking all voltage levels, specially related to the RESET/BOOT circuits and microcontrolle rpower supply. After some time, I was able to get the code to start running at odd times when I started to bridge some grounds and connections. However, after a while, when I was testing to see if my coulomb counter I2C code was working on PCB,
the microcontroller stopped flashing (could no longer write code to the microcontroller). Rest of the night was used for trying to debug this issue by switching Serial adapters, wires, soldering programming header pins, desoldering it, trying to flash several times, try to bridge some ground/connections, etc. The most logical conclusion I was able to arrive was that there could be a floating pin which is messing with my UART transmission.
Next steps are to get everything assembled with packaging and get microcontroller to flash again.
Date: April 24, 2025 Start Time: 9:00 am Duration: 5 hours
my focus was on evaluating the initial integration status of the system after assembling the PCB, battery, and flywired conductivity measurement circuit. I first verified that the microcontroller (ESP32) was flashing correctly via UART. Using idf.py flash at a baud rate of 115200, I confirmed that new firmware could be uploaded consistently and that the device booted properly after flashing. After flashing the test firmware, I monitored the system and successfully observed Bluetooth Low Energy (BLE) advertising and connection behavior, confirming that the base functionality of the board — including flash memory, BLE stack, and UART connections — was operational at this point.
Following the confirmation of microcontroller functionality, I shifted my attention to initial tests of the flywired conductivity analog circuit. I used a multimeter to verify biasing voltages at the key nodes around the op-amps and manually probed the excitation points to ensure that a sine wave was being generated. At this stage, I was able to measure a small AC signal at the excitation electrodes, but its amplitude and stability did not exactly match what had been observed during breadboarding. This hinted that although the basic structure of the conductivity circuit was intact, it would likely need deeper debugging later to match the original performance.
Additionally, I began working on restoring communication with the I2C-based heart rate sensor (MAX30101) attached to the PCB. Since the ESP32 was now able to boot and BLE was functioning, I attempted to initialize the I2C driver and scan for the sensor. However, the microcontroller was not detecting any devices on the I2C bus. I suspected that either the I2C SDA/SCL lines were not properly connected (possibly broken during previous flywiring adjustments) or that the sensor was not properly powered or pulled up. I verified that 3.3V was reaching the sensor’s VDD pin. I tried several modifications, including manually attaching wires to microcontroller pads and slowing down the I2C clock speed, but the device still failed to appear on the bus.
Toward the end of the day, I decided that it would be necessary to explore alternative wiring routes or rework the heart rate sensor connection entirely if no other solution could be found. Despite the I2C difficulties, verifying that the microcontroller, BLE communications, and basic conductivity circuit were alive represented major progress. These tests helped establish a clear technical starting point for the deeper debugging efforts that would follow in the next sessions. Next steps fix this I2C communication issue or try resoldering the microcontroller on this board, which is most likely root problem.
Date: April 18, 2025 Start Time: 9:30 am Duration: 5 hours
Neff and I soldered all the microcontroller and I2C related circuitry on the final board, with exception to the microcontroller module, which we recieved help from a TA. I conducted all the same tests from previous board - checked all voltage levels and flashed the code -
and this new PCB passed on Heart Rate Sensor, but failed Bluetooth, making it clear it is not a microcontroller issue, but most likely a software problem. Begun gathering all components needed to flywire conductivity circuit and started planning how to do so (my original idea was to stack to
boards, but Jonathan suggested to use top and bottom of the same one). Started debugging BLE more in-depth, researching if there has been any similar issues on Reddit and other Community Forums (https://esp32.com/viewtopic.php?t=30483 , https://www.reddit.com/r/esp32/comments/17as47t/problems_connecting_esp32_with_bluetooth/),but could not find anything that would apply to my situation, which is why I plan on directing my research towards
understanding the elements/components (libraries, configurations, etc.) needed for Bluetooth, so I can try to see if anything is missing. As a result, I found out a potential source of the problem, which is on the sdkconfig file, which does not explicitly disable the use of an external crystal, causing NimBLE to maybe default to expecting a 32.768 kHz external crystal (need to test it yet).
I have also started to research and get familiar with GDBStub, which I plan on using to go over memory adresses to see if anything is flashing differently between devboard and
pcb esp32 module that could be causing us this problem (GDBStub).
Next steps are to debug Bluetooth and assemble power on new board and flywire analog circuit.
Date: April 16, 2025 Start Time: 9:30 am Duration: 7 hours
Attempted flashing Bluetooth and I2C related code, but failed in both. I worked on debugging the initial BLE service integration into our ESP32-based HydraWise firmware.
The goal was to ensure that the BLE GATT server, particularly the heart rate characteristic, was advertising correctly and responding to GATT client read requests. I used the ESP-IDF NimBLE library along with the nRF Connect mobile
application for real-time BLE interaction. I started by confirming that the characteristic UUIDs matched our custom service profile, then checked for proper callbacks being triggered within gatt_svr.c. Debugging was done using idf.py monitor,
which let me trace service registration and event callback outputs. However, no signal was "captured" either in our App or nRF Connect, which indicates to me that Bluetooth was not initialized properly or something in hardware is interfering with it.
I double checked and researched about esp32 and its Antenna layout in PCB to make sure there was no errors on ourt part when design our board, which there do not seem to be. Then, I proceeded to try running Bluetooth again on devboard, which worked with no problems.
I compared both the log statements given to see if there was anything operating differently, but they were the same. I also tried running only Bluetooth and only I2C, but had the same issues. This gave me an understanding that it could most likely be a hardware issue since I2C was also failing. Therefore, Neff and I took the microcontroller
to get an X-RAY and found out the soldering was poorly done, including in 3V3 pin, which could be a reason for the failures (unstable power). We attempted to solder better the ground and power related pins to the microcontroller, but it still did not work for either Bluetooth or I2C.
In regards to Heart Rate Sensor and I2C, I was getting a debug print statement that indicated failure to read the fifo read and fifo write pointers in sensor, which indicated to me that there was a failure in the sensor initialization (sensor did not turn on), which could only happen if I2C was not working properly.
Therefore I wrote a function to scan for I2C device addresses to see if it was at least finding the sensor, but it was not, which showed me that I2C was definitely not working. As a result, I started checking the voltages across all components, including sensor power pin, sda pin, and scl, all of three had weird voltage levels (~1v, ~2.5v, ~2.6v respectively).
We soldered the two pull up resistors (10K) to see if maybe that was the issue, but it still did not bring the voltage up. We desoldered and soldered a lower resistor value (2.2K) and still did not work. In light of this, I thought it could be a pcb board issue. Therefore, me and Neff got another board and had another microcontroller and all its related circuitry,
as well as Heart Rate Sensor circuitry soldered. We flashed the code for BLE and I2C and were having same issues, indicating BLE could have a software issue. After talking to a TA, I realized aI had a bad connection on the sensor, which is why voltage levels were not ideal. After securing sensor properly, the voltages were fixed, but still was not working. Neff and I set up an osscilloscope on
SDA and SCL lines and discovered that SCL was idle at 2.7V, which would explain why it does not work. After performing some continuity tests, I could not figure out why it was failing. However, I decided to go back to the previous board I was testing and test again, but this time with the sensor secured properly. Finally, I2C and the sensor worked normally, which showed me that it was most likely a hardware issue on the other board.
Nonetheless, BLE did not work in either. All of this debugging was very important to pinpoint the issue with the sensor and get it working properly as our design intended. Next steps are continue debugging Bluettoth and build the entire microcontroller and I2C circuit in our final board with a better soldering on the microcontroller, since the other two were not very good according to staff.
Focused on getting microcontroller flashing onto custom PCB. Continue performing some tests, including checking all the voltage level across components in my PCB. All voltage levels were approapriate, but it was still not running the code as it should.
Attempt to switch USB to Serial adapter to rule out possible corruption of data by the adapter. Then, using the IDE I compared the main addresses location code was written to between devboard and pcb esp32 module using idf.py monitor, which was the same.
Then, I started talking to other groups using ESP32 that I knew and was suggested to specify flash method in IDE to be UART, but still had the same issue. Then, was suggested to flash my esp32 directly from the IDE and not command line, as I had been doing so far.
After flashing, I opened the monitor tab and pressed reset, which allowed the microcontroller to function properly (blinking red LED). Looking back, I do not remember if I ever pressed reset button after flashing in the custom PCB (I know I did for devboard), which
could have been the issue. Overall, it seems that the devboard specifically has some mechanism that does not allow me to flash it and run via USB-to-Serial adapter, which is something one of the TAs had suggested the day prior. Achieving this was fundamental
to continue with the project and be able to test and integrate the rest of the sstems on board (Heart Rate sensor via I2C and Conductivity Sensor via DAC and ADC).
Finished adapting my previous code to use the heartrate calculation functions designed by a Brazilian for the MAX30102 sensor (Heart Rate Calculation).
Had to perform multiple changes in the sensor settings in order to enable data collection of both IR and RED LED, including using spO2 mode, which has been indicated by others to have better results for heart rate as well.
In addition, I made changes in my read fifo functions, since the FIFO buffer on sensor hold alternate samples
([RED, IR, RED, IR ...]). In addition, had to add another buffer to hold the data collected for IR sensor, and make both ir_buffer and red_buffer a circular buffer.
Then, using ESP-IDF's esp_timer_get_time() function, I added logic to append the microsecond timestamp for each burst read from the sensor's FIFO to a uint64_t time_array[]. I refactored the max30101_read_fifo() function so that both the red LED values and
their timestamps are stored synchronously, enabling better alignment when calculating heart rate intervals. I also configured an esp_timer periodic timer to invoke the FIFO read every 40ms to match our target sample rate of 25Hz. The result was a functional
buffering system with verified time differences between samples. By printing and eye-balling these timestamps, I could confirm the consistency and stability of the timer, learning that there is about ±3ms of jitter — likely due to processing overhead — but within an acceptable range.
This contributes to project progress by preparing our heart rate algorithm to work with real, temporally accurate data, which is a critical design requirement. Next steps are to ensure that this embedded software works properly with ESP32 on custom PCB. However, I might have to solder
a few more components to PCB, such as pull-up resistors.
Description: Integrated the entire embedded software with Bluetooth to receive signals to trigger interfaces and send "real-time" data. Debugged PCB assembly (buck-boost converter and microcontroller boot-reset circuit), as well as attempted to flash microcontroller via UART.
Worked on flashing and testing the ESP32 module (ESP32-D0WD-V3) on a breadboard using a USB-to-Serial adapter. The goal was to set up a stable development interface to flash firmware and monitor serial output without relying on an ESP32 development board, similar to what I need to program the module in PCB. I began by supplying 3.3V to the
module via the 3.3V pin from my USB-to-Serial adapter - but later changed to my Analog Discovery 2 (AD2) to eliminate risks of power fluctuation affecting my boot efforts (minimal risk) - connected to the VCC pin of the ESP32. Initially, it took me a long time to get the timing of pressing BOOT and EN right, taking some time to research on the web (and AI) on the correct order since my intial attempts were failing immediately.
After several attempts, I was able to start writing the code, but it was being suddenly terminated after 8 bytes for some errors/ reason. Then, after a few more attempts here and there,
I started to get it to write more, but got errors that MD5 of the file does not match data, which I believe suggests data corruption, like I saw in some other errors claiming that checksums did not pass.
However, after several attempts, I was able to seemingly succesfully download the code into the esp32 via UART. However, for that to happen, I had to specify the baud rate as 115200 and the port I was using (COM5). The esptool recognized the chip, uploaded the stub, erased and wrote to flash, and verified all hashes. Despite the basic flashing setup being successful, I encountered repeated issues where the ESP32 would not run the flashed code. Whenever I tried to reset the board to see if maybe it would start running my flashed code, the ESP32 began an endless loop of booting
and resetting with some frequent messages such as "Brownout detector was triggered" and rst:0x3 (SW_RESET).
However, whenever it was done directly from my computer to esp32 devboard, the ESP-IDF toolchain (idf.py flash monitor) successfully compiled and flashed the firmware.
To rule out a faulty chip, I swapped out the ESP32 with another unit and later switched to a known-good USB-to-Serial adapter. The results were consistent: flashing completed normally, but the firmware would not execute, and the device would reset. To double-check my setup, I connected a full ESP32 DevKitC board to the same USB port and flashed the same firmware. It worked perfectly, confirming the toolchain and code were not the issue.
I suspect the problem lies either with the power stability or with startup sequencing. Even though the AD2 output read a steady 3.3V, it may not be able to supply sufficient current for the ESP32 during high draw periods (such as Wi-Fi/BLE initialization), triggering the brownout detector.
Due to a TA saying that he had a group who was unable to get their code flashed with the devboard due to some SPI errors, but was able to do so in the custom PCB, I had Matt solder the microcontroller circuit for me so I could do some tests.
On the PCB, after supplying it with 3.3V directly from DC Power Supply, I started trying to flash my code into microcontroller. It was not working, with it immediately failing due to not recognizing ports and not being able to connect to microcontroller.
Initially, I thought I was pressing the buttons at wrong time, so I kept trying. After several attempts, even trying to boot Arduino code into esp32 module, I started checking my PCB circuit.
I checked every single voltage across components (resitors, capacitors, and buttons) related to microcontroller and identified that some components were not getting the proper power on both BOOT and RESET circuit. Then, I checked the resistance of every resistor, which was correct.
However, when checking the resistance for the buttons, I noticed that they were shorted. The footprint and the buttons datasheet/pinout were different. Due to that, I used a plier to cut the 2 connections in each button that were shorting them. I conducted all the tests on components voltage and saw they were correct (around 3.3V when not pressed and 0 when pressed). With the BOOT and RESET circuit working, I attempted to flash code to flash the GPIO13 LED.
However, like before, it was able to write the code to the esp32 module, but the LED did not flash.
Getting the microcontroller fully functional on PCB is essential for the entire project integration on final hardware, both conductivity and heartrate.
Next steps are to continue debugging this issue, which I am now inclined to believe it could be something to do with my software setup, even though it would be weird that I am able to flash it through the devboard, but not UART.
Worked on setting up conductivity sensor on breadboard. Tried supplying the DAC AC signal through the capacitor filters, but wave was not working. For some reasong, my 150Hz frequency defined on the cosine module config was coming as 300 and something. Searching up on the internet,
I realized that it was based on an internal clock, which might not match "real time," which could cause the discrepancies. I tried several different frequencies, but anything below 140Hz was deemed due low for that specific ESP32 cosine module. However, looking at the oscilloscope and calculating the time difference
between peaks, the wave seemed to be always around 140Hz. The filters started working, but the amplitude was too low. Therefore, I started trying different values of attenuation, arriving at 29. Using the potentiometer along the filters and DAC, I was able to change the amplitude, but only the positive part of the wave
shows on the oscilloscope. Being able to fully integrate this on the breadboard will allow us to facilitated debugging, if needed, on the actual PCB when we start assemblying that part of the hardware. It would also allow for a better development of the hydration recommendation algorithm.
I am also in the middle of adapting my code to use open source heart rate calculation functions designed by a Brazilian for the MAX30102 sensor (Heart Rate Calculation), which have performed better than the calculation attempts I have tried so far.
I will however need to configure a few more settings on the sensor and read some more data (Red LED rather than just IR) via I2C, which is why I will need to adapt my code, which is part of my next steps, in addition to finishing integrating everything conductivity sensor related.
Focused on integrating heartrate sensor interface and battery tracking level interface with Bluetooth to send real-time data to the App on mobile phone.
The BLE server exposes a Heart Rate Measurement characteristic under the standard 0x180D Heart Rate Service, using UUID 0x2A37 for the characteristic itself.
It supports both READ and NOTIFY properties.
Notifications are sent every 10 seconds, conditioned on an active BLE connection (ble_gap_conn_find(...) == 0), which means if the microcontroller connects to a device using BLE. The characteristic handle (hrm_handle) is initialized during the BLE sync callback using ble_gatts_find_chr(...).
Creating a global variable in max30101.c called latest_heart_rate, I assign the heartrate value calculated from the data retrieved from I2C to this variable and using the header files, I include it in the HydraWiseBLE.c file, assign its value to hr_to_send, allowing me therefore to send heart rate data retrieved from the sensor
every 10 seconds. As a result, I was able to achieve live BLE transmission of heart rate and learned BLE characteristic update flow using NimBLE stack, which is fundamental to fulfilling all the integration needed to complete the PSDRS, more specifically PSDR4 (Bluetooth), and to suceed in all the functional requirements
we set to our project.
Similarly, I followed the same framework and steps as the heart rate integration in order to integrate the battery level tracking code with BLE, even though that I2C interface code has not been tested yet since the IC is only in PCB. First,
I changed the notify_battery_task task to only send data every 10 seconds, then I created a global variable called battery_level, initialized it as 0, created a header file, and made it available by declaring it there. Then, I included the header into HydraWiseBLE.c,
and assigned/prepared the value to send over BLE in te following way:
// int bat_level_send = battery_level;
int bat_level_send = 88; // % battery
struct os_mbuf *batt_om = ble_hs_mbuf_from_flat(&bat_level_send, sizeof(bat_level_send));
int rc = ble_gattc_notify_custom(conn_handle_global, battery_handle, batt_om);
I currently have the assignment commented out and have been using dummy data due to the untested nature of the other code and the fact there is no I2C connection I can make until the coulomb counter is on PCB.
However, it builds fine and I tested updating the values "manually" in battery_tracking.c to send it over Bluetooth in HydraWiseBLE.c, which worked normally. As a result, I now have the battery tracking integrated with
Bluetooth to send the device's remaining battery to the user's app, so he/she can track it. This is a very useful tool for the user to be able to know when it is time to charge the device so they can keep using it.
Next steps include integrating conductivity sensor with all the software (embedded and app) in breadboard and start assembling microcontroller boot-reset circuit on PCB and figuring out how to flash my code into microcontroller.
Focused on fully integrating the conductivity measurement module with the BLE (Bluetooth Low Energy) GATT server implementation on the ESP32 to connect to the app. This required combining
work across the conductivity.c, adc.c, and dac.c components with HydraWiseBLE.c. The main goal was to enable BLE-based transmission of sweat conductivity as a processed signal per user request
(button click on app). The first real setback was figuring out how to integrate Areej's written code for bluetooth (HydraWiseBLE.c and app_main()) in my own project directory in a way it worked and
it did not disrupt my project directory structure. Initially, I attempted to have BLE components as its own directory inside project directory. It did not work. Bluetooth modules, such as Nimble, were not being recognized.
I proceeded in trying to include all the modules I needed, including in the CMakeLists.txt files, but it still did not work. Then, I tried changed the settings in idf.py menuconfig to enable nimble use only, yet it still did not work.
Again, I tried changing some includes and modules, checking the paths of those modules I was using in my esp-idf folder to verify that the path I was referencing was correct, which I find out the nimble module was not. Therefore, I tried to include that path directly in CMakeLists.txt, but it still refused to work.
Finally, I went back to the original include statements of the file and changed the BLE folder location to be inside components directory, along with all the other relevant code to this project (conductivity, heartrate, BMS). Following the structure of my CMakeLists.txt for the other directories, I set up the CMakeLists for HydraWiseBLE,
copied Areej's app_main function to my own app_main function, added the necessary include statements, including the creation of a HydraWiseBLE.h file in order to make some of the functions and variables defined in HydraWiseBLE directory available in other directories, and successfully build the project after a few iterations.
Now, in order to accomplish original goal, I brainstormed an idea to obtain the sweat conductivity measurement per user request by sending the AC wave via DAC for 10 seconds, reading the sensor output via ADC for the same amount of time, and averaging the values over a 10-second data acquisition window.
I began by revisiting the ADC task that samples analog conductivity readings from GPIO32 (ADC1_CHANNEL_4). The ADC was configured in continuous mode using the ESP-IDF v5.4 adc_continuous_* APIs. I implemented a timing loop and logic that limited the
sampling period to 10 seconds using esp_timer_get_time(). The readings were averaged over that window, yielding a single float value representing the final conductivity estimate. This approach ensured minimal memory footprint and low BLE transmission overhead.
Next, I resolved issues around disabling the DAC after waveform generation. I initially encountered trouble finding proper shutdown methods (no dac_stop() exists). After testing several workarounds, I used dac_cosine_stop(chan0_handle), dac_output_disable(DAC_CHANNEL_1),
and manually forced the DAC output low using dac_output_voltage(DAC_CHANNEL_1, 0) - successfully ensuring no residual output remained after measurement.
To send the averaged conductivity value over BLE, I used NimBLE's ble_hs_mbuf_from_flat() to prepare a GATT-compatible buffer, and ble_gattc_notify_custom() to transmit to a characteristic. I confirmed that both conn_handle_global and the conductivity_handle were accessible from the BLE service context. All of this (DAC, ADC, and stopping DAC) is initiaded by a task I created called trigger_conductivity_measurement_task, which is triggered by a Bluetooth event (button click on app).
This value now updates on the app after each 10-second cycle initiated by the user on the app interface, which was confirmed by real-time acquisition of data by ADC (1V supplied by AD2), a 0.4Vpp Cosine wave at 140Hz (AD2 oscilloscope), and BLE delivery of conductivity data (visible on app), like I intended. In this work session, I was able to learn how to integrate different components into Espressif project structure, to debug code/setup, and how to manage ADC memory constraints, DAC shutdown procedures,
and the BLE GATT buffer format using NimBLE. This integration is crucial for closing the feedback loop from sensing to the mobile app.
This is the first major successful sensor → BLE data path in the system. It sets the framework for heart rate and battery data transmission as well.
Next Steps include tesing signal variability under actual sensor exposure, integrating DAC -> analog circuit -> sensor -> ADC, and integrate heartrate sensor and battery levels tracking code with BLE and the app.
ADC Output Post Integration with BLE DAC Output Post Integration with BLE
Dedicated time to refine the heart rate data processing functionality. My primary focus was on translating and integrating SparkFun’s Arduino-based heart
rate algorithms into the Espressif-IDF environment. The SparkFun code, originally written in C++ for Arduino, needed to be restructured to function within a plain C context
without relying on Arduino-specific constructs like millis() or Serial.print(). I translated core components such as the signal smoothing, moving average filters, and peak detection logic
while making sure the implementation remained compatible with IDF.
After translation, I concentrated on the circular buffer logic used to store and process recent LED readings. The buffer is a critical structure for enabling real-time analysis of signal trends, particularly for detecting rising and falling edges associated with pulse peaks.
I reviewed the logic responsible for handling index wrapping and data insertion, ensuring that the buffer didn’t suffer from off-by-one errors or data overwrites. Furthermore, I checked how derivative calculations and threshold comparisons were being performed across the buffer window.
These calculations are key for identifying heartbeats based on sharp increases in signal amplitude.
With the updated processing in place, I proceeded to collect and print raw data from the MAX30101’s FIFO, specifically using the green LED. The raw values appeared reasonable and consistent during both contact and detachment, demonstrating that the sensor hardware and configuration appear to be working correctly.
However, despite the seemingly valid signal, the beat detection algorithm failed to produce accurate or consistent BPM values. At times, the algorithm would register a beat with a plausible value like 59 BPM, but most of the time it either failed to detect any beats or output unrealistically low values such as 2.4 or 3.7 BPM.
This debugging session gave me insight into the nuances of signal processing for photoplethysmography (PPG) and highlighted the importance of aligning algorithm assumptions with actual sampling conditions. For example, the SparkFun algorithm presumes a fixed sampling rate, but discrepancies in timing or buffer handling on the ESP32 could be skewing the beat interval calculations.
Moving forward, my next steps will include going over my code from the start, checking over all my I2C and data retireval logic to guarantee its proper functioning, as well as go over my processing logic to pinpoint possible problems and errors. Succeeding in this is essential to have all the health functionality capabilities our design intended, and it is also a PSDR.
Today I worked on adapting and debugging Espressif’s example code for continuous ADC sampling (ADC Continuous Example) in order to accurately collect analog voltage data from GPIO32 (ADC1_CHANNEL_4), which is tied to the sweat conductivity sensor in our project.
The foundation of my implementation was the official ESP-IDF ADC continuous mode example provided by Espressif. That reference code was structured to demonstrate how to read from multiple channels using ADC1 and ADC2 with configurable patterns
and buffer frames. However, to tailor this code for the needs of HydraWise, I made a series of significant changes. First, I reduced the number of active ADC channels from two to one, configuring only ADC1_CHANNEL_4 because GPIO32 is the specific
pin wired to our sweat sensor. I replaced the original channel[] array and ensured the correct mapping to GPIO32 was maintained.
In the original code, logging statements and validation loops were written to accommodate data from multiple channels and print all incoming values. I removed this dynamic channel loop logic and simplified the data filtering process to check exclusively for channel 4,
which reduced overhead and made the logs easier to interpret. Furthermore, I introduced a line to convert the raw ADC readings to a meaningful voltage by dividing by the maximum ADC value (based on 12-bit resolution) and multiplying by the reference maximum of 1.1V, which corresponds
to 0 dB attenuation. This step is critical because the sweat sensor outputs a voltage proportional to ionic conductivity - our goal is to eventually transform this voltage into an estimate of electrolyte concentration, which will serve as the basis for hydration status assessment in the wearable.
One key obstacle I encountered during the adaptation was a persistent crash due to an invalid ADC configuration. Initially, I had mistakenly set the sampling frequency too low (1 kHz), which is not supported by the continuous ADC driver. This resulted in an ESP_ERR_INVALID_ARG failure and reboot loop.
I resolved this by increasing the sampling frequency to 20 kHz, a rate consistent with official documentation and other working implementations. After registering the conversion-done callback and starting the driver, the task was able to receive and process data as expected, with valid voltage outputs streaming through the serial terminal when I input values
below 1.1V on the ADC (1V and 0.85V), giving measurements with little fluctuation in its readings.
The ADC component is a foundational piece of our project because it captures the raw signal from the sweat conductivity sensor, the data from which will be analyzed to determine hydration recommendations for the user. Ensuring the accuracy and reliability of this signal path is essential before applying any interpretation or algorithmic conversion.
With this functionality complete, my next step is to finish integrating the MAX30101 heart rate sensor by configuring its I2C interface and processing the pre-filtered heart rate signal. Once both sensor systems are operational, I will focus on unifying their outputs and broadcasting the combined data over Bluetooth Low Energy to our mobile app, completing the full
cycle from sensor acquisition to real-time feedback.
Researched and developed A9: Legal and Regulatory Analysis. Did in depth research on the regulatory bodies
that HydraWise would need to comply with (FCC, FDA, CE, RoHS, etc.) to understand better their scope and purpose, as
well as the steps needed to take in order to regularize product with this organizations (refer back to A9 for furthert details).
In addition, researched the patents I had found and mentioned on the initial proposal document to familiarize myself more with its claims. Then,
did an extensive reflection and analysis on potential infrigements, as well as if it would be a literal infrigement or just doctrine of equivalents (refer to A9).
This assignment is fundamental in order to understand all the next steps needed if we were to put our product to market, not only to avoid litigation, but also to be able to market the product and sell, which we will not.
Therefore, no further steps on this sphere will be needed.
Date: March 28, 2025 Start Time: 10:30 am Duration: 5 hours
Made significant updates to the PCB layout based on Dr. Walter's feedback, specifically focusing on the buck-boost converter design. The main concern was the high-frequency switching of the inductor, which required careful attention to the inductor planes to prevent interference from other signals.
Dr. Walter’s feedback emphasized the need for the inductor planes to be directly under the inductor, without any conflicting signals on the top or bottom copper layers. To address this, I rearranged components on the PCB to ensure proper placement of the inductor planes. On the top copper layer, I added four dedicated planes: one for the input voltage, one for the output voltage, one for L1 of inductor, and one for L2 of inductor.
Additionally, I ensured that there was a solid ground plane that is connected to the thermal pad beneath the IC, which is essential for thermal management. The layout was updated according to the recommended geometry in the datasheet to ensure optimal performance.
The FB pin was properly connected to the output voltage plane using vias and routed on the back layer, as suggested. Similarly, the VINA, PS/SYNC, and EN pins were routed to the input voltage plane using vias.
In addition to the buck-boost converter changes, I also made updates related to the charger layout. On the back copper layer, I added an input voltage plane and an output voltage plane. I connected these planes to the corresponding top copper planes using vias to facilitate heat dissipation, as per Dr. Walter’s guidance. The ground planes on both sides of the PCB are now interconnected, ensuring proper thermal management and heat dissipation. I followed the datasheet’s example for the BQ21040DBVR charger layout (Figure 29), particularly focusing on the ground, input, and output planes.
After these updates and approval, I completed the changes and sent the revised PCB layout for production after generating gerber files, drill files, and map files. The PCB is expected to arrive in 2-4 business days. Once the boards arrive, the next steps will include assembling the power network and verifying the buck-boost converter design to ensure everything functions as expected.
Date: March 26, 2025 Start Time: 9:45 am Duration: 4 hours
Focused on updating the DAC implementation to use a non-deprecated and less noisy version of the DAC, specifically the cosine wave generator (used this repository as reference: DAC Example), which provides
a cleaner output compared to the previous approach. The use of a cosine wave, centered at around 1.5V with a peak-to-peak voltage (Vpp) of 0.4V, was tested successfully (see figure below).
During testing, the results showed minimal noise in the waveform. The addition of filters significantly helped in removing the DC offset, improving the signal integrity. The waveform generation on GPIO32 was stable,
and the output was much cleaner compared to the previous sine wave implementation. This shift to the cosine function helped in achieving the required specifications for this stage of the project, which will be essential for
the conductivity sensor implementation (providing AC signal to its associated circuit). Next steps are to integrate this with the other software applications and implement it on PCB once it arrives.
After successfully updating the DAC, I moved on to implementing the ADC functionality using the continuous ADC driver for GPIO32. The intention was to read and process the voltage from the ADC continuously, and for that I reference the following repository ADC Continuous Example.
However, upon testing the system, the results were not as expected. The ADC readings consistently returned two values: 79 and 255, which are far lower than the expected voltage range. This issue might be caused by improper configuration of the ADC, or there could be issues related to the ADC calibration and the reference voltage. Additionally, the readings did not change much, which suggested that the ADC
might not be sampling properly or that the configuration was not optimal for the expected voltage levels. I plan to investigate further by checking the calibration of the ADC, ensuring that the input signal is within the proper range, and verifying the accuracy of the reference voltage (Vref). Additionally, I will explore possible adjustments in the ADC configuration, including the sampling rate and other relevant settings,
to ensure the readings reflect the actual voltage at GPIO32. Further tests will be needed to troubleshoot and correct this issue.
Date: March 15, 2025 Start Time: 11:30 am Duration: 5 hours
Implemented a series of updates to the PCB layout based on the latest recommendations and feedback. First, I focused on the regulator circuit. I tried to redesign the regulator layout to match the schematic on page 16, ensuring that the current paths and heat dissipation requirements are met. I paid special attention to the component placements and trace widths to handle the expected thermal load effectively.
Next, I updated the layout for the BQ21040DBVR circuit, following the datasheet guidelines shown on page 22. Every pin and trace was repositioned to match the recommended layout, which should improve both performance and reliability of the charging circuitry.
I then reviewed the BQ27441-G1 datasheet (page 4) regarding the BIN and GPOUT pins. The datasheet clearly states that these pins should not be left floating, so I added the necessary pull-up and pull-down resistors. This change should stabilize the voltage levels on these pins and prevent any unintended behavior in low-power or shutdown modes.
To regulate the temperature of the IC, I added an external NTC thermistor with a voltage divider circuit. This addition will provide a temperature-dependent voltage to help manage thermal conditions, ensuring that the IC operates within safe limits.
I also addressed the programming header by adding a protection diode to prevent any reverse current. This is crucial for protecting the board during debugging and programming.
While I had already included a debugging LED, I took this opportunity to add a dedicated power indicator LED. This should help with visual confirmation that the board is receiving the proper supply voltage during operation.
For the heart rate sensor connector, I integrated ESD protection (diode) to safeguard against potential electrostatic discharge events, which is critical for safety and device reliability. Additionally, I routed my extra GPIO pins out to vias, providing more flexibility for future expansions or debugging.
Overall, these updates bring the PCB layout much closer to the datasheet recommendations and improve the robustness of the design. The next steps will involve getting the approval from staff to order the PCB or make any other necessary changes they deem necessary.
Implemented several critical updates to the PCB layout based on detailed feedback from the project staff. I started by addressing the geometric issues: acute angles were removed from key components (notably Pin 25 on the microcontroller and Pin 10 of the regulator), and the small vias on the back of the microcontroller were replaced with a larger via, which can now be soldered from the backside rather than using a hot plate. This change should improve both manufacturability and thermal performance.
I also updated the schematic to include the battery connector, ensuring that power management is fully integrated into our design. To further improve power integrity, I isolated the analog power section using an 0805 ferrite bead, which should help reduce noise in sensitive analog circuits. A ground plane was added to the backside of the microcontroller to assist in heat dissipation, a key change given the increased processing and power requirements. Additionally, I flipped the USB-C charging receptacle to better suit the board layout and moved the power switch to the board’s edge (after verifying the appropriate footprint) for easier user access.
Other modifications include excluding mounting holes from the power plane. I also reworked the buck booster layout by following the recommended layout from the data sheet and using Webench to verify the design. Finally, I added extra vias around the conductivity sensor area, allowing for easy modifications if needed later on.
These modifications are important to achieve a better design for our PCB and so there is no future complications when assemblying it. Next steps are continuing to integrating the sttaf's feedback so that we can order as soon as possible.
Date: March 13, 2025 Start Time: 9:00 am Duration: 1
Adapted our ADC reading code to measure voltage levels from our conductivity sensor connected to GPIO32. Since GPIO32 maps to ADC1 Channel 4 on the ESP32, I updated the channel definition accordingly. I maintained the multisampling approach with 64 samples to improve measurement accuracy and noise reduction, and used the same calibration routines as before.
The initial code was based on Espressif’s ADC example (Reference Code), and I adapted it to suit our sensor’s needs, while also learning how it operates. This change is crucial as it allows us to read from GPIO32 (ADC_CHANNEL_4) instead of the previously used channel. Although the code structure remains largely the same, this modification will help us validate sensor readings from the new pin configuration.
The next steps involve deploying this code onto the ESP32, testing the sensor's behavior on GPIO32, and fine-tuning the calibration if necessary, as well as adjusting voltage levels. This adaptation is a critical part of ensuring our sensor integration is both flexible and robust, allowing us to easily reassign ADC channels as our project evolves.
#include <stdio.h>
#include <stdlib.h>
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "driver/gpio.h"
#include "driver/adc.h"
#include "esp_adc_cal.h"
#define DEFAULT_VREF 1100 // Use adc2_vref_to_gpio() to obtain a better estimate
#define NO_OF_SAMPLES 64 // Multisampling
static esp_adc_cal_characteristics_t *adc_chars;
// Update channel definition: GPIO32 corresponds to ADC1 Channel 4
static const adc_channel_t channel = ADC_CHANNEL_4; // GPIO32 on ADC1
static const adc_bits_width_t width = ADC_WIDTH_BIT_12;
static const adc_atten_t atten = ADC_ATTEN_DB_0;
static const adc_unit_t unit = ADC_UNIT_1;
static void check_efuse(void)
{
// Check if TP is burned into eFuse
if (esp_adc_cal_check_efuse(ESP_ADC_CAL_VAL_EFUSE_TP) == ESP_OK) {
printf("eFuse Two Point: Supported\n");
} else {
printf("eFuse Two Point: NOT supported\n");
}
// Check Vref is burned into eFuse
if (esp_adc_cal_check_efuse(ESP_ADC_CAL_VAL_EFUSE_VREF) == ESP_OK) {
printf("eFuse Vref: Supported\n");
} else {
printf("eFuse Vref: NOT supported\n");
}
}
static void print_char_val_type(esp_adc_cal_value_t val_type)
{
if (val_type == ESP_ADC_CAL_VAL_EFUSE_TP) {
printf("Characterized using Two Point Value\n");
} else if (val_type == ESP_ADC_CAL_VAL_EFUSE_VREF) {
printf("Characterized using eFuse Vref\n");
} else {
printf("Characterized using Default Vref\n");
}
}
void adc(void)
{
// Check if Two Point or Vref are burned into eFuse
check_efuse();
// Configure ADC for ADC_UNIT_1
if (unit == ADC_UNIT_1) {
adc1_config_width(width);
adc1_config_channel_atten(channel, atten);
} else {
adc2_config_channel_atten((adc2_channel_t)channel, atten);
}
// Characterize ADC
adc_chars = calloc(1, sizeof(esp_adc_cal_characteristics_t));
esp_adc_cal_value_t val_type = esp_adc_cal_characterize(unit, atten, width, DEFAULT_VREF, adc_chars);
print_char_val_type(val_type);
// Continuously sample ADC
while (1) {
uint32_t adc_reading = 0;
// Multisampling: take NO_OF_SAMPLES readings
for (int i = 0; i < NO_OF_SAMPLES; i++) {
if (unit == ADC_UNIT_1) {
adc_reading += adc1_get_raw((adc1_channel_t)channel);
} else {
int raw;
adc2_get_raw((adc2_channel_t)channel, width, &raw);
adc_reading += raw;
}
}
adc_reading /= NO_OF_SAMPLES;
// Convert adc_reading to voltage in mV
uint32_t voltage = esp_adc_cal_raw_to_voltage(adc_reading, adc_chars);
printf("Raw: %d\tVoltage: %dmV\n", adc_reading, voltage);
vTaskDelay(pdMS_TO_TICKS(1000));
}
}
Updated ADC code to read from GPIO32 (ADC_CHANNEL_4) for conductivity sensor voltage measurements. (Reference: Espressif ADC Example)
Date: March 12, 2025 Start Time: 10:00 am Duration: 3 hours
Focused on developing and refining a piece of embedded C code in Espressif (adapted from the Arduino code we had already developed) to generate a sine wave using the ESP32's DAC. The goal was to create a smooth analog output by cycling through a predefined sine table of 50 8-bit values. This project required integrating several FreeRTOS components and ESP-IDF libraries such as freertos/task.h for multitasking, driver/dac.h for controlling the DAC, and esp_log.h for logging.
The code begins by initializing the DAC on channel 1 (mapped to GPIO25) and then enters an infinite loop where it iterates over the sine table. For each table value, the DAC output is updated and the program waits for a precise delay (set to 133 microseconds) using ets_delay_us(). This delay is crucial as it determines the frequency of the output sine wave. I calculated the best delay for a 150Hz wave to optimize the waveform's smoothness and stability.
Throughout the development, I encountered challenges with timing accuracy and ensuring that the sine wave was free of jitter. To address these issues, I revisited the ESP32 documentation and FreeRTOS timing functions, which ultimately helped me fine-tune the delay mechanism. The use of a pre-scaled sine table (with values between 0 and 255) simplified the DAC output process and allowed for a more efficient loop without the need for real-time computations.
Overall, this exercise not only improved my understanding of DAC operations and precise timing in embedded systems but also provided valuable experience in integrating various ESP-IDF libraries for a cohesive application. The final implementation still needs further testing, specially with the filters (capacitors) we had planned to regulate its smoothness.
Next steps would be to continue the testing and guaranteeing it works without issues.
#include <stdio.h>
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "driver/dac.h"
#include "esp_log.h"
#include "esp_system.h"
#include "esp_timer.h"
#include "esp_rom_delay_us"
static const char *TAG = "SineWaveDAC";
#define SINE_TABLE_SIZE 50
// Sine table with 50 points (values scaled for 8-bit DAC: 0-255)
const uint8_t sineTable[50] = {
128, 143, 159, 174, 189, 203, 215, 226, 236, 245,
249, 253, 255, 255, 253, 248, 243, 235, 225, 214,
203, 190, 176, 163, 149, 128, 107, 93, 80, 66,
53, 42, 31, 21, 13, 8, 3, 1, 1, 3,
7, 11, 20, 30, 41, 53, 67, 82, 97, 113
};
void gen_sine_wave(void)
{
ESP_LOGI(TAG, "Starting DAC Sine Wave Example");
// Enable DAC output on channel 1 (GPIO25)
dac_output_enable(DAC_CHANNEL_1);
int index = 0;
// Delay in microseconds between updates (determines the freq of the generated sine wave)
const int delay_us = 133;
while(1) {
uint8_t value = sineTable[index];
// Set DAC output voltage (0-255)
dac_output_voltage(DAC_CHANNEL_1, value);
index = (index + 1) % SINE_TABLE_SIZE;
// Delay for precise timing
ets_delay_us(delay_us);
}
}
Code snippet for generating a sine wave using the ESP32 DAC.
Focused on finishing and adjusting schematic, getting more familiar with PCB layout tool in KiCad, and use that knowledge to help with the PCB design (organization, traces, footprints, and etc.).
Dedicated several hours to deepening my understanding of PCB layout best practices by following tutorials and watching detailed instructional videos. I explored resources that covered the effective use of copper zones and proper via placement to optimize trace routing and signal integrity. One video (Zones Fill) offered practical insights into managing zones, while the KiCad documentation (KiCad PCB Editor Documentation) reinforced these techniques.
With the newfound knowledge, I started untangling the component layout for our board. I strategically organized the board by assigning specific regions for each circuit block: placing the power network and the microcontroller at opposite edges to minimize interference, isolating the analog circuit in the top middle for optimal signal performance, and positioning the heart rate connector with its switch at the bottom center for easy accessibility. This is extremely important for an optimal performance of the device and to guarantee no unexpected issues arise. These layout decisions were also guided by the manufacturing constraints set by JLCPCB.
In setting up the board constraints, I configured KiCad to match JLCPCB’s specifications for 2-layer PCBs. I established a grid spacing of 0.1 mm, set the minimum trace width and clearance to 0.16 mm and a solder mask expansion of 0.038mm. These specific numerical constraints are critical to ensuring that the final design will be manufacturable and reliable according to JLCPCB’s guidelines (JLCPCB PCB Manufacturing). Next steps are to finish the Layout and tracing/routing while managing DRC error free.
Now, working with Matt Dailey, we did a lot of the traces and routing for the components, discussing the best ways to connect them, where to add vias, zones, searching for better component footprints, among other things. This was fundamental to get the initial PCB layout done for the Midterm review on March 6th. Next steps include incorporating the feedback from the review into our design.
Initial Organization of PCB Layout Final Organization of PCB Layout before Review
Date: March 4, 2025 Start Time: 00:00 am Duration: 3 hours
Dedicated my time to a comprehensive review of the remaining schematics for our power network, heart rate sensor, and conductivity sensor circuit. In the power network section of the design, which includes a buck booster, a coulomb counter, and a battery charging IC, along with a USB-C receptacle, I implemented a few changes. To enhance power management and user control, I integrated a switch between the battery and the coulomb counter (and the rest of the power network), enabling the device to be turned on and off as needed. Additionally, I added a zener diode to protect the charging IC from voltage spikes - a crucial safeguard explained in detail in this resource: Zener Diodes. This is fundamental or our device to save power when it is not being actively used.
After updating the schematics, I conducted an extensive ERC review, addressing over 70 errors and 140 warnings. The issues ranged from common connectivity errors such as “not connected” and “off the grid,” to more subtle problems like inconsistent labeling across connections. Each warning was carefully analyzed and resolved to ensure that the schematic was both electrically sound and in full compliance with our design rules. Next steps are to do the PCB Layout and check DRC for a consistent and error free design.
Schematic for switch and added protection using a zener diode.
Focused on the detailed design of a USB to Serial UART adapter using the CP2102 chip. My design incorporates MOSFETs on the DTR and RTS lines to implement auto reset and auto boot functionalities, which are critical for reliable microcontroller programming. By using MOSFETs, I was able to ensure that the control signals are properly level-shifted and that transient conditions do not inadvertently trigger resets. This approach also provides a cleaner signal path compared to a passive resistor-capacitor network. In addition, this would provide an automatic programming of the microcontroller.
In order to implement this design, I had to do extensive research in its components and different implementations, including the multiple chips possible that can adapt USB to serial data. I compared several chips for USB to UART conversion and chose the CP2102 for its robust driver support and ease of integration with the remaining circuit, including the auto reset and boot circuit. Other alternatives evaluated were the FT232RL and CH340G. The FT232RL, while offering excellent performance, tends to be more expensive and requires more external components. The CH340G, on the other hand, is highly cost-effective but can present driver compatibility issues on some operating systems. Overall, the CP2102 struck the best balance between cost, ease of use, and design flexibility for our application, while being less complex and hence less chance for errors/complications.
Implementing the MOSFET circuits on the DTR and RTS lines was particularly interesting. These circuits not only facilitate a smooth auto reset mechanism but also help in initiating the boot sequence without manual intervention. However, the group has later opted against this implementation of USB to serial adapter and chose to use an off the shelf SparkFun break board with a connector attached on the PCB to conduct the microcontroller programming (manual boot and reset). Next steps are to continue reviewing the schematics for our product systems and adjust according to specifications and ERC.
Description: This week I demonstrated both the integration of a battery power network prototype, with coulomb counting (charge tracking) and a buck‑boost converter, and the heart rate sensor using green LED operation with the ESP32 (via Arduino).
Date: February 28, 2025 Start Time: 10:00 aM Duration: 3 hours
After reading most of the KTH Bachelor Thesis Report on conductivity sensors by Boström and Nyberg (2020) –
which emphasizes that an instrumentation amplifier must precisely amplify the voltage difference between sensor electrodes for accurate measurement –
I built the instrumentation amplifier circuit for our sensor module to provide an alternative from the simplified circuit my group had previously built and appeared to have worked.
At the same time, James Neff constructed the driver circuit for the finalized full circuit. We then attempted to test the integrated system by feeding in a sine wave generated from AD2; however,
the results have been irregular. There is a chance we might be measuring the signal with our oscilloscope in the wrong place (to compare with paper's result). Further troubleshooting is needed to determine whether the issue lies in the circuit’s performance/setup or in our measurement setup.
Suceeding in this would be very important to retrieve an smooth signal, with not as much noise as our primary alternative had, for a fundamental part of our project: measuring conductivity. Next steps will be
troubleshooting the circuit or reevaluating where I am taking the measurements to validate the circuit's results.
Initiated ESP32 Microcontroller Schematic Design, including ESP32 symbol, reset circuit, and boot circuit. Conducted a lot of research on ESP32 PCB Design
in order to find and know how to design all the components needed for the PCB design of our microcontroller.
For this, I accessed the datasheet (can be seen at Documents section in website) and a few videos on Youtube on some other ESP32 series of
microcontroller PCB being developed (https://www.youtube.com/watch?v=jiJGbWOSdMo). This helped me understand boot circuit and
led me indirectly to the realization that we will need an USB to serial adapter to comunicate with microcontroller for the embedded programming.
This is fundamental for our PCB design since the microcontroller will initiate all the operations necessary for our project. Next steps will be to continue aiding
Matthew Dailey with the PCB design wherever he needs.
Microcontroller schematic
Arduino Prototyping:
Implemented a version of the Arduino code for the LTC4150 coulomb counter running on the ESP32.
This version uses an interrupt-based approach to capture the pulse output on INT_PIN (GPIO4), reads a polarity signal from POL_PIN (GPIO5) to determine if the battery is charging or discharging,
and employs CLR_PIN (GPIO15) to reset the counter periodically. In the code, the Interrupt Service Routine is kept very short—simply setting a flag—so that all processing
(such as updating battery capacity in mAh, calculating state-of-charge, and computing current based on the time between pulses) happens in the main loop. I also calculate how much each pulse
alters the battery percentage using a constant (ah_quanta) and then compute the current in milliamps from the time delta between pulses. The serial monitor prints updated battery status every second,
and the counter is reset every 60 seconds by toggling the CLR_PIN. This implementation builds on a public available repository (see reference below), thereby providing a comprehensive battery monitoring solution.
#include "Arduino.h"
#define INT_PIN 4 // Interrupt output from LTC4150
#define POL_PIN 5 // Polarity output (HIGH = Charging, LOW = Discharging)
#define CLR_PIN 15 // Counter reset pin (Moved from GPIO 2 to GPIO 15)
// Battery tracking variables
volatile double battery_mAh = 2000.0; // Initial battery capacity (mAh)
volatile double battery_percent = 100.0; // Initial state-of-charge (%)
// Coulomb counter constants
const double ah_quanta = 0.17067759; // mAh per INT pulse
double percent_quanta;
// Interrupt tracking
volatile bool isrflag = false; // Flag set in ISR
volatile unsigned long currentTime, lastTime;
volatile double mA;
// **Short ISR (Interrupt Handler)**
void IRAM_ATTR myISR() {
isrflag = true; // Set flag only, do NOT perform calculations here
}
void setup() {
Serial.begin(115200);
pinMode(INT_PIN, INPUT_PULLUP); // Prevents floating input
pinMode(POL_PIN, INPUT);
pinMode(CLR_PIN, OUTPUT);
attachInterrupt(digitalPinToInterrupt(INT_PIN), myISR, FALLING); // Attach optimized ISR
Serial.println("LTC4150 Coulomb Counter Initialized.");
// Calculate how much each INT pulse changes battery percentage
percent_quanta = 1.0 / (battery_mAh / 1000.0 * 5859.0 / 100.0);
}
void loop() {
static unsigned long lastPrintTime = 0;
// **Process the pulse only when an interrupt occurs**
if (isrflag) {
isrflag = false; // Reset flag
lastTime = currentTime;
currentTime = micros();
// Read polarity pin to determine charging or discharging
bool polarity = digitalRead(POL_PIN);
if (polarity) {
battery_mAh += ah_quanta; // Battery charging
battery_percent += percent_quanta;
} else {
battery_mAh -= ah_quanta; // Battery discharging
battery_percent -= percent_quanta;
}
// **Calculate current in mA based on pulse timing**
if (lastTime > 0) {
mA = 614.4 / ((currentTime - lastTime) / 1000000.0);
if (polarity) mA = -mA; // Negative mA when charging
}
}
// **Print battery status every second**
if (millis() - lastPrintTime >= 1000) {
lastPrintTime = millis();
Serial.print("mAh: "); Serial.print(battery_mAh);
Serial.print(" | SOC: "); Serial.print(battery_percent);
Serial.print("% | Time: ");
Serial.print((currentTime - lastTime) / 1000000.0);
Serial.print("s | Current: ");
Serial.print(mA);
Serial.println(" mA");
}
// **Reset counter every 60 seconds**
if (millis() % 60000 < 1000) {
digitalWrite(CLR_PIN, HIGH);
delay(10);
digitalWrite(CLR_PIN, LOW);
Serial.println("Counter Reset.");
}
}
Testing the code with the prototype confirmed that the interrupt-driven pulse counting worked reliably,
with the ESP32 accurately reporting both the pulse count and the calculated charge. This coding session was
a vital step in integrating the battery monitoring functionality into our power network, and the use of interrupts proved essential
for capturing high-frequency pulses without overloading the main processor loop. Next steps include converting and adjusting this code
to run in native esp-idf code (C/C++), so that we can upload the firmware into the actual project with this functionality
implemented.
Worked on adapting the SparkFun heart rate sensor code for a MAX30105-based heart rate monitoring sensor, adjusting it to use the green LED
instead of the default red. My expectation was that the green LED, once enabled with a medium intensity, would provide consistent and reliable readings.
However, during testing I observed irregular readings that were, surprisingly, even worse when using the red LED. I conducted multiple tests, varying the pulse
amplitude and other parameters, but the inconsistency persisted. Below is the modified Arduino code I used. The code initializes the sensor with only the green
LED active, disables the red and IR LEDs, and processes the green value to detect heart beats. Despite the modifications and extensive testing, the irregular results were
unexpected, and I plan to investigate further to determine whether the issue lies with the sensor, the LED configuration, or external factors affecting the readings.
#include "Wire.h"
#include "MAX30105.h"
#include "heartRate.h"
#define RATE_SIZE 4
MAX30105 sensor;
float rates[RATE_SIZE] = {0};
uint8_t rateSpot = 0;
unsigned long lastBeat = 0;
float beatsPerMinute = 0;
float beatAvg = 0;
unsigned long samplesTaken = 0;
unsigned long startTime = 0;
void setup() {
Serial.begin(115200);
while (!Serial);
Wire.begin();
Serial.println("\nUsing GREEN LED for Heart Rate Measurement");
if (!sensor.begin(Wire, I2C_SPEED_STANDARD)) {
Serial.println("MAX30105 not found. Check connections.");
while (1);
}
Serial.println("MAX30105 connected!");
Serial.println("Place your index finger on the sensor with steady pressure.");
sensor.setup();
sensor.setPulseAmplitudeGreen(0x2F); // Enable Green LED with medium intensity
sensor.setPulseAmplitudeRed(0); // Disable Red LED
sensor.setPulseAmplitudeIR(0); // Disable IR LED
startTime = millis();
}
void loop() {
uint32_t greenValue = sensor.getGreen();
samplesTaken++;
if (checkForBeat(greenValue)) {
Serial.println("BEAT");
unsigned long currentTime = millis();
unsigned long delta = currentTime - lastBeat;
lastBeat = currentTime;
if (delta > 0) {
beatsPerMinute = 60.0 / (delta / 1000.0);
}
beatsPerMinute = round(beatsPerMinute * 10.0) / 10.0;
if (beatsPerMinute < 255 && beatsPerMinute > 20) {
rateSpot = (rateSpot + 1) % RATE_SIZE;
rates[rateSpot] = beatsPerMinute;
beatAvg = 0;
for (uint8_t i = 0; i < RATE_SIZE; i++) {
beatAvg += rates[i];
}
beatAvg /= RATE_SIZE;
beatAvg = round(beatAvg);
}
}
float Hz = samplesTaken / ((millis() - startTime) / 1000.0);
if (samplesTaken % 200 == 0) {
Serial.print("Green=");
Serial.print(greenValue);
Serial.print("\tBPM=");
Serial.print(beatsPerMinute);
Serial.print("\tAvg=");
Serial.print(beatAvg);
Serial.print("\tHz=");
Serial.println(Hz);
}
vTaskDelay(pdMS_TO_TICKS(10));
}
This Arduino code was ran in esp32 using I2C for microcontroller and sensor communication. The results, despite not up to the standards I expected,
were a good way to have a functioning prototype (the actual native esp-idf code still has some issues with data processing) for our Midterm review
and assure that actual data is being transmitted with our hardware setup. After inspecting Sparkfun's heartrate data processing,
I will try to translate it to C so I can use it for my own code in Espressif.
Built a prototype circuit for our power network, integrating a rechargeable battery, an LTC4150 coulomb counter,
and a Pololu buck‑boost converter. I started by reviewing the datasheets for each component to understand the required connections
and voltage requirements. After sketching the schematic, I assembled the circuit on a breadboard. I connected the battery to the LTC4150,
ensuring that all current flowing through the battery was monitored, and routed its output to the buck‑boost converter (Vin). The converter needed
special attention, as its enable (EN) pin was designed to work with a resistor divider rather than being tied directly to VIN. I had not initially understood
the function of EN, so I left it unconnected at first, which oviously resulted in no voltage output when I tried measuring it with AD2 oscilloscope.
Then, I tried connecting EN to Vin, which did not behave according to what I expected. Finally, after reading a source online (see References below) I calculated that
for a 3.7V source and a desired output of 3.3V, the EN pin should have about 0.78V. Using a 222 kOhms resistor to connect Vin to EN and with the help of the builtin potentiometer to finetune the voltage level,
I was able to provide 0.78V to EN. Once everything was wired, I powered the circuit. The voltage output was not very noisy, so I only added a diode to protect from reverse polarity.
With these adjustments, the buck‑boost converter finally produced a stable 3.3V output. I then connected the pulse output from the LTC4150 (INT pin) to GPIO4 on an ESP32 to count the current
pulses, while connecting POL to GPIO5 and CLR to GPIO15. This setup will allow me to monitor the battery's charge/discharge in real-time, while powering the ESP32 and remaining circuit. Despite some setbacks with the EN pin configuration
and minor resistor tolerance issues, the prototype performed as expected and I was able to fully power the microcontroller and the heartrate monitor in my breadboard.
The entire process reinforced the importance of carefully reading datasheets, as I lost some time due to lack of attention in reading some of the datasheet. Finishing this prototype
was extremely important to verify the basic operation of our power network in order to design our PCB. Next steps will be to implement the communication between coulomb counter and ESP32
to verify if we can retrieve battery charge data.
Prototyped reset circuit in the breadboard using schematic from ECE477 Lecture Week 6 PowerPoint. Used a 10kOhms resistor and a 0.1uF capacitor.
The EN pin in ESP32 is pulled up by the resistor and the pushbutton drives it low when pressed, reseting the microcontroller. This is fundamental
for programming microcomtroller, as it allows to revert to a known state.
Attempted to modify the MAX30101 settings to use the green LED for data collection instead of the IR LED. The green LED is often preferred for heart rate monitoring
due to better absorption by red blood cells, which should theoretically provide a stronger signal. Updated the sensor configuration by setting the LED mode to multi-LED operation
and enabling only the green LED while disabling the IR and red LEDs.
Code Changes Made:
Enabled Green LED Mode:
Set register 0x09 to 0x07 (multi-LED mode).
Disabled IR (0x0D = 0x00) and red (0x0C = 0x00) LEDs.
Set green LED pulse amplitude to max (0x0E = 0xFF).
Configured FIFO for Green LED Readings:
Enabled only SLOT1 for green LED (0x11 = 0x03).
Disabled all other slots to ensure only green LED data is stored in FIFO.
Issues Encountered:
Despite the changes, the data output is inconsistent. Some readings are unexpectedly low or zero.
Comparing results with the IR LED data, the new values seems to be worse than before.
FIFO occasionally returns zero, suggesting misconfiguration or incorrect data retrieval.
Next Steps:
Investigate if FIFO is correctly configured to store only green LED readings.
Experiment with different pulse amplitudes to improve signal strength.
Verify if ADC settings need adjustments for green LED detection.
Cross-check documentation for additional setup requirements.
If issues persist, I may revert to IR readings or explore alternative LED configurations.
Date: February 19, 2025 Start Time: 11:30 am Duration: 5 hours
Developed an algorithm to process raw data from the MAX30101 sensor and convert it into beats per minute (BPM).
Building upon the acquisition of raw infrared (IR) readings, this step involves detecting heartbeats by identifying peaks in the IR signal
and calculating the time intervals between these peaks to determine the heart rate.
Define Constants and Buffers:
Threshold (THRESHOLD): Set to 20,000. Readings above this threshold are considered potential heartbeats.
Buffer Size (BUFFER_SIZE): Set to 100. Stores the most recent 100 IR readings to analyze the signal over time.
Data Buffers:
irBuffer[BUFFER_SIZE]: Stores the IR sensor readings.
timeStamps[BUFFER_SIZE]: Records the timestamp of each reading to calculate intervals between peaks.
Initialize Variables:
lastPeakTime: Tracks the timestamp of the last detected peak to measure the time between beats.
numBeats: Counts the number of detected beats within the buffer.
bufferIndex: Points to the current position in the buffer for incoming data.
Heartbeat Detection Function (detect_heart_rate):
Iterate through the buffer, excluding the first and last values to prevent boundary issues.
Peak Detection Criteria:
The current reading exceeds the defined THRESHOLD.
The current reading is greater than the previous and the next readings, indicating a local peak.
Time Interval Calculation:
Upon detecting a peak, record the current time (esp_timer_get_time() from esp_timer.h).
Calculate the time difference (timeDiff) between the current peak and the last detected peak.
If timeDiff is greater than 300 milliseconds, record the timestamp, increment numBeats, and update lastPeakTime.
BPM Calculation Function (calculate_bpm):
Ensure that at least two beats have been detected before calculating BPM.
Compute the total time between the first and last detected beats.
Divide the total time by the number of intervals (numBeats - 1).
Convert the average interval (in milliseconds) to BPM using: BPM = 60000 / avgTimeBetweenBeats.
This algorithm provides a method to determine heart rate from the MAX30101 sensor's raw IR readings. Since the raw data is PPG data, it has no valuable
information to users unless processed, which shows the importance of this algorithm succeeding. Next steps include testing the algorithm with real-time
sensor data and optimizing peak detection parameters for accuracy.
References:
Photoplethysmography (PPG) Principles: Understanding PPG is essential for heart rate detection. (INSTRUCTABLES)
Heart Rate Calculation Methods: Algorithm approach aligns with methodologies from Texas Instruments' application note. (TI.COM)
Algorithm Implementation Examples: Practical insights into threshold setting and peak detection. (RENESAS)
Successfully read some raw sensor data (using its IR LED) from the MAX30101 FIFO Buffer. To do this,
I first set up the I2C communication and configured the ESP32 to communicate with the sensor. Then, I
initialized the MAX30101 by setting it to heart rate mode, enabling FIFO storage, and configuring the IR LED settings.
After ensuring that the sensor was properly set up, I checked the interrupt status register, which indicated that new data was
available in the FIFO buffer. I proceeded to read the 3-byte FIFO values, combined them into a 24-bit value representing raw IR LED readings,
and printed them for verification.
Code Steps:
Installed and initialized the I2C driver:
Used i2c_master_init() to configure I2C communication with the ESP32.
Defined I2C_MASTER_NUM as I2C_NUM_0 to specify the I2C peripheral to be used.
Configured SDA (I2C_MASTER_SDA_IO) and SCL (I2C_MASTER_SCL_IO) pins with pull-ups enabled.
Set I2C clock speed to I2C_MASTER_FREQ_HZ for optimal communication speed.
Configured the MAX30101 for heart rate mode:
Reset the sensor: Wrote 0x40 to register 0x09 to reset the sensor before configuration.
Enabled Heart Rate mode: Wrote 0x02 to register 0x09 to activate IR LED-only mode.
Set FIFO configuration: Wrote 0x0F to register 0x08 to allow storage of up to 16 samples in FIFO.
Configured ADC and sampling rate: Wrote 0x27 to register 0x0A to set 18-bit resolution and 100 Hz sampling rate.
Set IR LED pulse amplitude: Wrote 0x24 to register 0x0C to provide moderate LED brightness for heart rate detection.
Disabled Red LED: Wrote 0x00 to register 0x0D as it is not needed in heart rate mode.
Enabled FIFO Data Ready Interrupt: Wrote 0x40 to register 0x07 to trigger an interrupt when new data is available.
Checked the interrupt status register:
Read register 0x00 (Interrupt Status 1).
Verified if the 0x40 bit was set, indicating FIFO data was ready.
Read 3-byte FIFO data:
Wrote MAX30101_REG_FIFO_DATA (0x07) to select FIFO data register.
Read three consecutive bytes (FIFO high, middle, and low) into variables fifo_data_h, fifo_data_m, and fifo_data_l.
Combined them into a 24-bit value.
Even though I successfully retrieved some raw IR LED data, the data is still unprocessed and needs validation to ensure its retrieval is accurate.
The FIFO buffer is correctly storing and updating new readings, but I need to analyze the consistency of the values. Getting the sensor to return valid readings is a
critical step in processing heart rate data, and this progress establishes a strong foundation for the project as it is a functionality of the device.
The next steps involve validating the integrity of the raw data, implementing data processing algorithms to convert the raw IR LED readings into BPM, and comparing the processed values
with a reference heart rate monitor to assess accuracy. Debugging and refining this process will be essential to ensure reliable heart rate monitoring for the final implementation.
Description: This week, I finished setting up HydraWise project environment successfully, and started debugging its I2C implementation for MAX30101 sensor.
These were the debugging mechanisms that I employed to solve the communication errors encountered last time (data not being read):
Added several print statements checking the initialization and return values of every command (that has a return value) needed to complete a transaction
Verified that `i2c_master_init()` was being called before executing any I2C operations and added more debugging print statements trying to check actual values.
Updated the configuration, performed a full clean (`idf.py fullclean`), and recompiled the project.
Successfully initialized the I2C driver and confirmed sensor detection through the serial monitor (address 0x57).
Data is still not being collected, probably due to some other issue that still needs to be discoverd and debugged.
The debugging of this serial protocol implementation is very important not only for the heart rate data collection,
but also for checking battery levels, which also utilizes I2C. Getting the I2C working will advance greatly in both components of the project,
which should be the same with a few tweaks. Next steps: figure out why the heartrate data is not being read, and finish I2C implementation.
Testing HydraWise Heart Rate Implementation Microcontroller Scanning for MAX30101 Address
Succesfully flashed the i2c_tools example project (idf.py flash monitor), as well some of its commands, such as register_i2cdetect() in order to get familiarized with all the tools available.
To proceed with the entire development of HydraWise embedded software, I created a new Espressif project for HydraWise and ensured proper linking of components (included all the directories/files
in CMakeLists.txt). These were the steps to create the project:
idf.py create-project HydraWise
cd HydraWise
idf.py set-target esp32
Moved project files out of OneDrive to avoid the permission restrictions with the build tools I was having when trying to clean build directory.
Built and flashed the ESP32 and monitored the serial output for confirmation to make sure I had sucessfully set up my project for development.
Implemented I2C functions for the MAX30101 sensor but encountered communication failures, as no values are being read from the register.
It initializes the task that runs the data collection from MAX30101, it enters the function that is supposed to read status register,
but no value is coming from it.
With the project completely setup, allowing me to test the whole embedded system of HydraWise, I can
code and test simultaneously, allowing me a more efficient experience and, ultimately, be able to conclude This
part of the project. Next steps: fix the communication failures encountered with reading MAX30101 data.
Attempted to run `idf.py` to build and flash example "i2c_tools" project so I could get familiarized with the tools
I would be using to develop the firmware, but the command was not recognized in the terminal. Proceeded to
fix environment with following steps:
Deleted the existing ESP-IDF `v5.4` repository from VS Code installation to remove conflicts.
Manually cloned the ESP-IDF repository from Espressif’s GitHub (git clone -b v5.4 --recursive https://github.com/espressif/esp-idf.git esp-idf-v5.4)
Discovered that the ESP-IDF environment variables were not properly configured, and the system defaulted to MSYS2’s Python.
Included ESP-IDF python path in environment variables with higher priority than MSYS2's and verified that ESP-IDF’s Python environment was being used.
Ran `install.bat` and `export.bat` to properly configure the environment.
Successfully verified `idf.py` execution and project initialization, confirming that the development environment was fully operational.
This allows me to proceed with the testing and integration of the sensors with ESP32 (at the moment focusing on MAX30101). Next steps include
creating and setting up a project in Espressif for HydraWise so that I can start testing my written functions and develop firmware for the product.
Description: Finished working on initial MAX30101 I2C implementation and encountered issues with the Espressif VS Code IDE setup, specifically errors with idf.py. Attempted debugging and environment configuration to ensure proper project setup.
Date: February 7th Start Time: 10:00am Duration: 2hrs
I attempted to run the program in the Espressif VS Code IDE to flash firmware to the ESP32 but ran into issues when running
idf.py commands. The error message idf.py: command not found prevented further progress.
I attempted to source the environment using install.bat so I could use export.bat, but the command failed when
trying to upgrade pip and setup tools. I am now looking into alternative ways to configure the environment or verify
if the VS Code extension is properly set up. The next steps involve debugging the environment setup, ensuring Python dependencies
are installed, and checking system PATH configurations to identify the root cause of the issue. It is important to fix this issue
so I can proceed with the testing of all embedded software.
Date: February 5th Start Time: 12:30pm Duration: 2hrs
I worked on developing the max30101_task() function, which continuously monitors the MAX30101 sensor for new FIFO
data and prints the raw values when available. This function runs as a FreeRTOS task and periodically reads the
interrupt status register to check for new data availability. If new data is ready, the function reads the FIFO
buffer and prints the retrieved values to the serial monitor. It still has to be tested because of my unfamiliarity
with the microcontroller type and IDE.
This implementation ensures continuous data acquisition, which is crucial for real-time monitoring in our project.
The next steps involve flashing the firmware, analyzing the results, and optimizing task execution to minimize
potential delays or inefficiencies. Further debugging and improvements may be necessary based on initial test results.
Date: February 3rd Start Time: 1:30pm Duration: 4hrs
Today, I continued working on implementing the I2C communication functions for the MAX30101 sensor on the ESP32 using the ESP-IDF
framework in C. I finished the i2c_master_init() function to configure the I2C master interface with project approapriate values,
ensuring proper GPIO assignments and clock settings (100kHz for now - standard mode I2C).
Created an I2C command handle using i2c_cmd_link_create() to queue commands before sending them.
Sent the MAX30101 device address with a write bit to specify the register address for reading.
Introduced a small delay using vTaskDelay(30ms) to ensure sensor readiness.
Started a new I2C transaction, sent the MAX30101 address with a read bit, and retrieved the register value.
Then I also implemented max30101_read_fifo() to retrieve 3-byte FIFO data representing sensor readings with these steps:
Wrote the FIFO register address first to tell the sensor where to start reading.
Introduced another vTaskDelay(30ms) for stable communication.
Read three bytes (MSB, Middle, LSB) using i2c_master_read_byte()
The implementation follows the MAX30101 datasheet to ensure proper I2C sequence and acknowledge handling.
The code has not been tested yet as I still need to learn how to use the Espressif IDE to create projects and test on the ESP32 microcontroller.
Next steps include setting up the development environment, flashing the firmware, and verifying I2C communication using debug tools.
This implementation is critical for integrating the MAX30101 with the ESP32, allowing us to collect heart rate data.
Next steps include finishing the basic functions and then verifying I2C communication using a logic analyzer or debug prints,
and running test to check for proper register responses. Additionally, I plan to implement error handling for potential I2C failures.
Espressif C Code for Reading a Register via I2C Espressif C Code for Reading 3bytes of MAX30101 Fifo Buffer via I2C
Description: In Week 2, the focus was on setting up ESP32 development, building circuit, and starting embedded software development for heart rate sensor integration. Also, worked on A2 and did A3 (individual).
Date: January 31th Start Time: 9:30pm Duration: 6 hours
Finished setting up Espressif IDF on my PC via VS Code (https://github.com/espressif/vscode-esp-idf-extension/blob/master/README.md).
Using Espressif IDF and C, started to code the embedded software that integrates sensor and microcontroller via I2C communication (refer back to entry 1 for sources used to
aid development). This will be fundamental to achieve the device's functionality of collecting heart rate data for both the prototype
and the actual final design product. Next steps are finishing the program and testing with the circuit built earlier in the week.
Continuing A3. Refer back to assignment and previous entry for more info.
Beginning of ESP32 Program to read Heart Rate via I2C (untested)
Date: January 29th Start Time: 1:20pm Duration: 3 hours
Build the circuit integrating ESP32 WROOM microcontroller with heart rate sensor by getting a
microcontroller, sensor, and breadboard with GTA, and physically wiring the circuit (Figure).
This is fundamental not only for prototyping the device and testing the embedded software, but also
to assure our PCB will work.
Started working on Assignment 3: Software Overview. Extensive research on our Software implementation,
including data structures we will be using during the implementation, including how the data is being transmitted
(sensor -> microcontroller -> app). This will be fundamental to start developing the software in both ends (embedded and app),
as its high level approach facilitates integration. Check Assignment for research, sources, diagrams, and more.
Next steps is to continue research and finish assignment.
Date: January 25th Start Time: 9:00am Duration: 8 hours
Worked on Assignment 2. Conducted several research on how to integrate our sensors with ESP32 microcontroller,
in addition to possible sensor types (heartrate monitor and electrochemical). Made high level block diagrams.
Concluded at the decision to use I2C (heartrate) and ADC (hydration) to achieve the wearable device's functionality.
Description: In Week 2, the focus was on learning PCB design, researching ESP32 microcontroller integration with sensors, and evaluating electrochemical sensors for sweat electrolyte measurement.
Date: January 23st Start Time: 1:15pm Duration: 3.25 hours
Initiated my research on electrochemical sensors that could measure the electrolyte levels and concentrations via sweat
in order to find the best part/component to add to our wearable device. The research main results are listed below.
Common Types of Electrochemical Sensors
Potentiometric Sensors
Measure the ion concentration using ion-selective electrodes (ISEs)
Suitable for detecting sodium (Na⁺), potassium (K⁺), or chloride (Cl⁻)
Amperometric Sensors
Detect changes in current proportional to the ion concentration.
Common for detecting chloride and lactate in sweat
Conductometric Sensors
Measure changes in electrical conductivity in sweat, indirectly inferring electrolyte concentration
Impedimetric Sensors
Utilize impedance changes to detect ionic activity.
Commercially Available Electrochemical Sensors
Ion-Selective Electrodes (ISEs)
Example: Sodium-selective electrodes (e.g., from Vernier, Metrohm, NT Sensors).
Applications: Direct ion measurement in sweat samples.
Drawback: High Costs and relatively large size: around $200 and 50mm respectively as seen in picture below (sensor from NT Sensors)
Lactate and pH Sensors
Lactate sensors are commonly used to monitor sweat for fatigue or hydration
Example: Ph sensors from NT Sensors
Drawback: High Costs and relatively large size
Customizable Electrochemical Sensor Kits
OpenBCI or DIY kits: Platforms like those from SparkFun or Adafruit can be used for custom sensor development.
Conclusion: Using ion specific ISEs seems, at this moment, to not be viable due to its high costs (half the budget each) and its nearly 2 inches size, which seems very big even
though we are being lenient with size in this prototype
Next Steps: Find the right sensor/component that fits the project, order it, and start learning more about the sensor and how it can be integrated with microcontroller.
Do further research on the other types of sensors listed above.
Date: January 22th Start Time: 12:30pm Duration: 3 hours
Started to learn the specifications and documentations of ESP32 microcontroller (https://www.theengineeringprojects.com/2020/12/esp32-pinout-datasheet-features-applications.html), which was chosen by the group partially due to its Bluetooth capabilities, and
began brainstorming ways for the sensors to be integrated - microcontroller pinout is below (retrieved from the same source above)
As far as I have seen, the ESP32 can be integrated with a digital heart rate monitor sensor with onboard preprocessing, such as the one mentioned in class by Prof. Walter,
via its I2C or SPI interface. These sensors output processed data, including heart rate and blood oxygen levels (maybe?), eliminating the need for extensive signal processing on the ESP32.
Simultaneously, the ESP32 can interface with ion-selective electrodes (ISEs) for monitoring electrolytes like sodium, potassium, and chloride in sweat by reading their analog signals through its ADC
pins. With its built-in Bluetooth or Wi-Fi capabilities, the ESP32 can transmit both heart rate and electrolyte data in real time to smartphones or cloud-based platforms, making it an efficient solution
for wearable devices like ours. Learning how to setup these interfaces integrating microcontroller and sensors is how we can achieve
most of our hardware PSDRs.
Next Steps: Do a deeper research on the specific ESP32 microcontroller type we select (also check with TA which ones we have available already)
and further develop the interface/integration plan.
Date: January 20th Start Time: 10:00am Duration: 2.5 hours
Started to learn the inner workings of PCB design using KiCad via online tutorials, such as the DigiKey video series https://www.youtube.com/watch?v=vaCVh2SAZY4 and
the Sparkfun tutorial https://learn.sparkfun.com/tutorials/beginners-guide-to-kicad/all. With these resources,
I learned the overall/basic process involved in designing a PCB, including how to create a symbol and footprint, capture an schematic,
generate netlist, define the outline, board layout, among other steps. Learning this fundamentals was imperative not onlt because of my interest, but also
due to the fact that only Matthew (Electrical Lead) had prior experience with PCB in the group and I will most likely be the 2nd person in the task.
I believe that continuing this learning process will be helpful in the near future when we start the actual design.
Date: January 17th Start Time: 1:00pm Duration: 3 hours
Team meeting for completion of A1 and consequently more discussion on how to accomplish engineering design requirements. Helped elaborate PSDRs
and write functional description, as well as team role and responsabilities.
Named Systems Lead, which as a result I have taken upon myself to be heavily involved on both side of the project (Hardware and Software)
for a better overview of the entire system and all its components. More research on ESP32 microcontroller and PCB design is needed.
Reports assigned to me: Software Overview and Legal Analysis. Will need to plan meeting with Software Lead within next two weeks
to discuss the high level software design, as well as the specifics (programming language, tool, etc.).
Date: January 15th Start Time: 4:30pm Duration: 2.5 hours
Filled out all general team information on the website (project name, functional description, PSDRs, contact info, and team members name, role, and emails)
by writing text and "pointing" site to the correct images and documents files approapriately.
Added the personal image and description for every teammate except Matthew Dailey to website, like it is seen on the image below. In order to do so,
I had to study the website directory structure, as well as the files and its contents. As a result, paired with independent research in HTML to
better understand the setup, I have harnessed an adequate knowledge on HTML language - syntax, structure, etc. - that I did not have before. website
will need to be weekly updated.
Above item was revisited during the week (Saturday) in order to update information, such as functional description and PSDRs, and add others,
such as link A1 document.
Had technical issues with website (not updating or taking too long to update) which delayed progress. After troubleshooting online
(Reddit/Stackoverflow), figured out that I needed to clear the cache on my browser.
Date: January 15th Start Time: 12:30pm Duration: 2.5 hours
Went on lab tour with Prof. Walter in which I learned all the resources available in lab as well
as all outside resources, including Knowledge Lab, which after further research, it is clear it will
be instrumental for achieving the wearable portion of our product/design - integrating the packaging
with the wristband in a way the sensors (hear rate and electrolytes) are still in a position to perform properly
(in contact with skin and sweat, respectively). This resource will be fundamental towards the end of the project -
assemblying final "version" (commercial prototype) of project.
Met with TAs for a initial discussion on project proposal, including overall functionalities, directions the project
will take, possible components used to start evaluating what parts are needed and the next steps of the project. more
research on sensors, specially electrochemical sensors (to measure electrolytes) is needed.
Got the team website live on ECE 477 servers by copying template contents into web folder so that the Team
could eventually upload their information (eg: documents and journals) and the course faculty could easily access.
Having the site properly running is important since it is the main place for project related documents, reports, etc.
that can be used for further consultation by teammates or others. Team specific information still needs to be filled in on website.
