There hasn’t been a lot of progress on the clock lately, so there haven’t been a lot of posts. What can you do? One thing that has changed is the choice of ESP32 for the project.

ESP32-S3 for fun and profit

I’ve been running into the issue of power management. Coming from a JavaScript background it’s not something I’ve ever had to actively think about, but building a clock that’s meant to hang on the wall is different. You want one set of batteries to last you around a year for something like that, and based on my research, I would only be able to get months with a standard WROOM.

The issue is waking up every 1.4-ish seconds to update the clock. The idea was to enter low-power mode between seconds and just wake up for a moment to update the clock. That works, but it chews up 3 AAs in a few months which, honestly, isn’t going to cut it for most people. So what’s the answer? Ultra-low-power mode.

The ESP32 has a simple core called the ULP co-processor that can run small programs while pulling mere microamps. The thing is, if you want to write a program to run while the ESP32 is in deep sleep mode, you have to use the ESP-IDF framework, so good bye sweet Arduino. Oh, and that small program that runs in ULP mode? If you use the WROOM, it has to be written in assembly. So we’re switching to the S3 which will allow me to write it in C.

The new plan is to have a tiny program that runs in ULP updating as much of the clock as possible, and only waking when the clock needs to be recalibrated via NTP. This is the change that will push my battery life from months to at least a year.

ESP-IDF is a splash of cold water

Diving into ESP-IDF is eye opening. I’m always going to have a soft spot for Arduino just because it brought me to this point, but it’s kind of shocking how much complexity it abstracted away from me. Even the simple delay() function is a layer of abstraction.

A part of me hates the seemingly arbitrary complexity of the VSCode implementation of ESP-IDF, but I can also see how it’s going to open up some doors. The part that I’m looking forward to the most, though, is being able to save my work directly to GitHub. I’ll admit I don’t use it so much as version control as I do a cloud repo, but I like having my work on GitHub more than in a random directory on my computer.

As much of a learning curve as it’s been, I’ve managed to get the TM1637 working with the new compiler/flasher. It was surprisingly harder than I thought it would be to make it work given some of the quirks that Arduino smoothed over for me (I’m looking at you ticks), but it does work, which means I can make more complex things, like ternary clocks.

Clock technical drawings have been finalized

The last bit of news I’ll drop is that my suppliers have finalized the design for the LCD. From here it will be about a month to get the sample displays made and then a few weeks to get those samples to me. Honestly, I don’t think I’ll be ready by then, but I’ll probably be close.

The big thing that’s changed is they told me they needed to go with 1/1 duty cycle to make it work, so the final display they’ll send me will have 124 pins! That’s two rows of 62. I’m going to have to chain at least three LCD controllers to get this to work and probably an external oscillation chip. The complexity has ballooned so much it’s overwhelming.

That’s where we are. I’m going to play with this 1637 a bit more and then get the WiFi working with this new ESP-IDF setup. I have to make a captive portal to get WiFi credentials and write the smallest clock program possible to cram into ULP, and I have about two months to do it before my samples get here. Did I mention I have to design a PCB as well? No? FML =P

---