4-Digit IN-12 and IN-2 clock coming soon!

I have just put together what I think is the last firmware changes to the new Wemos based IN-12 or IN-2 4-Digit clock. I've completely reworked the entire firmware, now getting the time from NTP, and have kept all of the best features:

• Linear digit dimming controlled by LDR
• RGB NeoPixel back lights
• Fully WiFi configurable
• On-board RTC
• Automatic changes to DST
• Motion sensor support
• Simple to build using only through hole components

As well as this there are a whole bunch of new features:

• Very high speed multiplexing (more than 300Hz)
• Very small PCB size (38mm x 100mm)
• OTA updates (no need for special programmers to update the firmware)
• Persistent on time and tube on time counters
• NTP time setting with DST for anywhere in the world

Every clock will come with a series of video tutorials and a traditional build manual.

MikeS wrote:

Ian wrote: I have just put together what I think is the last firmware changes...

I'm amused.

Good point.

However, we're only talking about V0001 here, so I'm not saying it's finished.

It took me ages to get it right. I've been fiddling about with it for at least two months, but now I am happy with it for a release. It's tricky to get the ESP8266 just right to run a multiplexed clock, WiFi and NTP all without them interfering with each other. The ESP has to balance its time between the display (which is highly sensitive to disturbance - the slightest hiccup is visible) and managing the rest of the work that has to be done.

To get this right, I went through these iterations on the net management:
1) Time server using a synchronous HTTP client: Response is too slow and causes the display to blank for 200mS. I also want to get away from the proprietary server solution
2) Time Server using an asynchronous HTTP client: Better but still visible
3) ezTime: Better but uses synchronous UDP and still visible. I also found that ezTime makes a real dog's dinner of the time zone handling. Much too complicated.
4) NTP using ESP SDK: Nearly right, but uses synchronous UDP and does not allow the update interval to be managed
5) NTP using asynchronous UDP and C time management. Yaay! Fast, flexible, configurable, no display flicker.

The clock uses NTP while it can, then if that becomes unavailable, falls back to RTC, and if that is broken or unavailable, falls back to internal time management using millis(). Each type of time source updates the ones further down the stack, so if we get and NTP update, it sets the RTC and the internal time source. When NTP is not available, RTC updates the internal time. Reconnection also works great.