Skip to main content

ESPCLOCK V2.0 - Design

I previously started a project to hack an analog clock to sync with NTP. I call the project ESPCLOCK, because it uses the ESP8266 chip (or more specifically, the ESP-12E development board for the ESP8266) to integrate with the analog clock.

From a usability viewpoint, I like the fact that there is no need to mess with timezones during setup. Basically when setting up the WiFi, the setup page grabs the timezone from your browser automatically. So setup is as simple as entering the WiFi credentials, and the clock will start keeping accurate time and handle daylight saving automagically.

However, in its current state, there are two issues with the clock:

1. The battery life is awful. Connected to a 2400mAh USB battery pack, it can only last for about 27 hours. A typical analog wall clock will run for at least a year on a single AA battery.

2. To deal with possible power loss, it writes the current clock time to EEPROM every second. Since the EEPROM has a limited number of write cycles, this is clearly not practical. We can of course simply not write to the EEPROM, but that means having to setup the current clock time after every power loss.

I have been thinking about tackling both problems in version 2 of the ESPCLOCK. While waiting for the parts to arrive, I am going to document the initial design I have in mind.

Instead of using only the ESP8266, which is rather power hungry, I am thinking of delegating the clock module to the ATtiny85. This is a diminutive chip that has a normal power consumption of 2.5mA and a sleep mode consumption of only 0.5µA. It is also extremely low cost, priced at slightly over $1 if purchased individually.

The idea is to have the ATtiny85 drive the hands of the clock, as well as communicate with the ESP-12 via I2C. This can be achieved via the TinyWire library. It will only need to respond to 3 commands from the ESP-12:
  • Get current clock time
  • Set current clock time
  • Set current NTP time
The ATtiny85 will effectively act as the "brain" of the clock and automatically catches up with NTP time if necessary. Given its power consumption parameters, it will theoretically last for about 200 days on a 2400mAh battery (assuming 200ms of uptime, and 800ms of sleep time per 1s cycle).

To deal with the EEPROM issue, a 0.47F capacitor will be connected in parallel to the power supply. The ATtiny85 will constantly monitor the voltage of its power supply. When power loss occurs and voltage drops below a certain level (say 3V), the capacitor will provide the ATtiny85 with enough residual power to write the current clock time to the EEPROM. That way, it can keep track of the current clock time accurately in the event of a power loss, without maxing out the write cycle budget of its EEPROM.

The ESP8266 will sleep most of the time, wake up every 30 minutes (probably make this configurable), get the current NTP time (and convert to local time), send it to the ATtiny85 via I2C, then sleep again.

I have ordered another ESP8266 development board, the Wemos D1 Mini, because it seems to have better unmodified deep sleep characteristics (low current draw of 170µA during deep sleep) compared to the ESP-12E. Assuming an average current draw of 70mA over a 10s active uptime (this is just a wild estimate; I could be totally off the ballpark here), it should theoretically be able to last 180 days on a 2400mAh battery.

Putting the two results together, the entire concoction should last about 95 days on a 2400mAh battery. Put it another way, a 10,000mAh battery should be able to drive the clock for a year on a full charge. Given the low prices of USB battery packs, or even a pack of 4 x 2500mAh NiMH rechargeable batteries, an Internet-connected analog clock that runs for a year on batteries alone seems less a pipe dream!

