Project Journal for Pat Patterson

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

Entry 2: Setting up rasberry pi in lab

Date: April 18th
Start Time: 1:00 pm
Cumulative hours: 73.5

Duration: 1 hours


In this entry I just focused on getting the rasberry pi setup on the local network on a router we had in lab. It should havbe been as easy as plug and play but the rasberry pi for some reason would nt let me connect even though the server was running accroding to terminal. To fix this I just cleared the memory on the rasberry pi and installed it all from scratch and then it worked. All the steps to do so are listed in the previous journal entry. Here is a pic of the basic website in its current state.

The result of this is a functioning website we now need to develop to communicate with the esp32. This is huge progress since the only two things we have left are packagin and the user gui. Next step will be interfacing the esp32 with the rasberry pi.

Entry 1: Setting up Rasberry pi

Date: April 17th
Start Time: 12:00 pm
Duration: 2.5 hours


Our project has been coming along very well and we have three checkoffs already. The main focus for this entry was to get the rasberry pi setup. We need to be able to host a web server that the esp32 can communicate with to store data and allow the user to acess the inforamation and also modify parameters such as the lights and threshold sensors. I found the video below and followed it step by step.
https://www.youtube.com/watch?v=14j_N7ub9UM&t=459s
The first thing to do was install rasbian os on the rasberry pi to do this I used the rasberry pi imager. This is the link to download it below
https://www.raspberrypi.com/software/
This is very straight forward you connect the microsd card to your computer and click flash. The next thing I did was install apache which is a web server. To do this I opened terminal and ran sudo apt update then sudo apt-get inbstall php -y. Next I installed php running sudo apot-get install apache2 -y. Next I installed the database and wordpress following the steps in the tutorial. One change that has to be made is step 6 in the video they have you set a static ip using a dhcpcd.conf file. This is an older video and this step no longer woirks since rasberry os now uses network manager to configure this. So instead of doing step 6 you run the command
nmcli connection modify "YOUR-CONNECTION-NAME" ipv4.addresses YOUR-IP-ADDRESS ipv4.gateway YOUR-GATEWAY ipv4.dns YOUR-DNS ipv4.method manual
I then did step 7 which was the final setup set for the website and at this point I had a working web server I could acess from a computer on the same network as the rasberry pi. Next step was making it acessible from any device anywhere. To do this I continued following the steps in the video and got all the way to the point where I had to forward the port on my network to the rasberry pi. I was able to do this through the app and it said it was succesfful but when I went on port checker it would say it was closed. I then tried doing it again and switching different ports and different devices but nothing seemed to work. I then deciided to google my network provider and quickly found out that metronet blocks all port forward requests coming into a network on their residential plans. So then I took the rasberry pi to brandons home network and tried to port forward on his since they use xfinity and had the same isssue so at that point I scrapped the idea and decided to just use a router in lab and make it so the devices had to be on the same network for demo purposes which is want I will work on tomorow.
I did all the setup steps in the rasberry pi terminal and to port forward I was using my routers provided app on my cell phone. The result was a some what working rasberry pi web server, and I learned that network providers are very annoying here when you dont have a business plan. This contributes since it is one of the final things we need working to complete out project. The next steps are going to be setting the server up locally in the lab.

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

Entry 3: continuing spi cam

Date: April 9th
Start Time: 10:15 am
Cumulative hours: 70

Duration: 2 hours


Since the code from yesterday appears to be capturing an image and trying to send it over uart to com5. Im now trying to read it using a python script I wrote.

This was giving me an issue where it would try and read data and was just receiving two numbers back and forth which didn’t make sense until I realized its from the print statements. So after removing all the print statements I was not receiving any data from the camera. So now I learned the issue was with the micro code so I went back to it and modified the send part of the code. To try and make it simpler but slower I made the esp32 send 1 byte of data at a time instead of using a buffer this appears to work and now the python script was getting data. the code that worked can be seen below.

Here is a picture of the data being recieved it wont convert to jpeg so that will be the next thing I have to figure out on why the data isnt correct.

I did all this code in vs code and pycharm with chatgpt and google for help. The result of this work was that I now had running code that appeared to be sending picture data to the computer. This contributes because this is one of the last functions we need to get working and I now made more progress. Next thing I'm going to do is work on getting the data to be converted to an image thats openable.

Entry 2: spi cam

Date: April 8th
Start Time: 3:45pm
Duration: 2 hours


Since yesterday did not work I decided to create a new project to start from scratch.

I used the hello world example so I could quickly confirm its functionality and make sure the esp32 was working.

I then tried to import the spi library and it gave the erro below and I fixed it by making my cmake identical to what you see below I got this code from another code file I used on the i2c protocol.

Copied all code from this video, this video shows how to enable a spi interface
https://www.youtube.com/watch?v=2yY_ifE8jQw
Needs to modify because of errors original

new

This is the working code it sends the string Hi I am from esp32 to camera, obviously I don’t get a response but at least it compiles and builds
I then used chatgpt to help code the this next function I gave it my already working spi code and prompted it to modify it to take a picture of a arducam spi camera this was the resulting code









As you can see I left the code from the video still in it but just commented it out. This code was hanging at the line you can see below I figured this out by addding a bunch of print statements.

As far as I know 0x04 is the address that says the camera has completed the picture I added this print statement to make sure the camera was working since it had a more unique default value of 0x05 and now the code is running


I believe this print statment for some reason wakes the camera and now the code was running. I did all this code in vs code with chatgpt and google for help. The result of this work was that I now had running code that appeared to be working and making the camera take a picture. This contributes because this is one of the last functions we need to get working and I now made substantial progress. Next thing I m going to do is work on getting the photo from the camera to the esp32 and then to the computer.

Entry 1: Develop code for spi camera

Date: April 7th
Start Time: 2:15 pm
Duration: 2 hours


