Hello! I’ve been a bit busy so there aren’t going to be too many updates this month. From last month’s blog I stated that the 1st release for ZBCE API and Waste Watcher should be coming out soon. I was aiming for the release to come out this month, but I hit a couple snags and found more improvements to be made. In addition, I still need to write some documentation with the releases. That’s probably the part I hate the most, but still making some slow and steady progress. In this month’s blog, I will be going over some of the improvements I implemented and some general updates.
Reducing Waste Watcher Power Consumption (Again) 🤦
I feel like this is an ongoing task that will never stop. There always seems to be some type of power consumption improvement to make. This usually includes modifying the circuit, modifying the code, or both. So what was the problem this time? As I noticed, the flash was sometimes on for way too long (as observed from previous blogs as well). This is a problem because turning on the flash on the ESP32-CAM is the most power hungry operation. For some reason I always thought the code flow was perfect, but then I realized I came up with the code so it must suck. After checking the code again I realized the flash was not turned off after the image was taken. Instead it was only turning off after the image was saved to an SD card (with Waste Watcher v0) or sent to a HTTP server (with Waste Watcher v1).
It was a pretty quick fix and now the flash only turns on for about less than a second. I will need to test how much better this improves the total number of hours it can run on one battery charge. I am pretty confident that this will help a lot.
Debugging Waste Watcher 🐞
I spent some time working with Andrea, Brianna, and Patrick for debugging a problem with the Waste Watcher. With v0, there was a problem trying to mount to the SD-card. I don’t know when this started happening, but basically for some reason there was some trouble trying to mount the SD-card for saving images and bin fullness data. As usual, this was the approach I took for my debugging process:
- Found out as much information as I can by isolating the problem and trying to reproduce the error
- Come up with some hypothesis as to why the problem is occurring
- Test hypothesis
- Determine best solution for the problem
I’m pretty sure that there are some official debugging process for software engineering, but above is just a process I like to go through. Maybe I should try to look-up some official debugging process as a future learning goal. Anyway, for step 1, we isolated the problem and figured out that the sd card mounting error only occurs when we set the GPIO pins in lines 293 and 294 in the image below. If we comment those two lines out and not use those GPIO pins the sd card mounts just fine. However, as soon as we use it the sd card does not mount.
With that I came up with the following hypotheses.
- The SD card was not in a 1-bit SD bus write mode, which was using the same GPIO pins as the ultrasonic sensor pins leading to some sort of GPIO pin conflict.
- Assigning GPIO pins was interfering with mounting the SD card.
For the first hypothesis, I got to say the documentation for the ESP32 CAM was pretty terrible. There was little to no documentation at all, the best bet was to go to the source code. Thankfully there were some good helpful resources such as this one which explains the difference between a 4-bit SD bus and a 1-bit SD bus mode. Basically, the difference between the two modes is that the 4-bit SD bus writes data faster to the SD card, but uses more GPIO pins; while the 1-bit SD bus writes slower, but uses less GPIO pins. I already knew this when I was developing the Waste Watcher. With the group, we were just able to confirm that the code was running in 1-bit SD bus mode which rules out my first hypothesis.
The second hypothesis took a while to come up with, but I eventually thought of this after we tested commenting out the lines that setup the GPIO pins. As a solution, commenting out the GPIO pin setup code is not feasible. We need to setup those pins for the ultrasonic sensor. So instead, we tried switching the order. We mounted the SD card first by calling the sdSetup() function. And then we setup the GPIO pins. This was so weird, but it works. So even though a 1-bit SD bus mode does not use the extra pins that the ultrasonic sensor is currently using, it still needs it to mount it properly. I have no idea how that works, but it works 🙃. In the image below, we show that the sd-card is setup first and then the ultrasonic pins are setup.
This was such a simple fix, but took a while to figure out. Thank you to everyone who helped out. You all rock!
Updates on Releases 🌱
Both releases for Waste Watcher and ZBCE API should be ready soon. I was actually planning for it to be release this month, but I got really busy. I also just wanted to take some time to thank everyone who contributed to these two repositories. I know that I have been sort of stuck on the prototyping phase of this process for a while, but I’m glad to know that we are making some progress. I also know that there are probably an infinite number of ways to improve the Waste Watcher and the ZBCE API, but I really wanted to focus on getting a working concept deployed first. Otherwise, I feel like this project will always be stuck on the prototyping phase. But please feel free to keep on telling me how the project can improve in our Discord Server!
Have a great a day!
– Owen