Motivation:

I sometime play games into the night without realizing how late it is. I need a clock below my monitor that is non-distracting, large, easy to read in my peripheral vision. Also it would be ideal if is set and forget i.e. accurate enough and handle silly DST time changes.

Additional pages for this project on HaD:

https://hackaday.io/page/6687-stm8-led-clock - more project details
https://hackaday.io/pages/10708 - test results

External Project page: 

Github: https://github.com/FPGA-Computer/LED-Clock

User interface

The clock and display time:

The arrows key switches between the time and date display.  The date display uses a different format to distinguish the modes.  The 7 segment LED can only show a limited set of characters and have to make do with some approximations. 

e.g. Th(ursday) 16 Jan is shown below.  

Time (and similarly date) can be set using 3 buttons.

Hardware description:

Instead of using the usual RTC modules used by other projects, the RTC is implemented in firmware with features such as Daylight Saving Time. The RTC code can be adapted for oddball clocks that uses different units of time. e.g. Metric time or Mars time. 

The clock doesn't require an ultra accurate crystal.  As long as it has a very stable frequency, then the tolerance can be calibrated out.  I used a common AT-cut 12MHz crystal as the frequency source. 

If clock is used in a home environment with temperature controlled, chances are that the temperature variation is small enough to get away without using a TXCO.  e.g. Heater set to 21C and air condition to 25C means that the variation is about 4C.

There is only a very narrow frequency range that you can shift a crystal by the load capacitance and a trimmer capacitor doesn't make fine adjustment predictable nor repeatable.

A 16-bit timer in the STM8 generates a 20Hz IRQ. A more accurate 10Hz is then generated from using a 24-bit Numerically-controlled oscillator (NCO) implemented in firmware.

e.g. if your 20Hz is  +50ppm fast = 20.001Hz, 10Hz can be generated by dividing it by 2.0001.

NCO can perform fractional frequency division by keeping track of the phase in an accumulator.  Don't let the name fool you, this 3 extra lines of code is all that's needed for very fine frequency adjustments!

The 10Hz is used by the RTC code to update the time, date and implement the Daylight Saving Time (DST) for North America.

 (repost from https://hackaday.io/page/6687-stm8-led-clock)

I made a digital clock. Originally I planned to use a VFD, but the user interface on a 4 digits would be too limiting. I used a STM8S003, 74HC595 and a couple of  the cheap green 7 segment displays. The display efficiency is actually not bad as the entire clock runs on 5V at ~20mA.

The LED driver is on a separate rail. A supercap allows the STM8 to work for a few minutes during a power failure. 

The PCB is wired to the original (stripped) Caller ID PCB to use existing buttons. The same GPIO for the common cathode driver when off-duty is used for polling the buttons.

I could have used the STM8 alone to drive the display. By adding the 74HC595, I freed up a few GPIO lines for future expansion.

External I/O

UART, I2C, a Timer pin, 5V power and the hardware debug interface (SWIM) are connected to the headers on an I/O panel PCB using the existing RJ11 cutouts. I have since changed the power connector to a MicroUSB as it has much better latching.

Side by side view of the old traveler's Casio clock it is replacing as it is much harder to read during night time.

Calibration 

This clock can be calibration without external frequency counter, GPS etc. I simply used a binary search algorithm to narrow down the value of the divisor by visually comparing whether the clock was running faster/slower than an atomic clock website: https://time.is/   over a period of time.  Each of these test would only needs to be just long enough to notice the difference.  As it progressed, each test get longer to run as the clock gets more accurate.  One advantage is that the long term effects/drifts are part of the test, so this is real life accuracy. So far I have down 7-8 such comparisons to the less than +/- 1 sec/month accuracy I have. I am surprised that a very inaccurate crystal could be this good.  There is more tweak that can be made, but I think other factors such as temperature drift etc would be the limiting factor unless I replace the crystal with a more stable clock source such as a TXCO or OCXO.

Accuracy:

The test was done on Nov25 - Dec25 and it measured less than +/- 1 sec after 1 month. This includes the tolerances, long term drifts due to temperature, power etc.  The clock slowed down by 1 sec after 4 week 6 days.  As can be seen, this is as accurate as some of the better grades of RTC after calibration.

Contrary to common believes, off the shelf RTC modules are a mixed bag.  Some of the common ones with external crystals are not accurate at all.

Accuracy of a RTC module without any calibration:

http://www.reuk.co.uk/wordpress/accurate-ds3231-real-time-clock-as-alternative-to-ds1307/

>However, in our experimental projects (using this RTC with an Arduino for dataloggers amongst other things), we have found these DS1307 modules to vary hugely in their time-keeping accuracy – some gaining/losing a few seconds per day, and others gaining/losing as much as 3-5 minutes per day. 

>The DS3231 chip on the module is marketed as being accurate to 2ppm (parts per million), which means less than one second lost or gained every 5 to 6 days. The units we have tested thus far have all come in at under 1ppm accuracy, so a couple of seconds at most lost or gained per month.

When a good quality RTC module is calibrated with a GPS:

https://blog.dan.drown.org/rtc-comparison/   

>This (DS3231) RTC's performance over this week was -0.038ppm +/-0.085 ppm. This is pretty good. This is around 1 second fast per year

>The PCF2129's performance over this week was 0.462ppm +/-0.239 ppm. This is also good. This is around 1 second slow per month.

Also see https://blog.heypete.com/2018/02/04/ds3231-drift-results-5-months/