First I watched this youtube video
https://www.youtube.com/watch?v=c9zIyfd-UbI
It wasnt very useful since it just walked through how to get the camera working in arduino with librarys the manufacture provided. But it did have links to useful websites that expalined how the camera functioned so i read through all three. One was pinouts he other was how to communicate with the camera, and the other was the same tutorial as the video for getting the camera to work in arduino. The order I list them below is most important to least important.
https://iotprojectsideas.com/interfacing-arducam-5mp-spi-camera-with-esp8266/
https://iotprojectsideas.com/arducam-mega-5mp-spi-camera-with-arduino/#pinouts
https://iotprojectsideas.com/arducam-mega-5mp-spi-camera-with-esp32-wifi-module/
I then connected the camera to the esp32 following our schematic and the pinout diagram in the second link. I then went to arducams github and found an example code that was supposed to make the camera work in espidf.

So after downloading the exaple I tried to run it. When using the buttons in vs code to build and monitor I was getting an error saying that the example did not have a ninja.build file. I asked chatgpt what this meant and ninja is as similar tool to cmake that esp uses to build project. I was able to get this to work without a ninja file by building directly through terminal with the command idf.py build. I found this workaround on this website from esp32
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/get-started/windows-setup.html#get-started-windows-first-steps
Initially I was still getting a build error since the project was in downloads which was a network drive so i moved it to to documents and the error went away. Next error I got was uart and spi not working properly So I referenced them directly using a full path as can be seen below

Next error I received was a simple one one of the names for a variable must have changed so I changed it to the suggested fix

Then I got this large build error.
Merged 2 ELF sections Successfully created esp32 image. Generated C:/Users/patte214/Documents/Arducam_Mega-main/examples/ESP-IDF/ESP32-S/build/bootloader/bootloader.bin [109/110] C:\WINDOWS\system32\cmd.exe /C "cd /D C:\Users\patte214\Documents\Arducam_Mega-main\examples\ESP-IDF\ESP32-S\build\bootloader\esp-idf\esptool_py && C:\Users\patte214\.espressif\python_env\idf5.4_py3.11_env\Scripts\python.exe C:/Users/patte214/esp/v5.4/esp-idf/components/partition_table/check_sizes.py --offset 0x8000 bootloader 0x1000 C:/Users/patte214/Documents/Arducam_Mega-main/examples/ESP-IDF/ESP32-S/build/bootloader/bootloader.bin" Bootloader binary size 0x6560 bytes. 0xaa0 bytes (9%) free. ninja: build stopped: subcommand failed. * The terminal process "C:\Users\patte214\.espressif\tools\ninja\1.12.1\ninja.EXE" terminated with exit code: 1
Build now completes but isn’t uploading with this error. I put this into chat gpt and it said to try and change flash config. I did this by running idf.py menuconfig Navigate to Serial flasher config > Flash size and chooeing 8mb from 2mb. I got the same error so i tried manually creating partition tables and this still didnt fix it at that point I scrapped the example project and decided I would code it from scratch tomorrow. I did all this code in vs code with chatgpt and google for help. The result of this work was realizing I should just code it from scratch. This contributes because this is one of the last functions we need to get working. Next thing I m going to do is work on coding it from scratch tomorrow.

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

Entry 4: Presentation Review

Date: April 3rd
Start Time: 5:30 pm
Cumulative hours: 64

Duration: 1 hours


As a last resort after many failed things I decided to just pull the calls to i2c from the functions I had them in to the spot where the data was going to be used and all of a sudden it works and im not getting a buffer error anymore and data is being read. Now I have to figure out how to interpret the 4 bytes of data. working code.

Next I had to figure out a way to take the raw data and convert it to a meaningful tempperature reading. I wrote the code below to do this

This should have converted the temps but was giving me -40 everytime I realized the interger division was causing this so I just had to cast everything to a float and now it worked. Below is correct code and the output.



I now just had to copy the temp code and make a few minor tweaks to do the same thing for humidity. I had one issue which was the humidity and int raw values were signed they need to be unsigned or you can get some weird behavior with random negatives. Heres the cleaned up code

Entry 3: Continuing i2c code

Date: April 2
Start Time: 11:30pm
Duration: 2.5 hours


Tos start I tried to understand how the device worked better. So I rewatched the video from texas instruments
https://www.youtube.com/watch?v=syiS0rs9lkE
I then found I was really confused by this chunck of pseudo code

I thought it was writing each byte individually to the ox40 register. This was wrong ti wants to write to the device 0x40 a 0x02 byte + 0x90 byte + 0x00 byte all at once. This will write to the 0x02 register a 0x90 + 0x00 16 bit sequence which configures the device to read temp and humidity at the same time. I discovered this from reading the device's datasheet and reading an example of arduino code on how the wire.write function works.


The config is working Im now trying to request the measurements. The issue with this is that its not an address to read you just request the bits from the device and the original function I had required an address so I made another function.

This works because Im setting the address to null. This now gave me this error
E (8752) i2c.master: i2c_master_transmit_receive(1201): i2c transmit buffer or size invalid
I tried a bunch, but nothing worked
https://www.youtube.com/watch?v=Yf9oaoTTS_E
https://www.youtube.com/watch?v=syiS0rs9lkE
So I changed gears and now made a github so my teammates could acess the code I was working on instead of emailing this back and forth
https://github.com/CPATTERSON1234/working_doc_1.0

Entry 2: continuing i2c code dev

Date: April 1st
Start Time: 5:30 pm
Duration: 2 hours