Wemos D1 mini


  1. Interesting. I've been working on a similar project, similar to this but with the addition of a RTC (DS3231). At the moment I've gotten total power usage down to an average of 0.75ma and with some design changes I think I can get less than 0.5ma in total. See I found that the motor controller that I am using to drive the clock is a power hog and am working on some alternatives, BJT h-bridge or direct drive from the ATtiny possibly with PWM if that helps reduce power. Have you played at all with PWM driving the clock?

    1. No, I haven't. The designs I have been playing with always use software to drive the 2 wires originally connected to the clock's quartz crystal. I figure if this mechanism is able to run on an AA battery for a year, it's a good starting point. So my current thinking is to get the uC power consumption down to a minimum, and also to be able to save the current clock state when the battery starts running low. That way, once a new battery is connected, it has enough information to sync the clock back with NTP time.

    2. I found that pulsing the clock with 3.3v uses a lot of power. My first option, using the motor controller make the pulse timing, and the faster adjust timing much easier by using 1.5v or 1.8v to drive the pulses. I also found that driving direct with 3.3v uses that about same amount of power and presents issues with the tick and adjust pulse widths not operating properly. My current experimental setup plan is using the PWM capability of Timer1 on the ATtiny85 and this weekend I hope to be able to run some tests. (I use a web server on the ESP and I2C to the ATtiny85 to be able to adjust the pulse timing on the fly). I like the idea of detecting powerful and saving the current clock position but wonder how much extra power that requires... I'll have to look at the ATtiny85 data sheet again.

  2. Having some thoughts on NTP sync clock movement... Here is an idea which may possibly solve battery issues:
    Instead of quartz clock movement, what if you use a radio sync clock movement like DCF77 or WWVB signal receiver. That type of clock movements comes with a price range within 10 to 15 USD, have mostly the same pysical structure and have exactly the same structure on syncing the clock automatically but use DCF77 instead of NTP. So, on clock PCB, cut the wires of the ferrite antenna to prevent receive of DCF or WWVB signals, and connect the ESP8266 or ATtiny85 to the board which receives the NTP time from WiFi, converts the message to DCF signal type (coding only) and injects to the clock PCB. So the clock module still thinks this signal is a DCF signal. ESP doesnot need to work all the time, only once every let's say 24 hrs; get the NTP signal, convert and send to clock module. Only 1 AA battery lasts from 1 to 1,5 years on the DCF clock module itself. Any thoughts?

    1. Btw, the clock module itself is keeping track of the hour-minute-second hand all the time, so there's really no need to concentrate on clock side of the business.If only i had the electronics knowledge on hacking the DCF77 clock PCB :)

    2. It's an interesting idea. Thanks for sharing!

      I don't think it's possible to "inject" the time into the clock PCB as you put it, since what's on the PCB is probably firmware that reads signal off the DCF77 receiver and decode the information.

      I did think it is probably more feasible to build a mini DCF77 transmitter and convert the NTP time to DCF77. Since our own transmitter is very near to the receiver, it's probably not a problem overwhelming the real signal (assuming it is present in the first place).

      However, after doing some reading on DCF77 transmission, I find it beyond my field of understanding and seem to require advance knowledge in RF transmission, antenna design etc.

  3. Sorry for the consecutive posts; but here is a link to a sample module:

  4. I have a similar design I am wowrking on. I am having trouble waking up the ESP 12E using pin 1 from Attiny85 connected to RST on ESP. It works when connected to USB but not when the Attiny is alone connected to 3.3V. Do I need to add something more or is it a voltage issue?

    1. Your setup should work.. not sure why. Are the ESP12E and the ATtiny85 connected to the same ground? That's a common issue. Also, try pulsing the EN pin instead of RST pin, though both should work AFAIK.


Post a Comment

Popular posts from this blog

Adding "Stereo Mixer" to Windows 7 with Conexant sound card

This procedure worked for my laptop (Thinkpad E530) with a Conexant 20671 sound card, but I suspect it will work for other sound cards in the Conexant family. I was playing with CamStudio to do a video capture of a Flash-based cartoon so that I can put it on the WDTV media player and play it on the big screen in the living room for my kids. The video capture worked brilliantly, but to do a sound capture, I needed to do some hacking. Apparently, there was this recording device called "Stereo Mixer" that was pretty standard in the Windows XP days. This allowed you to capture whatever was played to the speaker in all its digital glory. Then under pressure from various organizations on the dark side of the force, Microsoft and soundcard makers starting disabling this wonderful feature from Windows Vista onwards. So after much Googling around, I found out that for most sound cards, the hardware feature is still there, just not enabled on the software side. Unfortunately, to

Hacking a USB-C to slim tip adapter cable to charge the Thinkpad T450s

This hack is inspired by this post . A year ago, I bought an adapter cable for my wife's Thinkpad X1 Carbon (2nd Gen) that allows her to power her laptop with a 60W-capable portable battery (20V x 3A). A USB-C cable goes from the battery into the adapter, which converts it to the slim tip output required by the laptop. Everything works out of the box, so I didn't give much thought about it. Recently, I decided to buy a similar cable for my Thinkpad T450s. I know technically it should work because the T450s can go as low as 45W (20V x 2.25A) in terms of charging (though I have the 65W charger - 20V x 3.25A).  I went with another adapter cable because it was cheaper and also I prefer the single cable design. So imagine my surprise when the cable came and I plugged it into my laptop and it didn't work! The power manager just cycle in and out of charging mode before giving up with an error message saying there is not enough power. After much research and reading the Thinkwiki

Using Google Dashboard to manage your Android device backup

I used to use AppBrain/Fast Web Install to keep track of which apps I have installed on my phone, and to make it easier to reinstall those apps when the phone gets wiped or replaced. But AppBrain had been going down the tubes, and Fast Web Install had always been a hit-and-miss affair. Android's own "backup to the cloud" system had previously been even more unusable. There isn't a place where you can see what has been backed up. And when you setup a new phone with your Google account, you just have to wait and pray that your favorite apps will be restored to the phone. Typically all the stars have to be aligned just right for this to happen. More often than not, after waiting for an hour or so and nothing happens, you just curse under your breath and proceed to install your favorites apps manually via the Play Store. But I just looked again recently and was pleasantly surprised that things are much more civilized now. Firstly there is a place now where you can loo