Project Journal for Gavin Zyonse
=============== Week 14: =================
Entry 6: -----------------------------------------------------------------
Date:Start Time: 12:00
Duration: 2 hours
Today we presented demo of our project to Dr. Walter. The demo went fairly smoothly aside from some brief pairing issues. We were able to show off all of our features and the demo was well received.
Next week we will be working on the final report and presentation for the project. We are also registered for the Spark Challenge, so we will be working on the poster for that as well.
Entry 5: -----------------------------------------------------------------
Date: April 17thStart Time: 8:00pm
Duration: 4 hours
Today I am working on fixing our TFT display issues. Luckily Gino was able to get it to a working state, now we're just having issues with the RTOS and watchdog.
We are using the LVGL library and I think it might just be too intensive for the ESP32 to handle.
For now I've decided to disable the display update tasks and just have it show a static text screen. We can always add the display update tasks back in later if we have time, but for now I just want to get the demo working. This will get us the "interface a TFT LCD display via SPI" PSDR.
I'm now going to work on integrating the Spotify API with our mobile app to meet our other stretch PSDR. Gino worked on this a bit before and he provided me with a Spotify API key.
I was able to get the Spotify API working and I can now pull song and artist info via song ID. I'm going to implement a function to set the current color of the LED strip to the album art color.
This is a good prototype for now, later I'll implement a login system to make it more personalized. We're presenting our project tomorrow for the early submission bonus, so I think we're in a good state now.
Entry 4: -----------------------------------------------------------------
Date: April 16thStart Time: 11:00am
Duration: 3.5 hours
Today I'm once again trying to integrate the TFT display with our Matter codebase. I was able to get the display to work with Gino's code, but I'm having trouble getting it to work with our code. I've been trying for about an hour to get the display to show something other than a white screen. I ran into some memory related issues and I'm worried that we're running out of heap space. I need to check later to see how to profile the heap space on the ESP32.
I'm going to meet Gino in the lab to get him set up on the build system for the Matter codebase. That way he can help me debug the display code and we can get it working together.
That took a ridiculously long time, but I was able to get Gino set up on the build system. The project takes a long time to compile which made things take even longer. The issue we were running into with his build system was that some low level Matter functions were missing arguments. It was very confusing to troubleshoot because Gino already had ESP-IDF installed, but it was a different version than the one we were using. The problem ended up being that our ESP-Matter repository was using a different version of the Matter SDK than Gino's repository. I just ended up putting my version of ESP-Matter on a flash drive and loading it onto his laptop manually. We couldn't do that with all of the dependencies because they have specific install scripts.
Alas, Gino is now set up with the build system and he is the resident TFT display expert on our team so hopefully he can get it working.
Entry 3: -----------------------------------------------------------------
Date: April 15thStart Time: 5:30pm
Duration: 3 hours
Tonight I'm spending some time attempting to integrate the TFT display with the ESP32. Gino sent me his code for the TFT display, and I'm going to try merging it into the main project like I did with Aidan's microphone code. There's some sensitive info in the code that I don't want to accidentally push to the repository, so I redacted the Wi-Fi credentials and Spotify API keys.
I'm starting by creating a task that will run the TFT display code in the background. It runs an initialization function that sets up the display and then enters a loop that updates the display every second. Gino's code uses the LVGL library, which is a great library for creating GUIs on embedded devices. https://lvgl.io/ It also uses the esp_lcd_ili9341 library, which is a driver for the ILI9341 TFT display we're using.
I'm having a lot of trouble getting the display to work. The only thing I've been able to do is get it to show white and black screens.
I got the build system working for Gino's repository so I have a point of reference and his works fine. I'm still not sure why the re-implementation on our Matter repository isn't working.
It's getting pretty late so I'm going to call it a night for now.
Entry 2: -----------------------------------------------------------------
Date: April 15thStart Time: 9:30am
Duration: 5 hours
Today I am working on implementing our 5th PSDR, the ability to automatically adapt lighting based on real time environmental conditions via Wi-Fi module. I forgot that this was one of our goals for most of the semester but it's also something that should be fairly simple to implement.
For this PSDR we are using a weather API to get the current weather conditions in our area. I am starting by looking for a free weather API that we can use to get the current conditions. After some searching, I found the OpenWeatherMap API, which is free for up to 1000 calls per day. https://openweathermap.org/api
We're using the current weather API, which returns the current temperature, humidity, and weather conditions for a given location: https://openweathermap.org/current We can use this information to adjust the color of the LED strip based on the current weather conditions. For example, "sunny", "cloudy", and "rainy" conditions can be returned from the API. We can use these conditions to set the LED strip to different colors, such as yellow for sunny, white for cloudy, and blue for rainy.
I made a separate file for the weather API key called secrets.h, this file will be ignored by git so we don't accidentally push our API key to the repository. I set up a periodic task in the RTOS that will call the weather API every 15 minutes to get the current conditions. The response will be cached in a global variable so we can use it in the LED control code and avoid making too many API calls. We're using the ESP HTTP client library to make the API calls, which is a simple and easy to use library for making HTTP requests on the ESP32. https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/protocols/esp_http_client.html
Right now our code has two main modes, adaptive (microphone) and manual. I'm going to add a third mode for weather API control. This will also require some changes on the mobile app side to allow the user to select the weather API mode.
I just got the weather API working and I'm able to get the current temperature, humidity, and weather conditions for my location. Now I need to implement the logic for setting the LED strip color based on the weather conditions. I'm going to use some logic to check the weather conditions and set the LED strip color accordingly.
Now that I have the weather API working, I need to implement logic in the app and ESP firmware to allow the user to select the weather API mode. I'm going to turn the adaptive mode switch into a segmented control that allows the user to select between manual, adaptive, and weather API (environmental) modes. Here is the result:
After some app network troubleshooting, the weather API integration is finally working well! This is a huge milestone for our project and I'm really happy with how it turned out. This will also allow us to display the current weather conditions on the TFT display, which is a nice bonus.
Entry 1: -----------------------------------------------------------------
Date: April 14thStart Time: 12:15pm
Duration: 2 hours
Worked on my last individual assignment for the project: the user manual. Our project is fairly software-heavy so a lot of it is just explaining how to pair it to Wi-Fi and use the mobile app. I worked on creating the user manual for our smart LED strip controller. Since our product is a mix of hardware and software components, I made sure to document both aspects thoroughly. I covered:
1. How to set up the device initially with power connections
2. Step-by-step instructions for Wi-Fi pairing through the Google Home app
3. Detailed explanation of all app features:
- Color control
- Brightness settings
- Adaptive mode (microphone response)
- Environmental mode (weather API integration)
I included screenshots for each step to make the instructions more user-friendly. The manual also has a troubleshooting section for common issues like connection problems or LED malfunction.
The manual is a crucial deliverable for our project as it ensures users can actually take advantage of all the features we've implemented.
=============== Week 13: =================
Entry 6: -----------------------------------------------------------------
Date: April 10thStart Time: 12:00pm
Duration: 6.5 hours
Today I am working on the TFT display code. Gino sent me his esp-idf project and I am going to try merging it into the main project like I did with Aidan's microphone code. I'm having some trouble getting the libraries to compile though, it seems like it's trying to call functions that don't exist.
Kyle just arrived, so we're going to try getting the microphone working on our PCB. We're having some trouble getting the microphone to work. I think it might be a hardware issue because it works fine on the dev board, but Kyle seems to think it's a software issue. The problem is that the esp32 keeps rebooting randomly, and we're not sure why.
I'm back to testing the microphone on our dev board and it actually seems like my assumption that it was working was wrong. While the FFT algorithm is printing values, they don't actually seem to be changing when I tap the microphone. I'm really not sure what's going on here, I might have to wait for Aidan to come in and help me debug this.
I ended up using ChatGPT to write new code for the microphone and I now have a prototype working that can at least detect loudness. However, when I test it on our board it still has the same issue of rebooting randomly. I talked to my friend Matt who is next to our lab station and he said maybe the microphone signal is creating interference and tripping the enable pin. Sure enough, when I took another look at the pinout for the ESP32, the enable pin is right next to the microphone signal pin we're using.
I'm going to try re-wiring the microphone to a different pin and see if that fixes the issue. I also found out that the PCB we thought was dead with the buck converter actually works fine, so we can prototype on that board too!
I soldered a wire to one of the TFT pins and connected it to the microphone signal pin. It worked fine for about 10 minutes, but then the reboot issue randomly came back. I'm really confused at this point and I'm giving up for now. Hopefully next week when I have a clear mind I can figure this out.
Entry 5: -----------------------------------------------------------------
Date: April 9thStart Time: 7:00pm
Duration: 2 hours
I'm back from my dinner break and motivated by the possibility of getting our project done early. I'm on Aidan's branch of the code, he said he was having some issues with the linker after making some changes and I think I found the problem. It's an issue I ran into previously, he's trying to use C only features in a C++ file. Luckily this is easily fixable by declaring the function as extern "C" in the header file. Now the linker is working and I can see the microphone code running in the terminal. It's printing "Dominant Frequency" and "Magnitude" values as expected.
Aidan's code works using a FFT algorithm, which is a common algorithm for analyzing the frequency content of a signal. We need to schedule this in our OS properly but ensure that we're not using too much CPU time. I thought about dynamically creating a task based on whether adaptive mode is toggled but I for now that's too risky because I don't want to accidentally create a memory leak. I've settled on a simple task that runs a check of whether adaptive mode is active then continues to perform FFT if it is:
While the task is always active, the performance impact should be negligible if the initial check is false. Now it appears that our microphone is actually working! When I tap the microphone, I can see the dominant frequency and magnitude values change in the terminal. I also see the color of the LED strip change in response to the microphone input.
Next I'm going to work on integrating the TFT display. Aidan can definitely handle any further changes to the microphone algorithm.
Entry 4: -----------------------------------------------------------------
Date: April 9thStart Time: 12:00pm
Duration: 5 hours
Kyle got to the lab early today and has been working on a new PCB. This one has a couple of buttons flywired onto it so we can hopefully boot into the bootloader more reliably. However, we are still having trouble getting the ESP32 to flash. We also tried downloading the Arduino IDE and flashing with that just to see if it was a problem with the ESP-IDF SDK. But that isn't working either. There are also lab sessions in progress so it's hard to get the attention of the TAs.
We've been troubleshooting for a couple hours now but we haven't made any noteworthy progress, it seems like we're just doing the same thing over and over expecting a different result. We were able to get help from one of the TAs and she said we should use an oscilloscope to check the signals on the UART pins, but we don't know which mode to use and the TAs are all busy with other students now. A small discovery I made was that the ESP32 draws slightly more power when we hold the boot button down during reset. So I think that means the bootloader is working and we have a way to detect that the ESP32 is in bootloader mode.
I had the idea to check the ESP32's serial monitor again now that we know how to get into bootloader mode. And in now it is actually transmitting data! It shows information about the microcontroller and indicates that it is in bootloader mode. I'm not sure if the board yesterday was having issues but that one didn't show anything in the terminal at all. Kyle had the idea to try flashing again with the Arduino IDE and it actually worked this time! This is such a relief after so much time troubleshooting. Now we just need to get flashing to work through ESP-IDF.
The fix ended up being to increase the baud rate back to its original value of 400k. Now we see the familiar debug messages being printed to the serial monitor just like our dev board.
We were even able to get the LED strip to light up by providing 5V from an external power supply (this board doesn't have a buck converter). We suspect that the buck converter on the other PCB isn't working properly because Kyle said he saw it go up to 3.65V at one point, so we're considering just using our backup LDO instead. The LDO is currently soldered to another board however, so we need to get that unsoldered first.
We got the LDO unsoldered by the ECE shop staff, and everything appears to be working now! We are able to control the LED strip from the ESP32 completely powered by our 5V input.
One of the TAs also checked off our PSDR for controlling the LED using our app, which is a big milestone. Now we're taking a much deserved break but next I'm going to work on getting the microphone code fully working.
Entry 3: -----------------------------------------------------------------
Date: April 8thStart Time: 5:30pm
Duration: 2 hours
Me and Kyle are working on the PCB assembly today. It's been a while since I flashed a microcontroller without a USB port, and at first we thought that our ST-LINK programmer was a UART adapter 😂. After finding a proper UART adapter, we are trying to flash the ESP32 with the firmware we have been working on. The UART adapter is showing up in VSCode, but we are having trouble getting the ESP32 to flash. We don't know if the microcontroller is actually in bootloader mode or not. We don't have any buttons soldered because the ones that were originally planned for the board ended up being way too small, so we have jumper wires we're using to try and reboot the microcontroller.
According to the Espressif documentation, the ESP32 should be in bootloader mode if GPIO0 is pulled low during boot. We are trying to pull GPIO0 low by connecting it to ground, but the ESP32 is still not entering bootloader mode. Our voltage levels look normal so it appears the buck converter is working fine.
We also tried turning down the baud rate from its original 400k, but that didn't help either. After asking a TA for help, they said we should prepare a new PCB because the ESP32 might be soldered incorrectly. We will continue working on this tomorrow.
Entry 2: -----------------------------------------------------------------
Date: April 8thStart Time: 9:30am
Duration: 1 hour
Met during assigned lab period to discuss our project progress. Everyone provided updates on their respective components, and we had a productive discussion about integration timelines. Aidan shared that he's making good progress on the microphone code. He's successfully got it to compile with our codebase, which is a significant milestone for our software integration. The code is compiling without errors, but there are still some issues with the functionality. We discussed potential solutions, and I offered to help debug once I finish class later today.
We also reviewed our overall timeline and agreed that getting the microphone working properly is a priority, as it's a core feature for our adaptive lighting mode. Kyle will also begin soldering the PCB components this week as we have received all the parts needed. I might help him load software onto the PCB once it's assembled if he does that later today.
Entry 1: -----------------------------------------------------------------
Date: April 7thStart Time: 12:15pm
Duration: 2 hours
Today I worked on the App for our project a bit more. I tried to add a function that extracts the RGB values from the color picker, but I was having some trouble with it. I implemented everything on the firmware side as well, but I'm really struggling with the RGB color values not being accurate. When I select what appears to be a pure red color in the iOS color picker, the RGB values that get extracted are something like (255, 12, 8) instead of (255, 0, 0). I spent a good hour trying different approaches to fix this issue.
Looking at Apple's documentation more carefully, it seems their color picker uses a different color space internally, which is causing these slight variations in the RGB values. I tried implementing a simple correction algorithm, but the results weren't satisfactory - colors still appear slightly off on the LED strip compared to what's selected in the app. At this point, I think I need to take a step back and focus on other core parts of the project for now. The basic color functionality works well enough for demonstration purposes, and there are more critical features we need to implement before our next milestone. I'll come back to improving the color accuracy later when we have more time. For now, I'm going to prioritize getting the adaptive lighting mode working with Aidan's microphone code integration.
=============== Week 12: =================
Entry 4: -----------------------------------------------------------------
Date: April 4thStart Time: 1:00pm
Duration: 3.5 hours
Today I helped set up Aidan's build system on his laptop so we can merge his microphone code with my base firmware. Before now he was working on his own project and didn't have the Matter SDK set up. It took a while to get everything set up, but I was able to help him get the ESP-IDF SDK installed and working with the Matter SDK. The thing that took a while was that I forgot how to set the Matter directory inside the ESP-IDF SDK. After some research I found this forum post: https://www.esp32.com/viewtopic.php?t=36547 which made me remember that it is a command from the VSCode command palette. Now Aidan is able to build the firmware and he's working on integrating his microphone code with the rest of the firmware.
Next I did some work on the mobile app to make it more presentable. I added a color picker for the LED strip color, but the colors are a little bit off. I'm using Apple's ColorPicker() component, which is a great way to get a color from the user. But if I slide the red slider all the way to the right, the color has a little bit of green in it.
After reading the documentation more, there's a way to get the RGB values from the color picker instead of HSB. Next week I'm going to implement a new web request to set the LED strip color using the RGB values from the color picker.
=============== Week 12: =================
Entry 3: -----------------------------------------------------------------
Date: April 3rdStart Time: 1:00pm
Duration: 6 hours
Today I am continuing to work on the HTTP server for the ESP32. I know Matter uses mDNS to advertise the device on the network, and I was able to get that address from the device logs. I'm not sure if this is a static or dynamic address, so it's not clear if I can use it in the mobile app. But it should be fine for testing purposes for the web server. After putting the Matter mDNS address into Postman, I was able to get a response from the ESP32!
Now that I know the web server is working, I need a way for the mobile app to reliably find the ESP32's mDNS or IP address. I'm going to look into using the ESP32's mDNS service to advertise the web server on the network.
I'm going to implement a custom mDNS service that will advertise the web server on the network. The mDNS service will be named shall-led-MACADDRESS.
After some experimentation, I found that initializing the mDNS service in the web server code was causing the Matter component's mDNS service to fail. However, the mDNS name I found earlier is actually just the ESP32's MAC address. And it is static and persists across reboots and factory resets. Obviously using this address is not ideal since it is device specific, but it works for now, and it's better than just hard-coding the IP address into the mobile app.
For some reason the iOS emulator will not connect to the ESP32's web server, but I was able to get it working on my iPhone. I wrote a simple GET request and printed it out on the main screen of the app.
Next, I am going to implement the POST requests for setting the LED strip color, brightness, power, and adaptive mode. After adding all of those to the firmware, I am going to create a simple UI for the mobile app to control the LED strip.
It's not pretty, but it works for now. I also used ChatGPT to generate this app icon!
Next steps are to add a proper UI so the app is more presentable.
Entry 2: -----------------------------------------------------------------
Date: April 2ndStart Time: 2:15pm
Duration: 4 hours
Today I am working on getting the HTTP server running on the ESP32. I am planning on implementing the following espressif component: https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/protocols/esp_http_server.html
The goal here is to develop an API that the mobile app can use to control the LED strip. We want to be able to set the LED strip to different colors, turn it on and off, set the brightness, and toggle adaptive mode. I'm going to start by implementing a simple GET request that returns the current state of the LED strip. Then I'll add POST requests for setting the color and brightness.
I'm putting most of the code in a new file called web_server.cpp. After Matter is initialized, I call the function:
web_server_start();Which initializes the HTTP server and starts listening for requests.
This is the code I wrote to retrieve the current state of the LED strip:
Part of my work last week was to make the LED strip control code more modular, so I can easily call those led_strip_get functions to get the current state of the LED strip. According to the Wi-Fi router we're using, the ESP32 should have the IP address 192.168.0.105. However, I'm having trouble reaching it from the mobile app.
I'm not sure if it's an issue with iOS app permissions or the ESP32's web server, so I'm going to try using Postman to test the API first. Postman is a great tool for testing http APIs that I've used in the past. It allows you to send GET and POST requests to a server and view the response, among other features. I was still unable to reach the ESP32 from Postman, and I realized that the IP address I was using was incorrect, I actually had the IP for the Google Nest Hub.
I am going to continue working on fixing this tomorrow.
Entry 1: -----------------------------------------------------------------
Date: April 1stStart Time: 9:30am
Duration: 2 hours
Met with group during assigned lab period. We are still waiting for parts to arrive for the PCB, our order finally got processed after a week of waiting. On the software side, Aidan was able to get his FFT code working for the microphone and is now ready to integrate it with the lighting. Gino was able to get the TFT display to show a live feed of the current time, showing the ability to update the display in real time.
During this lab period, I was able to fix the lighting issues I faced last week. I ended up hard-coding conversions for color temperature to RGB values. It's a bit of a hack but it also saves performance, which is important because we are running multiple tasks on the ESP32 at once.
Now it's my job to get the base OS ready to integrate with the rest of the software. My next step is to get the HTTP server running on the ESP32 so we can control the LED strip from the mobile app.
=============== Week 11: =================
Entry 2: -----------------------------------------------------------------
Date: March 28thStart Time: 12:00pm
Duration: 6 hours
Today I am working on getting our firmware ready for integration with the mobile app. Because the ESP32 already connects to Wi-Fi for Matter control, I decided to use the same Wi-Fi connection for the mobile app. To do this, I need to set up a web server on the ESP32 that can handle HTTP requests from the mobile app. Luckily, the ESP-IDF SDK has a built-in HTTP server library that makes this easy to do. https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/protocols/esp_http_server.html
First however, I need to lay the groundwork for this by making the LED control more modular. This way we can control the LED strip from both the Matter protocol and the mobile app. And it will be easier to add adaptive control via the microphone in the future.
I'm having some trouble converting Matter's HSV color space to RGB for the LED strip. The issue is that as brightness increases, the color shifts to a cooler temperature.
Next steps are to keep working on the LED control code and get the HTTP server set up.
Entry 1: -----------------------------------------------------------------
Date: March 25thStart Time: 9:30am
Duration: 2 hours
Met with group during assigned lab period. Discussed progress on each member's software component. Gino is working on the TFT display and fixed the issue he was having with off-axis color shifting. Aidan is still working on getting microphone processing working properly.
We also received our PCB back from fabrication and Kyle will soon begin work on soldering/testing components on it. Next steps for me are to integrate the mobile app with the ESP32 firmware.
=============== Week 9: =================
Entry 3: -----------------------------------------------------------------
Date: March 13thStart Time: 5:30pm
Duration: 5 hours
I feel like I've been hyperfocusing on the LED strip control for the past few weeks, so I decided to take a break from that and work on the mobile app for our project. The goal of our app is to expose controls that aren't available in the Google Home app, such as setting the LED strip to adaptive mode for responding to music, and dynamic lighting effects where different LEDs on the strip can be set to different colors. It will also handle the user's Spotify login for use on the TFT display.
I'm building the app using Xcode and SwiftUI, which I have a bit of experience with from a personal project I'm working on. SwiftUI is a declarative UI framework that allows you to build user interfaces using a simple and intuitive syntax. It's how Apple recommends building apps for their platforms, and I've found it to be easy for creating apps that look native to iOS.
I decided to make a sketch of the app's layout before starting to code, so I can have a clear idea of what I want to build. Here's a rough sketch of the app's main screen:
After sketching the app, I started coding the main screen in Xcode. I was able to get the basic layout set up with a navigation bar using the SwiftUI TabView() structure. I also created basic "Hello world" views for each screen that will be in the app.
After that, I started working on my journal summary when I came across a potential fix for the Matter library issue I had a couple days ago. I found the following code which could achieve the same result as modifying the Matter SDK directly to enable HSV color support:
I found it in the following GitHub issue on the esp-matter repository: https://github.com/espressif/esp-matter/issues/963 Now that this is fixed I don't have to worry about making my teammates manually apply fixes to the Matter SDK.
Next steps are to make lighting commands light up the entire LED strip instead of just the first LED.
Entry 2: -----------------------------------------------------------------
Date: March 11thStart Time: 12:00pm
Duration: 4 hours
In order to integrate our working LED strip control with the Matter SDK, I first need to debug an issue that came up earlier with the Matter library.
In the Google Home app, I can change the color temperature of the LED strip, but I can't set an rgb value to it.
I found this GitHub issue that seems to be related to my problem: https://github.com/espressif/esp-matter/issues/365 It says that the sample Matter project uses HSV color space, while some apps require XY color space. I spent some time implementing a basic version of the XY color space conversion algorithm in my code. But I was still having the same issue with the colors not showing up in the Google Home App.
After further experimentation, I found that you can fix the issue by editing the Matter SDK directly to advertise the correct color space, thanks to a comment in the GitHub issue mentioned above.
After making this change and re-pairing the accessory, I was able to control the LED strip with the Google Home app using RGB values.
However, I would like to avoid modifying the Matter SDK directly if possible. Especially because my teammates would need to make the same change on their devices.
Next steps are to find a way to enable HSV color space without modifying the Matter SDK directly.
Entry 1: -----------------------------------------------------------------
Date: March 11thStart Time: 9:30am
Duration: 2 hours
Met with lab group during assigned lab period. Reviewed progress on PCB layout and discussed next steps for software development. Now that we have LED strip control working, we can finally continue working on other software components.
=============== Week 8: =================
Entry 3: -----------------------------------------------------------------
Date: March 6thStart Time: 3:30pm
Duration: 3 hours
Met with the team to prepare for our presentation on Friday. We spent a lot of time finalizing our slides and assigning who is presenting which slides.
We also put our minds together to really try and figure out what's wrong with our LED strip. We figured that maybe this strip was damaged as well. Because WS2812B strips are wired with each LED in series with its own controller, you can actually cut them apart and use sections of a strip individually. We wanted to check if the first LEDs in the strip were damaged so we cut them off and soldered new wires onto the strip. This time, rather than a single LED lighting up, we actually had a segment with 12 working!
The rest of the strip doesn't work, but we decided to cut off another section and see if that worked. That part had 6 working LEDs. Kyle was able to solder those two sections together and we found that the combined strip worked fine. So at this point we think the issue is that our LED strip was damaged before it was given to us.
Finally, we spliced out all of the bad LEDs and found a point where the rest of the strip was fully functional. We have now confirmed that our electronic setup works fine for controlling the LED strip!
Next steps are to integrate this into our software more so it can be controlled via Matter.
Entry 2: -----------------------------------------------------------------
Date: March 5thStart Time: 11:30am
Duration: 4 hours
Today I continued my efforts in debugging the WS2812B LED strip's voltage issues. This time Kyle was in the lab with me and he was able to provide some EE expertise 🤠. After spending some time verifying that everything in my test circuit was correct, we thought the issue might be with the level shifter we had. Although the lab staff is technically off this week, I was able to talk to a TA that happened to be there and got a new level shifter and LED strip. I asked him if it made sense to use a boost converter for our project and he said a level shifter would ideally be the best implementation as I suspected. This time the level shifter we get was a TXB0104, which is more common and had better documentation than the one we were using previously.
https://www.ti.com/lit/ds/symlink/txb0104.pdf
So I wired up the new circuit while Kyle soldered some wires onto the LED strip for testing. Kyle had to leave at that point, but I wired it up and was disappointed to find that it wasn't working.
I took a break to work on our presentation slides, and when I returned to the LED strip issue, I realized I still had it wired to 3.3V because that's the only voltage the previous strip worked at (even though they're supposed to be 5V). After fixing that, I finally got the strip to run at 5V. However only the first LED would light up.
I'm very confused on what the problem is with our LED strip controls. I honestly did not expect this part of the project to be so difficult. Kyle thinks it might be an issue with the code, but I was able to control multiple LEDs on the other strip fine at 3.3V. We tried changing the data rate and some other settings in the LED strip library, but nothing worked.
Next steps are to keep debugging the LED strip control.
Entry 1: -----------------------------------------------------------------
Date: March 1stStart Time: 11:00am
Duration: 3 hours
Today I went into the lab to work a bit more on the LED strip control. Our LED strip had an issue where only half of the strip would light up.
Initially, I thought the issue was due to power limitations of the USB port on my laptop, but after testing with the lab power supply the issue persisted. I assumed this was linked to the issue of only being able to run the strip at 3.3V instead of 5V. After some troubleshooting, I remembered that the code I wrote only addressed 50 LEDs, and our strip might be larger to that. After changing the code to address 200 LEDs, the entire strip lit up as expected.
I spent the rest of the time in the lab trying to get the strip to run at 5V. I verified that the level shifter was outputting the correct voltage by giving it a static 3.3V signal and checking the output. I put in a part request for a boost converter to see if that would help rather than a logic level shifter. I also requeted a new LED strip to make sure the one we got isn't defective.
Next steps will be further debugging the LED strip issues. I'd really like to get those sorted out before our presentation.
=============== Week 7: =================
Entry 2: -----------------------------------------------------------------
Date: February 27thStart Time: 12:30pm
Duration: 6.5 hours
Today I am working on integrating the FastLED library with our ESP32 firmware. I'm having some trouble getting the library to compile with the ESP-IDF SDK. This is my first time integrating an external library with C++ software, and ESP-IDF. I'm getting build errors regarding the library's source C++ files not being discovered, so I might need to add them to the project's CMakeLists.txt file.
After some troubleshooting and advice from my teammate Gino, I decided to switch to the official espressif led_strip library:
https://components.espressif.com/components/espressif/led_strip/
The reason why I want to use a library for the LED strip is because the data line of a WS2812B expects a specific bit pattern in order to control its colors. Rather than writing this code from scratch it makes sense to use one of the readily available open source libraries due to the timing restraints and complications with implementation. Switching to the official espressif led_strip library made the implementation a lot more simple. I was able to drop it in the managed_components folder and had very few issues getting it to build. I coded a simple blink example using the official library with the following code:
led_strip_set_pixel(strip, i, 0, 0, 0);This function allows us to set the color of a specific LED in our WS2812B strip. The function takes five parameters: - strip: A pointer to the LED strip object - i: The index of the LED to control (zero-indexed) - r: Red intensity value (0-255) - g: Green intensity value (0-255) - b: Blue intensity value (0-255) After setting the color values, we need to call
led_strip_refresh()to actually update the physical LEDs with our new settings. This two-step process allows us to prepare multiple LED changes before sending the data to the strip all at once, which creates smoother animations and effects.
Upon testing this, I'm getting weired mixed results. I have the LED strip connected to the ESP32 with a level shifter to convert the 3.3V logic to 5V logic.
It worked great for a few minutes, very bright and lighting up the entire strip. But now the LEDs won't turn on at 5V. Oddly, they still work at 3.3V, however they're much dimmer and only light up about half of the strip.
Next steps are to troubleshoot the LED strip power issue, I'm considering swapping the level shifter for a boost converter.
Entry 1: -----------------------------------------------------------------
Date: February 25thStart Time: 9:30am
Duration: 2 hours
Today I met with the team during our assigned lab period to review the PCB layout for our project. Kyle has been taking the lead on designing the PCB layout in KiCad, and I was able to provide some feedback based on my experience with Purdue Electric Racing. One of the main suggestions I made was to use a pour layer for the ground connections rather than individual traces. In my experience with PER, using a ground pour offers several advantages: it provides better noise immunity, reduces impedance, and simplifies routing complex boards. Kyle was receptive to this feedback and agreed that a ground pour would be the better approach for our design. During this lab period, I also did more research and discovered the FastLED library for interfacing with the WS2812B LED strips:
https://github.com/FastLED/FastLED
This library is well-documented, widely used, and offers extensive functionality for creating dynamic lighting effects. It will integrate well with our ESP32 platform and the existing Matter protocol implementation. Next steps include finalizing the PCB layout with the ground pour implementation and preparing for design review before submission for fabrication.
=============== Week 6: =================
Entry 3: -----------------------------------------------------------------
Date: February 21stStart Time: 2:30pm
Duration: 5.5 hours
Today I am working on getting the ESP32 to run multiple tasks simultaneously. The ESP-IDF SDK uses FreeRTOS to manage tasks. I've worked with FreeRTOS before a bit in Purdue Electric Racing, so I'm familiar with the basics. However, I've never used it with a C++ project before.
Right now the code for the Matter components of the firmware are in app_main.cpp and app_driver.cpp. My goal is to create a new file that my teammates can use to add their own code for things like sensor processing and display output.
I am still pretty new to using C++ in embedded systems, so I'm learning a lot about how to structure the code. The ESP-IDF SDK has a built in HAL for the ESP32, which is nice because we can call a function to write to a GPIO pin without having to mess with the registers directly. This is done in the function:
gpio_set_level(gpio_num, level (0 or 1));They also provide a logger that can be viewed over the USB connection to the ESP32 via JTAG:
ESP_LOGI(TAG, "This is a log message");I decided that I'm going to create a file called gpio_toggle.cpp that will toggle the onboard LED on and off once per second. Obviously this is a simple task, but it will help me understand how to structure the code for the project. I can use the vTaskDelay() function provided by FreeRTOS to create a delay between toggles.
I've been spending a lot of time trying to debug code that I've written. I was stuck on an undefined symbol error for a while because I didn't know that you need to use the 'extern "C"' keyword to include C code in a C++ project. I also ran into a stack overflow issue due to not allocating enough memory for the task in the FreeRTOS task creation function. However, I finally got the code to compile and run on the ESP32! This is a big step in the project because it shows that there is a viable path forward toward supporting both Matter and our custom software on the same microcontroller.
Next steps are to get the team's code integrated into my version of the software.
Entry 2: -----------------------------------------------------------------
Date: February 20thStart Time: 12:00pm
Duration: 2 hours
Today I am testing the Matter version of our firmware on a Google Nest Hub that I brought to the lab. After some troubleshooting, I was able to get the ESP32 to pair with the Nest Hub and control the LED strip. I had to add some code to reset the ESP32's Wi-Fi and matter pairing settings when the boot button is held down for 5 seconds. This was necessary because the ESP32 would not pair with the Nest Hub if it was already paired with the ESP Rainmaker app. The Matter protocol only allows pairing when the device is in a specific discoverable state, and the SDK we're using supports this by calling the following function:
app_reset_button_register(button_handle);After the ESP32 was reset, I was able to pair it with the Nest Hub and control the LED strip using the Google Home app by scanning the QR code mentioned in a previous journal entry. Because the Google Nest Hub is a Matter hub for my Google Home ecosystem, I was able to control the LED strip from my phone and the Nest Hub simultaneously.
This successful integration represents a major milestone in our project by validating our Matter implementation with a real-world smart home ecosystem. Next steps are to get simultaneous tasks working on the ESP32, such as controlling the LED strip with the Matter protocol and reading sensor data from a GPIO pin.
Entry 1: -----------------------------------------------------------------
Date: February 18thStart Time: 9:30am
Duration: 1 hour
Met with lab group during assigned lab period. Reviewed our PCB design with Dr. Walter and discussed power requirements for our LED strip controller. Using KiCad and our current schematic, we talked through potential modifications to our power distribution design to ensure proper voltage regulation for both the microcontroller and LED strips. We need to update the label on our power source and carefully consider the current requirements of our LED strips. This feedback helps ensure our PCB design will be reliable and meet safety requirements. Next steps are to update the schematic with the suggested changes and begin PCB layout.
=============== Week 5: =================
Entry 2: -----------------------------------------------------------------
Date: February 11thStart Time: 1:30pm
Duration: 7 hours
Today I was able to create a working prototype for our C++ codebase. The software that I used previously was part of the Matter SDK's sample code, and because it is explicitly royalty free I decided that it would be a good starting point for our project. The difficult part was getting the code to compile outside of the parent SDK's subdirectory, which was crucial for establishing a Git repository. After lots of trial and error, I was able to get the code to compile and run on the ESP32 again.
Using the SDK is crucial for our project due to the complexity of the Matter protocol. It handles secure pairing with smart home systems and their given Wi-Fi access point using Bluetooth, and can even pair with multiple systems at once. Writing a Matter library from scratch would likely qualify as an open source software senior design project itself due to the amount of work it would take!
I was also able to check out a Wi-Fi router from the lab, which allowed me to finally connect the ESP32 to the internet and more importantly a Matter controller app! In the example below, I've connected the ESP32 to the ESP Rainmaker app, which is a demo app that uses the Matter SDK. Pairing with Matter devices is very simple, as long as the device is in pairing mode you can just scan its qr code and it will automatically connect to Wi-Fi and pair with the target app.
Next, I would like to try pairing the ESP32 with a Google Home or Apple Home ecosystem to make sure it works with systems outside of the Demo app I'm using. These systems require the use of a home hub device, such as a Google Nest speaker or Apple HomePod. I also need to figure out how I can structure the software to switch from Matter control to sensor control mode, and give my group members a way to interface with the base software for the required modules they are working on.
Entry 1: -----------------------------------------------------------------
Date: February 11thStart Time: 9:30am
Duration: 1 hour
Met with team during scheduled lab period to discuss switching our codebase from MicroPython to C++. The transition would give us better performance and more direct hardware control. After reviewing the ESP-IDF documentation and Matter SDK requirements, we determined C++ would be a better fit. Successfully mapped out key parts of the codebase that need to be ported. This helps establish our core software architecture. Next we will begin implementing the basic LED control functionality in C++.
=============== Week 4: =================
Entry 4: -----------------------------------------------------------------
Date: February 7thStart Time: 11:30am
Duration: 5 hours
Worked on getting matter the esp-matter firmware flashed onto our esp32 devkit. At first, I was getting a bunch of build errors from ninja, and after troubleshooting them for a while I just decided to scrap everything and re-clone the esp-idf and esp-matter repositories. Finally, I was able to get firmware flashed onto the board, and shortly after I was able to view the device logs over the same usb port used for flashing. I noticed that upon pressing the "boot" button on the board, the device would show a toggle command in the logs, but the onboard LED would not turn on.
After some debugging with the help of GitHub Copilot, I narrowed it down to a missing configuration on the type of onboard LED and its GPIO pin. After adding the correct configuration, I was able to get the LED to turn on and off with the boot button on the microcontroller.
However, I'm still having issues with getting the controller to pair to the Matter controller app on my phone, according to the errors I'm getting I suspect I might need to check out a Wi-Fi router for it to be able to connect.
Overall this was great progress in getting Matter implemented in our project. In terms of further steps, I'd like to get Matter control working via an app, then create custom software using the Matter library where we can switch between Matter mode and sensor-controlled lighting.
Entry 3: -----------------------------------------------------------------
Date: February 6thStart Time: 11:30am
Duration: 2 hours
Completed assigned work on A5 component analysis. Used my prior research into LED strip standards from last week to complete that section of the component analysis. I was able to create a comparison chart between WS2812B and 4-pin non-addressable strips to justify why we should use the former for our project. Later this week I would like to get a working implementation of Matter working on our microcontroller.
Entry 2: -----------------------------------------------------------------
Date: February 5thStart Time: 10:30am
Duration: 1 hour
Met via FaceTime to discuss LED strip selection. I explained to the group why we should go with the WS2812B standard over other 4-pin RGB strip standards. We also met to solidify what we want to accomplish with the project by the end of the semester, and which PSRs should be our stretch goals. As a result we decided that incorporating computer vision should be a lower priority than the app connectivity or the onboard display.
Entry 1: -----------------------------------------------------------------
Date: February 4thStart Time: 9:30am
Duration: 2.5 hours
Researched ESP32 revisions. Compared chips and decided which one to use based on feature set and release date.
Initially, I was looking at the ESP32-WROOM-32. However, that version of the ESP32 doesn't include integrated USB support and would require an external USB to serial chip. This Reddit thread mentions the ESP32-S2, which does have integrated USB. But it's not as powerful as the WROOM which has a dual core processor rather than the S2's single core. Our development board uses the ESP32-S3-WROOM, which maintains the dual-core processor of the ESP32-WROOM-32 while also having integrated USB. This lead me to the conclusion that the ESP32-S3-WROOM-2 would be the best choice for our project, which is the most recent revision of that line of chips and has additional RAM for compute tasks like FFT. Additional power could come in handy for features like audio processing. Selected specific microcontroller we will be using. Later this week I will continue prototyping software.
=============== Week 3: =================
Entry 4: -----------------------------------------------------------------
Date: January 31stStart Time: 2:00pm
Duration: 1.5 hours
What: Continued Matter SDK implementation and A3 document updates
How: Using ESP Matter SDK build system and documentation writing
Result: Encountered build errors with Matter SDK, successfully added Matter library documentation to A3
Project contribution: Software architecture documentation improvement and progress towards Matter integration
Next steps: Debug and resolve Matter SDK build issues
Still working on getting the Matter SDK working, I'm running into some build errors right now. Also updated the A3 software document with information about the Matter library that we will potentially be using.
Entry 3: -----------------------------------------------------------------
Date: January 31stStart Time: 9:00am
Duration: 2 hours
What: Research into Matter frameworks compatible with ESP32
How: Online research and GitHub repository exploration
Result: Found ESP-Matter framework by expressif, initiated framework setup
Project contribution: Identified viable Matter implementation solution for our project
Next steps: Complete framework setup and begin implementation testing
Did research into existing Matter frameworks and found one compatible with the ESP32. It's actually made by expressif, the same company that makes the ESP32. You can find it here on GitHub: https://github.com/espressif/esp-matter
Working on getting the framework set up on my computer, but it's taking a while to clone all of Matter's development dependencies.
Entry 2: -----------------------------------------------------------------
Date: January 30thStart Time: 3:30pm
Duration: 2 hours
What: Team progress meeting and LED strip protocol research
How: Team discussion and technical documentation review
Result: Selected WS2812B protocol for LED strips, reviewed Wi-Fi implementation progress
Project contribution: Defined LED strip specifications and identified need for Matter framework
Next steps: Begin Matter framework implementation to replace current micropython solution
Met with the team to discuss current progress. Gino has been prototyping software on his ESP32 and was demonstrated the ability to connect to a Wi-Fi access point. Currently the software is based on micropython, but there isn't an easy way to interface with the Matter protocol using that language, so I will need to do some individual experimentation with existing matter frameworks.
We also established that our project will support LED strips that conform to the WS2812B protocol. These strips are individually addressable, which will allow us to create some cool effects with the lights, such as a startup animation. The LED strip pinout is as follows:
- 1: GND
- 2: Data
- 3: 5V
Graphic source: Last Minute Engineers
Entry 1: -----------------------------------------------------------------
Date: January 29thStart Time: 12:00pm
Duration: 2.5 hours
What: A3 Software Overview document preparation
How: Software architecture planning and library research
Result: Created initial software architecture documentation
Project contribution: Established software development roadmap and requirements
Next steps: Share documentation with team and begin implementation
As the software lead, I am responsible for this week's assignment: A3 - Software Overview. Spent a couple of hours planning the software architecture and researching libraries, as well as filling out the assignment.
=============== Week 2: =================
Entry 4: -----------------------------------------------------------------
Date: January 23rdStart Time: 6:00pm
Duration: 1 hour
Completed the weekly participation quiz and updated website journal entries.
Entry 3: -----------------------------------------------------------------
Date: January 23rdStart Time: 3:30pm
Duration: 1 hour
Finished up the last of the A2 assignment. Received ESP32 DevKit from course staff, which means we can start work on serious prototyping!
Entry 2: -----------------------------------------------------------------
Date: January 22ndStart Time: 2:00pm
Duration: 2 hours
Researched different types of LED strips and their protocols. It looks like the most suitable option for this project would be a 12V 4-pin RGB strip. We don't need the LED strip to be individually addressable because of the limitations of the Matter protocol.
Entry 1: -----------------------------------------------------------------
Date: January 21stStart Time: 9:30am
Duration: 1 hour
Met with lab group during assigned lab period. Began work on assignment A2 and discussed proposal feedback with Dr. Walter.
=============== Week 1: =================
Entry 3: -----------------------------------------------------------------
Date: January 16thStart Time: 3:30pm
Duration: 2 hours
Met with the team to discuss potential additional PSDRs. We specifically set aside time to discuss potential uses for computer vision in our project.
Entry 2: -----------------------------------------------------------------
Date: January 14thStart Time: 1:00pm
Duration: 1 hour
Set up network share for team website. Took some troubleshooting to get login username prompt to appear on macOS. Also completed weekly quiz.
Entry 1: -----------------------------------------------------------------
Date: January 14thStart Time: 9:30am
Duration: 1 hour
Met with lab group during assigned lab period. Received lab tour and met teaching staff.