Im still trying to get i2c to work. Im following the same tutorial as before but I did link it again.
https://www.youtube.com/watch?v=Snp6iTu1R7E
I initially skipped the scanning part since I was getting an error with a function it used, but it just started working today I dont know why . But communication wasnt working still. So I went back to the scanner and tryed to get it working since it was simpler. But I got this error assert failed: xQueueSemaphoreTake queue.c:1709 (( pxQueue )). I did some googling and found that the code below was most likely causing the issue so I changed the parameters and it worked.
original
xTaskCreatePinnedToCore(check_address_task, "scan I2C", 16384, (void*)&bus_handle, 10, &checkAddressHandle, 1);
changed
xTaskCreatePinnedToCore(check_address_task, "scan I2C", 2048, (void*)&bus_handle, 5, &checkAddressHandle, 1);
works i2c found at 0x2e Next thing I found was that one of my lines had the wrong id for the i2c so I updated that since I now knew it.
original
i2c_master_init_handle(&bus_handle, &dev_handle,0x77); // 0x77 is the address of the PMOD device
This was wrong updated to
i2c_master_init_handle(&bus_handle, &dev_handle,0x2E); // 0x2E is the address of the PMOD device
Afterwards the code would run but I got the following error
E (4432) i2c.master: I2C hardware NACK detected
E (4432) i2c.master: I2C transaction unexpected nack detected
E (4442) i2c.master: s_i2c_transaction_start(635): release pm_lock failed
E (4452) i2c.master: s_i2c_synchronous_transaction(918): I2C transaction failed
Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled.
Since this was all related to the i2c device not respoinding I started googling and found this youtbe video from texas instruments about our device. I made some of the changes from the video to my code to reflect this.
https://www.youtube.com/watch?v=syiS0rs9lkE
I also changed (github copilot)
xTaskCreatePinnedToCore(read_hydro, "read hydro", 2048, NULL, 5, &PMOD_handle, 1);
to this
xTaskCreatePinnedToCore(read_hydro, "read hydro", 4096, NULL, 10, &PMOD_handle, 1);
Still getting the same error so I commented all the code except the first line to try and isolate the problem. As seen below

This was causing the issue. After rechecking everything I discovered I had the wires off by one and the i2c device wasnt wired correctly. So I reran the scanner and found the device id to be 0x40. I then changed this were it needed to be changed and it still did not work but the current state of the code can be seen below and that is were I stopped for the night

Entry 1: esp-idf coding

Date: March 29th
Start Time: 12:15pm
Duration: 3.5 hours

So first thing I wanted to focus on was the ability to pair the esp32 to a wifi connection through a users phone since this would be necessary for setup. After doing some research I found out there is a way to do this using something called wifi provisioning. I followed the link below to complete this
https://www.youtube.com/watch?v=JYtDibqJMs0
Next I wanted to make sure I was able to blink an LED so i set one up on the board going from gpio pin 34 and used a 1k resistor. This did not work and after googling I found out pin 34 was an input pin only of course the one I choose. https://forum.arduino.cc/t/gpio-output-gpio-num-error/1092605/8
So I moved it to 35 and it still did not work, and again that was also an input only. Finally I googled a diagram of the board show all pin functionality and 33 was a normal GPIO pin so i used that and the LED worked. The code to this is below

Next I started working on the i2c temp sensor. I went through the example templates provided by express if and found an i2c one.

After trying to run it I got an error ninja: error: loading 'build.ninja': The system cannot find the file specified. I then tried a bunch of different things and none of it worked below are links to everything I tried.
https://stackoverflow.com/questions/72299754/ninja-error-loading-build-ninja-the-system-cannot-find-the-file-specified
https://ninja-build.org/manual.html#:~:text=Tarball%20Extraction-,Introduction,and%20orchestrates%20building%20them%2C%20quickly.
https://community.platformio.org/t/esp-idf-build-error-can-t-find-ninja/16066/4
https://stackoverflow.com/questions/4145232/path-to-powershell-exe-v-2-0
https://docs.espressif.com/projects/esp-idf/en/v4.2/esp32s2/api-guides/tools/idf-tools.html#ninja
https://github.com/espressif/vscode-esp-idf-extension/issues/605
So then I gave up since I spent over an hour and a half trying all of this. During my research though I did find a link to a youtube video of someone implementing an i2c connection from scratch in expressif so I followed that tutorial and finally started to make progress
https://www.youtube.com/watch?v=Snp6iTu1R7E
https://www.ti.com/lit/ds/symlink/hdc1080.pdf
I also included the link to our temperature and humidity device spec sheet.

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

Entry 1: Final PCB design

Date: March 26th
Start Time: 11:00 1m
Cumulative hours: 59

Duration: 3 hours

My goal for this session was to get the PCB fully revised so we could order it. So I started with the feedback from the proffesors email and just started going through it. First I widened all the ground traces to match the thickness of the power traces. I dont know how we missed this but whatever. I could not find a way to this automated so i just clicked every single one and made them .6mm. Next I added a large resistor between shielded ground and regular ground on the schematic and PCB, as you can see below. This apparently helps isolate the data lines. I did not know how much current would go through this so I just put the largest resistor possible.

Next I made the 0 ohm resistors by the led plug larger to be able to support the current going through them. As seen below

Next I moved the c2 decoupling cap closer to the 3.3V pad on the LDO this was to make sure it would be able to do its job.

Next I moved c8 and c9 closer to the pins and moved r4 further away. Again allowing them to properly decouple.

Next I fixed the orientation of our programming leds. These leds allow for us to see when data is being transfered to the micro, but I read the datasheet wrong and had them backwards. The pins on the chip are gnd and power has to be supplied externally so I fixed that.

Next I tried to make the usb lines the same length and added the same amount of vias to each one. Even though are chip will be programmed over uart the usb side befor conversion is still high speed so this should help with any potential timing issues.

Next I brought tx and rx from the micro directly to a header for programming just in case our circuitry doesnt work. This will allow us to bypass everything so we can program directly just in case.

Finally the last modification for the main PCB was that I enlarged all of the vias so they could be fly wired if necessary. I also went through and made sure I didnt see any acute angles. below are two images the after and before of all these modifications.



Now onto the breakout board this board was much simpler but still had some issues that needed fixed. First it had no esd protection so this was added to both the schematic and PCB. Also it needed mounting holes added to the schematic and PCB.As you can see belolw is the updated schematic

Next I placed the diodes and mounting holes on the PCB to do so I had to extend the edges and place the mounting holes on all 4 corners then I placed the diodes along the top of the board since there was plenty of room. Next I had to completely rerun all the traces to be able to connect to the diodes. Since there is a spi connection on the board I put a layer of copper on the top to help isolate. Finally I added a gnd plane to the entire back. The before and after can be seen below

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

Entry 1: Presentation Review

Date: March 14th
Start Time: 1:30 pm
Cumulative hours: 56

Duration: 1 hours

My team worked a lot on updating the pcb this week to reflect some of the feedback we received. They asked me to look over and change anything that I might think needs fixed. The only issues I noticed was the esd protection my teammates added was incorrctly placed. They added diodes just on the signal wires this would have been an issue since alot of the signal wires are two way and need to be able to send current both ways. So I deleted all of the diodes and then added TVS diodes which are specifically designed for esd protection to every signal wire a user would be interacting with and gnd. This prevents momentary high voltage zaps from an individual from causing damade to the PCB. I then verified the footprints and added these to the PCB and ran the traces for them this can be seen in the images below.

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

Entry 4: Presentation Review

Date: March 5th
Start Time: 11:00 am
Cumulative hours: 55

Duration: 2 hours

As A team we did 2 timed run-throughs of our design review before our presentation at 1:30. The main thing I focused on understanding exactly what I was going to talk about, specifically I was assigned the schematic slides since I did a lot of the work on it. The slides can be referenced on our website and I observed I ended up changing the order I was presenting the subsystems of the schematic so they would flow better and would lead into each other. This Change is reflected in the slides order. During the timed presentations my section ended up right around 18 minutes which was perfect to make our overall presentation 42 minutes. This practice allowed myself to enter the presentation with confidence and understanding of what I was going to say.

Entry 3: Finishing up PCB for presentation

Date: March 4th
Start Time: 4:00pm
Duration: 4 hours


Starting work on finishing the pcb. This first image is as far as I have done so now I need to connect everything else. As you can see pretty much nothing is done So i have alot to do.
To start I connected the programming and manual reset switches to the esp32 and usb to uart chip. This was alot of just running wires and then making small tweaks until it was all connected with minimal wires crossing each other and keeping power and ground away from each other.
Next I moved over to the 8 pin connectors that are used for the camera and temp sensors. 7 of the 8 pins are shared among two connectors because of this it was hard to run all the wires without having 2 many crosses. Also their is a decoupling capacitor that needs to be close to the ground and power pins on each connector to prevent noise from coming onto the board. My initial design had a lot of crossing and was very hard to follow the wires. I then printed out the pcb so I could manually draw on teh diagram to try and find a better way to route them. After doing so I went back to kicad and made the changes and came up with the final version below.
Next was the led strip plug this has 4 0 ohm resistors 2 for power and ground to the main usbc connector and then 2 more for power and ground for the backup usbc. This is if the LED strip pulls to much power for the 1 plug we can split the power across 2 plugs. this was very simple to run to main power and gnd since its all over the board, the 2nd power and ground though was much harder and had to go to the front and back of the board multiple times to get the power and ground to the connector.
Now I started warking on the debug header and debug leds. Their are 3 leds connected to leftover gpio pins and gnd this is so you can test code very easily by just turning on lights. Thers also a 1k ohm resistor to have a small current draw. Next I just wired the debug header directly to the esp32. While designing the schematic I made sure none of the traces would have to cross to connect to the esp32 gpio pins.
Then I moved over to the backup power connector this was pretty much just copied from the main power connector without the programming pins. Both CC lines have to go to ground to tell the usb device we want power.
All this work was done in kicad, and we now can present this pcb at our design review. The next thing we will need to do is implement any feedback we recieve during the desing review into the pcb to have a finished prototype ready to order. I have attached an image of the whole pcb it its current state before the design review.

Entry 2: making presentation

Date: March 3rd
Start Time: 5:30 pm
Duration: 1.75 hours


For this entry I focused on getting our presentation to a point where only minor changes needed to be made. Alot was already done by my teammates but their was some mistakes. Primarily in the parts slides, some of the info was out of date such as the exact model of microcontroller we were going with, since we changed it to the one with an external antennae. also what LEDs we were going with.This was pretty minor so I updated those with the correct part numbers and information. Next I focused on the order I felt it should have gone from most important parts to least so I moved the slides around to reflect this, and also moved the pictures on the transistion slides to reflect this so the speaker would be able to know what was coming next without having to memorize the order this was to help with flow of the presentation. Next I Went to the packaging design slides these were pretty filled out by brandon the only thing he was missing was the 3d view of the pcb, so I made a slide for it but was unable to upload the image since we were still working on the pcb. Next was my section of slides for the electrical schematic. Since this is what I was going to be talking about nothing was done yet for these slides. So the first thing I did was get an imaghe of the schematic and add color boxes around each sub assembly for the overall circuit. THis was going to be my transistion slide. Then I added a list of text nameing each color box so the audience could understand what I was referring to during the presentation. I played with the order a bit to try and reflect how complicated the circuit was but also how important it is since most audience members attention would fade as the more I talked. The order I ended on can be seen in the presentation which is linked below. I then went through each sub system slide and added preliminary notes on what I wanted to talk about to make sure nothing was missed. I know these will change slightly after saying things out loud and preacticing but for preliiminary notes it was fine. Next was the PCB slides which I was unable to fill out since the PCB was not finished yet. So I moved onto prototyping which was already done except for the camera. All of this work was done in a shared power point of the preovided template. This got us mostly ready for our presentation. Next we need to practice the presentation to make sure everything flows well and catch a minor issues that we might have.
https://engineering.purdue.edu/477grp21/Files/docs/Midterm%20Design%20Review%20Presentation%20Grp21.pptx

Entry 1: pcb design

Date: March 1st
Start Time: 2:30pm
Duration: 1 hours

For this entry I worked on the amin pcb design to start I worked on running the wires for the main usbc to uart connections and the power cleaning circuit. First I connected all the pins on the J1 chip to its partner pin since the connectors can be flipped over s otheres two of every pin. this was b7 to a7. b6 to a6. a4 to b4 and b9 to a9 for power. a1 to b1 and a 12 to b12 and those to all the s1 components that way all grounds are connected. next i connected the cc lines to the pull down resistors that way according to the uisb protocol this device will be recieving power not giving power. to connect these I had to run some wwire s acoross the back of the board and use vias. Next I connected the daata lines to the usb protection device again these lines had to cross so I used vias to do so. This was pin A7 to 3 on the u2 device and pin a6 to the pin 4 on the u2 device. Dinally i connected power to the ferite bead and the nto the fuse and then to the usb protection device. Next I focused on runnning the usb - uart device. So first I spent some time trying to place the components in such a way were theuir would be minimal wire crossings and ease of runnnings. First I connected all of the capacitors that are required forsignal smoothing next I connected the 4.7k resistor for reset to the 3v power on the chip . then I connected the leds to their respective pins and to ground this is so we can see when data is being transfered. Then I moved onto the reset circuitry and the data pins. Each data pin requires a2 2 ohm resistor which was quite easy to run and then the pins for thereset had to be run to the Q1 chip o nour schematic thince was a little more complicated since it had to cross the data lines but I ran it on the back using vias.

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

Entry 4: pcb design

Date: February 21th
Start Time: 11pm
Cumulative hours: 46.25

Duration: 2 hours

My teammate Brandon finished making our breakout board PCB, so first, I went in to verify its design and see if there were any issues I would notice. Overall, it looked very good. The only issue was that one of the wires ran over the pad for another pin (circled in yellow below), and also, the orange line I circled in orange was just a little too close to the pad and could possibly be covered by the connector. To fix this, I added two vias to run one wire under the other instead of around it and also moved the other line a little farther out. Next, Brandon got all the footprints handled on our main board, so I took some time playing around with the placement of important parts to hopefully make running the wires easier. I haven't gotten to the point where I'm routing them yet, but if changes need to be made, I will handle that.

Entry 3: Finishing up schematic

Date: February 27th
Start Time: 5:30pm
Duration: 1.75 hour

I moved the 2nd sheet to its own file since it's going to be its own pcb and I was informed sheets are for breaking up large pcbs and not multiple pcbs. Next I just did a bunch of small changes to provide more functinoality since its a protype board, below is a list of all the changes and a picture of the schematic.

• added debug header with gpio pins
• added reset buttons incase trnasistor network doesnt work for programming
• added leds so data transfer can be visually seen during programming
• added debug leds directly connected to gpio pins to use for programming debugging
• added a 2nd usb c plug that can be connected to the led just in case it causes issues sinces its a high current device
• moved things around slightly for better division of circuits and easier readability

Entry 2: code development

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


For this entry, I worked on developing some of our code in ESP-IDF now that I got it working. So, I started with Bluetooth functionality. There were a lot of template codes to choose from, and I spent over an hour and a half going through these examples, trying to get them to work with my phone, which is an iPhone 16. This was especially challenging since we discovered during prototyping that Bluetooth compatibility over ESP32’s security protocols with iPhone was much more complicated and harder to get working.
After all this time, I could not get a single one to work properly, so I turned to an online tutorial (linked below) and found one that did work—I was able to connect to my phone. After following the steps exactly, I got it working, but it used 70% of our memory on the ESP32. This was a major issue since we also need Wi-Fi, which uses about 40% in Arduino IDE, meaning the two wouldn’t be able to run at once.
So, I reviewed our PSDRs and talked to the team. Since we never specifically mentioned Bluetooth, we decided to scrap the Bluetooth setup and instead use only Wi-Fi for setup. This involves a direct-connect Wi-Fi method to the phone, allowing it to provide credentials for the network. This is a common practice for most home security devices, such as Ring doorbells and cameras. The easiest method would have been QR code direct connect, but this isn’t supported by iOS, so now we have to look into alternatives to achieve the same functionality.
https://medium.com/@fatehsali517/how-to-code-bluetooth-chatbox-in-esp32-esp-idf-from-scratch-d56813e6609b

Entry 1: Switching over to esp idf instead of arduino

Date: February 26th
Start Time: 9:45am
Duration: 1.75 hours

Today, I came into the lab early to work on switching our code from Arduino IDE, which we used for prototyping, over to ESP-IDF. First, I started following a tutorial (linked below) to get it set up. After following the steps, I wasn’t able to get it working. I don’t know if this was due to my Windows setup or something else, but after doing some research, I found that installing it into VS Code was much easier and required just a few clicks of a button. So, I opened up VS Code, went under the Extensions tab, typed in "ESP-IDF," and installed it—very simple.
After installing, I opened the template blink file to confirm functionality and the ability to upload. This was just a basic starter code that would turn a GPIO pin on and off to blink an LED. I hate to admit it, but it took me an ungodly amount of time to get this to work. I tried multiple different terminal commands—nothing worked. I tried the build buttons and uploads, but nothing worked. Finally, I discovered there were small buttons added to the bottom toolbar that I hadn’t seen, and one of them would build, flash, and upload the code to the microcontroller. In the image below, the red arrow must be clicked first to make the toolbar appear, and then the blue arrow is the button.
After this, I started working on code, which I broke into another entry.
https://www.youtube.com/watch?v=h9JA7V5tHsA

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

Entry 3: software overview document

Date: February 21th
Start Time: 2pm
Cumulative hours: 37.75

Duration: 3 hours

This week, I completed the A8 document, which was my assigned individual task. This document contains all relevant links, references, and detailed information about our current software plans. By ensuring that all necessary details are documented, this resource will serve as a comprehensive reference for the team moving forward. Anyone needing information about our software implementation can refer to this document for clarity and guidance. Finalizing this document is an important step in our project’s progress, as it consolidates key software-related decisions and ensures that everyone is aligned on our development approach. With this completed, the next steps will involve using the outlined plans to begin implementation and making any necessary refinements as we test and integrate the software with our hardware components.

Entry 2: schematic revisions

Date: February 19th
Start Time: 11am
Duration: 3.5 hours


This week, I worked on several key tasks to advance our project. First, I updated the datasheets on our project website to reflect the recent changes in our sensor selection. Keeping the documentation up to date is essential for maintaining accuracy in our design and ensuring that everyone on the team is working with the most current information. Next, I soldered solid-core wires onto the LED strip. The original stranded wires made it difficult to establish a reliable connection to the breadboard, so replacing them with solid-core wires improved stability and ensured a more secure electrical connection for prototyping. Following that, I began working on the schematic design. Since we decided to place the temperature and humidity sensor alongside the camera on an external PCB, several design modifications were necessary. One significant change was consolidating the connectors—rather than using separate 4-pin and 6-pin connectors for the temperature sensor and camera, respectively, we opted for a single 8-pin connector. This simplification reduces the number of required connections and streamlines the PCB layout. Additionally, I designed a breakout board to manage decoupling capacitors and properly distribute power and data for the camera to a header, allowing for easy integration. A few other refinements included adding a second header to accommodate an additional camera if needed and incorporating a dedicated LED strip connector. Currently, the LED circuit is always receiving power and ground. Once the final LED strip arrives, we will measure its power consumption in the off state. If the standby power draw is too high, I plan to design a simple MOSFET circuit, enabling the microcontroller to control power delivery via a GPIO pin rather than relying solely on software to disable the LEDs. This approach would provide better power management and efficiency for the system. These updates contribute significantly to our project's progress by refining the schematic design, improving hardware reliability, and preparing for better power control. The next step is to finalize the schematic based on these changes and begin testing the new components once they arrive. If needed, additional adjustments will be made to optimize performance and ensure smooth integration with the rest of the system.

Entry 1: Team meeting and ordering

Date: February 18th
Start Time: 5:30pm
Duration: 2 hours

This week, our group met to assess our progress and identify the biggest challenges preventing us from moving forward efficiently. We determined that our main obstacles were related to schematic design software functionalities and the absence of key components, specifically the LED strip and the camera we planned to use. Without these, we couldn’t properly develop or test critical parts of our system. To address this, we compiled a list of all the necessary components, not only for our PCB design but also for the overall project. I used Digi-Key to research and source parts, ensuring that we selected functionally identical alternatives when some components had extended lead times. After finalizing our selections, we created a comprehensive order and documented everything in the parts procurement Excel spreadsheet. We then submitted this spreadsheet to the business office for processing. As a result, we now have all the essential components ordered, which removes a major bottleneck in our development process. One key takeaway from this experience was the importance of planning ahead when sourcing components, as availability and lead times can significantly impact the timeline. Additionally, we confirmed that the camera available in the lab did not meet our project’s needs, reinforcing the importance of thorough testing before committing to specific hardware. This step contributes significantly to our overall progress by ensuring that we have the necessary parts to move forward. The lack of a suitable camera was a major roadblock since it is crucial for one of our primary functionalities. With the new camera and components on the way, we will soon be able to continue development without further delays. The next step is to receive and test the ordered parts, particularly setting up the camera functionality as soon as it arrives. If the components arrive early next week as expected, we can proceed with integration and begin verifying system performance.
https://www.digikey.com/en/products/detail/arducam/B0400/19116509
https://www.digikey.com/en/products/detail/espressif-systems/ESP32-WROOM-32UE-N16/11613145
https://www.digikey.com/en/products/detail/sensirion-ag/SHT40-CD1B-R3/19543014
https://www.digikey.com/en/products/detail/silicon-labs/CP2104-F03-GM/2486177
https://www.digikey.com/en/products/detail/stmicroelectronics/USBLC6-2P6/1007440
https://www.digikey.com/en/products/detail/adafruit-industries-llc/3919/9658068?s=N4IgTCBcDaIAQEYCsYAcBaMB2BAGdAcgCJwAUAMgKIkDOALgE4CWADgJQgC6AvkA

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

Entry 2: raspberry pi setup and webserver

Date: February 14th
Start Time: 6pm
Cumulative hours: 28.25

Duration: 2 hours

Today, I focused on setting up the Raspberry Pi for our web server. Since the Raspberry Pi does not come with an operating system preinstalled, I first had to install Raspbian. I have done this many times before, so I completed the process from memory but also included a tutorial link for reference. The setup involved downloading Raspbian and flashing it onto a microSD card, which I then inserted into the Pi. I used Balena Etcher, which I already had installed, to complete this step. After the initial setup, I followed a guide (linked below) to configure the Raspberry Pi as a web server. The instructions were clear and straightforward. However, by default, the web server was only accessible on the local network, meaning I couldn't connect to it from an external device. To enable remote access, I had to port forward to the Raspberry Pi. This required accessing my router’s homepage, opening a port, and assigning the Pi’s IP address. After making these changes, the web server is now accessible from anywhere. The result of today’s work is a functioning web server that can be accessed remotely. This contributes to the project by providing an online interface for our system. The next step is to address potential security vulnerabilities, as this is a very basic setup. I will likely need to implement authentication measures, such as passwords or additional software, to protect the network from malicious actors.
https://thepi.io/how-to-install-raspbian-on-the-raspberry-pi/
https://www.tomshardware.com/news/raspberry-pi-web-server,40174.html

Entry 2: Initial Schematic Design

Date: February 12th
Start Time: 8am
Duration: 6.5 hours

Today, I started designing the initial schematic for our project. Since we are using an ESP32, I took advantage of KiCad’s built-in library, which already includes this component. I began by adding the ESP32 to the schematic and then focused on how we would power and interact with the device. Given that USB-C is becoming the standard, we decided to implement it in our design. After reviewing available components in KiCad, I selected a USB-C USB 2.0 receptacle due to its availability and affordability on DigiKey. To protect the data lines, I added a USBLC6 chip. Since the ESP32 is programmed over UART, I also included a USB-to-serial UART chip to facilitate communication. Power management was another critical aspect. The 5V input can be noisy and unreliable, so I incorporated a ferrite bead, a polyfuse, and a capacitor to ground for noise filtering, following the recommended design guidelines from the component datasheets. Additionally, I added a linear regulator to step the 5V down to 3.3V, ensuring compatibility with the ESP32, using parts that were readily available on DigiKey. For peripheral connections, I designed an I2C connector with the necessary pull-up resistors. This will be used for the temperature and humidity sensor. Finally, I implemented the startup and boot circuitry for the ESP32 to ensure proper functionality and programming capability. The result is a solid initial schematic that lays the foundation for our project. This contributes to our progress by providing a structured design that integrates all essential components. The next steps are to complete the schematic by adding any missing functionality and thoroughly reviewing it for correctness and functionality.

Entry 1: Website and learning kicad

Date: February 11th
Start Time: 12:00
Duration: 1 hours

Today, I focused on two main tasks: uploading reference files for all the parts to the course website and refreshing my knowledge of KiCad for schematic design. To upload the reference files, I searched for each part online, located the corresponding datasheets, and downloaded them. I then uploaded the datasheets to the course website and saved the links in our shared notes document. This process ensures that our website is becoming more complete and provides an easier way to access critical component information. For schematic design, I started reviewing KiCad since I hadn’t used it in a year. I followed a short YouTube tutorial (link attached) to re-familiarize myself with the interface, button placements, and shortcuts.The result of these efforts is that our team now has a centralized, organized way to access part datasheets, which will help with future design decisions. Additionally, my KiCad refresher prepared me to work more efficiently on schematic development.These tasks contribute to the project by improving documentation and ensuring I am ready to create accurate schematics. The next steps are to continue updating the datasheets as parts change or get added and to begin working on the schematic for our project.
https://www.youtube.com/watch?v=jTMjb-1SVHo

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

Entry 2: PSDR's, Funcional Description, Journals

Date: February 7th
Start Time: 10:30am
cumulative hours: 18.75

Duration: 2 hours

Today, I brought the fridge into the lab so we could start considering design constraints related to the physical package that will house our device. This allows us to better understand space limitations and integration challenges. The first task I focused on was updating our PDSRs (Product Design Specification Requirements) to incorporate the recommendations provided by the TAs and professors during our weekly lab meeting. One major change was removing the battery backup feature. After further brainstorming, we realized that a power outage affecting the fridge would likely also affect the entire house, meaning Wi-Fi would be unavailable even if the device remained powered. This was a critical oversight, so we decided to scrap the battery backup and instead shift the focus to designing the circuit that controls the LED strip. Another issue with the PDSRs was that our requirement for setting up the web server was too vague. I revised this section to provide more specific details on how the server would be implemented. Next, I worked on improving the functional description. The main feedback we received was that our initial description lacked sufficient detail. To address this, I started from scratch, first listing all the components we plan to incorporate, including sensors, an LED strip, a microcontroller, and a Raspberry Pi to host the web server. Then, using the flowcharts and block diagrams from last week, I went through each step of the system's operation, explaining the purpose and functionality of every part. Hopefully, this revision meets the professor’s expectations. This work contributed significantly to the project’s progress by refining our design specifications and improving our documentation. With clearer requirements and a more detailed functional description, we now have a stronger foundation for development. The next step is to review the revised documents with the team to ensure alignment and make any necessary final adjustments. Additionally, we need to begin testing individual hardware components to confirm functionality. Finally, after completing these updates, I typed out all my journal entries, including this one, and uploaded them to the project website for this week.

Entry 2: Adding bluetooth connectivity

Date: February 5th
Start Time: 12:00pm
Duration: 2 hours

Here's your revised and structured journal entry that ensures all five questions are answered clearly: I worked on implementing a way for the ESP32 to connect to Wi-Fi by allowing the user to provide network credentials. Since the microcontroller has built-in Wi-Fi and Bluetooth capabilities, Bluetooth seemed like the easiest method for initial setup. To achieve this, I researched how to use Bluetooth for two-way communication between the ESP32 and a smartphone. At this point, the ESP32 was turning on, and Andrew had written basic setup and loop functions. I found a tutorial that demonstrated how to connect an ESP32 to a phone using a two-way serial Bluetooth app, allowing data to be sent and received. This method made it simple to establish an initial connection for setup. However, I encountered an issue where the Bluetooth connection did not work with iPhones but was successful on Android devices. After researching the problem, I discovered that iPhones only support the BLE (Bluetooth Low Energy) protocol, which is different from the standard Bluetooth protocol used in my initial setup. BLE is designed for lower power consumption by reducing the frequency of device polling. The tutorial I followed did not use BLE, meaning the implementation was incompatible with iPhones. This work contributed to the project's progress by allowing direct interaction between the user and the device, rather than only viewing data through a computer connection. Now that the ESP32 can establish a basic Bluetooth connection, we are moving closer to a fully functional setup process for users. The next step is to update the code to use the BLE standard so that most phone users, including iPhone users, can connect to the device during setup. I will continue researching BLE implementation for the ESP32 and begin working on the updated communication protocol.
https://www.electronicshub.org/esp32-bluetooth-tutorial/

Entry 1: Connecting to esp32

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

I set up the ESP32 on a breadboard and started following a tutorial to get it working in the Arduino IDE. Initially, I wasn’t able to establish a connection to the board, so I had to troubleshoot the issue. First, I checked the available ports in the Arduino IDE’s built-in port selection tool, where I found two ports: COM3 and COM4. Since unplugging and replugging the ESP32 didn’t change these ports, I assumed they were assigned to my mouse and keyboard. Next, I attempted to use a UART TTL adapter from ECE 362 to connect to the board through the pins instead of the micro USB port, but this also didn’t work. I then checked Windows Device Manager and found that the ESP32 wasn’t being recognized under the hidden or other device sections. After researching on Reddit, I discovered that some USB cables only provide power without data transfer capabilities. I tested three more cables from the lab before finding one that allowed the device to be detected. Even after the ESP32 was recognized in Windows Device Manager, it still wouldn’t connect to the Arduino IDE. I then realized my computer was missing the necessary USB-to-UART drivers. After installing the drivers, the upload process still failed, but at least the device was now being recognized. Finally, I discovered that I needed to press the boot button on the ESP32 while uploading code. Although this step can be automated with an external circuit on pin 1, it was easy enough to do manually. This troubleshooting process was critical to our project’s progress because, without the microcontroller, we couldn’t move forward with any other development. Now that the ESP32 is operational, the team can work on multiple aspects simultaneously. I assigned different sensors to each team member so they could focus on getting them to communicate with the ESP32, allowing the software lead and me to begin working on the server side. The next steps are for everyone to get their assigned sensors working with the proper circuitry and ensure they communicate correctly with the ESP32. Once the sensors are functional, we will focus on connecting the ESP32 to the web server for data transmission.
https://randomnerdtutorials.com/getting-started-with-esp32/

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

Entry 2: FlowChart/state machine

Date: January 30rd
Start Time: 11:45am
cumulative hours: 10.75

Duration: 2 hours

Gustavo and I worked on creating the flowchart and state machine for the software assignment. We used Draw.io to design both diagrams. To create the state machine, we discussed all the states needed to support the desired functionality. The states we settled on for now include powering on, idle, door open, door closed, take picture, read sensors, and send data. The final diagrams can be seen in A3. This process helped us define the system’s operational states, ensuring that all necessary transitions were considered. The next step is to refine these states as we develop the software further. We also worked on the flowchart by mapping out the logic of the state machine, defining how each transition should occur and how different cases should be handled. This first draft feels incomplete and will likely change, but it serves as a solid starting point for structuring the software’s logic. The result of making these diagrams is that we now have a general outline of how the software should function, which we provided to our software lead for use in the A3 assignment. This contributes to project progress by giving the software team a clear list of functionalities to implement. The next step is for the hardware team to set up the microcontroller so that software development can begin.

Entry 1: Brainstorming/ functional diagram

Date: January 29th
Start Time: 10:00am
Duration: 4.5 hours

During this block of time, I researched and selected the microcontroller for our project. I used Google and the class slides from Week 2 to compare options and determine which microcontroller best met our requirements. The result of this research was the decision to use the ESP32, as it supports both Wi-Fi and Bluetooth, which are essential for our project. Additionally, I found clear online guides on how to connect an ESP32 to an SD card, which is necessary for storing photos. This decision allows us to begin requesting parts and planning sensor connections. The next step will be to start programming the microcontroller. Additionally, Gustavo and I worked on creating a functional block diagram to outline how all components will connect to the microcontroller. We used Draw.io to design the diagram, starting by listing all necessary components, such as cameras, temperature/humidity sensors, an LED strip, power, and a battery backup. We then researched each component on DigiKey to determine its interface and verify that the ESP32 has enough input pins for all connections. As a result, we now have a clear roadmap for how each component will integrate into the system. This contributes to project progress by ensuring we have a well-structured plan for implementation. The next step is to begin building a prototype on a breadboard.

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

Entry 2: revising pdsrs and journal entries on website

Date: January 23rd
Start Time: 11:45
cumulative hours: 4.25

Duration: 1 hours

I met with gustavo in lab to revise the pdsr's and update the website with all the information. I also modified the website template so our journal folders had the same name as our login. Then Gustavo and I both worked on adding our journals to the website.

Entry 1: Lab Time/ Brainstorming

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

This entry is for the time spent in lab. I started the group lab meeting with splitting up the A2 assignment and letting everyone know what they needed to get done this week. Then We met with the ta's and professor and got feedback on our A1 submission. The main issues were lack of detail in functional description and to broad psdrs. After this meeting as a team we talked about potential fixes and brainstormed potential problems our project would have due to its environment, and potential solutions to these problems. One of the big probelms is power and i came with the idea to use flat wire for the power cable to have ist under the door seal. \https://www.amazon.com/dp/B00WITWKNG?language=en_US

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

Entry 2: Worked on A1

Date: January 17th
Start Time: 12:22pm
cumulative hours: 1.25
Duration: .75 hours

Today I shared all the project documents with my team and and completed section 1.0 project description and section 2.0 team description for myself in the A1 assignment. I decided that google drive was the best way to share all the documents because of its ease when collaborating. The result was that some of document A1 was completed and ready for submission. The next steps is for the other people in the group to finish their assigned section and then have a meeting to go over the entire document and make sure its ready for submission.

Entry 1: Website Setup

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

In lab today I worked on getting the website up and running with basic information put in. I used the provided website setup document to mount the correct drive and copy the template over. After ding so I worked on editing the team page wit all of our information. To mount a drive I used the windows folder system. The result of doing this was a functioning website. I learned how to mount a drive in windows by doing this. This contributes to the progress of the project by giving us a central place to keep track of our progress. The next steps are filling in the rest of the sections.