How realistically do you think that an Arduino could HOLD accurate clock time, with precise tuning?

Projects Programming
1

I am aware that Arduinos are not really intended as real time clocks, however, I have been very impressed so far as to its precision holding. I could not find any good SevSeg (I am obviously using the 4 digit display, hence SevSeg!) program on Github, so I modified the “counter“ example provided with the Github SevSeg library:

/* 
  Extant4Life: clock that continues almost in real time, but not quite.
  Adjust the 60000 preciseMillisValue value to account for the program logic in the loop!
  This is a very basic version with no ability to adjust the clock reading.
 */

#include "SevSeg.h"
SevSeg sevseg;  //Instantiate a seven segment controller object

const int initialTimeSet = 35; //This is just the time of day when the program is uploaded to arduino (0035 atm)
const uint16_t preciseMillisValue = 59820; // Adjust very finely to increase precision

void setup() {
  byte numDigits = 4;
  byte digitPins[] = { 2, 3, 4, 5 };
  byte segmentPins[] = { 6, 7, 8, 9, 10, 11, 12, 13 };
  bool resistorsOnSegments = false;    // 'false' means resistors are on digit pins
  byte hardwareConfig = COMMON_ANODE;  // See README.md for options
  bool updateWithDelays = false;       // Default 'false' is Recommended
  bool leadingZeros = true;            // Use 'true' if you'd like to keep the leading zeros
  bool disableDecPoint = false;        // Use 'true' if your decimal point doesn't exist or isn't connected

  sevseg.begin(hardwareConfig, numDigits, digitPins, segmentPins, resistorsOnSegments,
               updateWithDelays, leadingZeros, disableDecPoint);
  sevseg.setBrightness(90);

  sevseg.setNumber(initialTimeSet, -1);
}

void loop() {
  static unsigned long timer = millis();
  static int clockDisplay = initialTimeSet;

  if (millis() - timer >= preciseMillisValue) {   // 60000 milliSeconds is equal to 1 minute
    timer += preciseMillisValue;                  // Adjust very finely to increase precision
    clockDisplay++;

    //Due to this program logic (here and below), the 60000 figure needs fine adjustment
    //60000 is a little too slow
    int secondDigit = (clockDisplay / 10) % 10;
    if (secondDigit == 6) {
      clockDisplay = clockDisplay + 40;
    }

    if (clockDisplay == 2400) {
      clockDisplay = 0;
    }

    sevseg.setNumber(clockDisplay, -1);
  }

  sevseg.refreshDisplay();  // Must run repeatedly
}

/// END ///

Over the past couple of days, I have adjusted the preciseMillisValue. It is getting really accurate now. The main program I am using actually has buttons for adjusting time, but I gave this basic program to avoid too many lines of code.

Do you think there is a point where preciseMillisValue can be adjusted to make it so that it will hold for maybe many days, or even weeks, or are some variables going to come into play that might seriously compromise its integrity over that timespan?

I think it may lose integrity over about 50 days anyway due to the usage of millis(). For now though, it seems pretty good.

Any thoughts?

2

when i built a digital clock in high school, i was told to use 60Hz from the power supply as a reference because it is tied the the clock at the Naval Observatory. (use a schmitt trigger)

3

Temperature changes and power failures come to mind.

This is why RTC modules like the DS3231 (accurate to about +/- 1 minute drift per year) compensate for temperature changes and have battery backups.

4

OK, it is good to see that in print. The temperature part of that, was what I was expecting someone would mention. I just wanted to see if someone mentioned it (before I presumed). I was not specific but I was presuming it would be a factor. My accommodation may see a lot of temperature fluctuations, if I am honest.

Thank you.

The “power” bit is something that can be mitigated hopefully. I probably won’t be using this for something like security, so I likely would be using a stabilized PSU (e.g. USB PSU), rather than a battery.

I am in the process of trying to work out how to switch to battery backup cleanly, but that is another issue, for a lot of projects I have going at the moment.

5

I think you are just kidding yourself and the time you have spent is wasted. A change in temperature will undo it all. A DS3231 module is temperature compensated, can be had for just a couple of dollars or so, and is well-supported round here.

6

Thank you, yes, I have been looking at that exact unit. I am still wondering if it is a level of accuracy needed, or if I can get away without it. I am going to check up on what I have over several days (which, indeed, may not be enough). I am compiling a bunch of things to purchase right now, and I will see if it is needed.

7

An Arduino with AtMega 32U4 processor (Leonardo, Micro, Pro Micro) has a much more accurate crystal instead of the UNO's ceramic resonator because of USB's tight frequency requirments. Right now, I'm running a similar program on a clone Pro Mini that's 2 seconds fast after 2778 minutes (46+ hours). 3 for $18 from Amazon. Update interval is 60000 millis().

ProMini

8

It is much, much easier and cheaper to switch to using a DS3231.

9

Who would know what you really want? But you might find what you have is satisfactory if it stays indoors and you have a benign climate. I understand the DS1307 is much the same as a Uno but I found it OK until I took it outside.

10

A broken analog clock is absolutely correct at least one time every day. An Arduino can be tuned to be reasonably accurate over a short period of time, but as temperature changes and components age, its timing will drift. It will both gain and lose time, with the average being only somewhat close. If you need real accuracy, obtain the time from NTP or another external reference and be sure to account for signal and processing delays.

You have not defined accuracy so your results are subjective.

11

People sometimes say to use the signal from a GPS receiver for accuracy. But there are limits to the accuracy in what you get. The GPS satellites are only accurate because of corrections from ground stations making the corrections. The earth is not a sphere and is not of uniform density, therefor satellite all vary in orbit and speed. There are 4 ground stations in the US. Others are scattered around the earth. There was one in Russia, but was removed when the US would not allow Russia to put in a US ground station for their version of GPS.

My former company built GPS receivers for Meritron to use in their navigation system. We had to stop production for 4 months when Russia closed the US ground station. It took that long for the software company for rework their software to work properly without the corrections from the ground station in Russia.

So that tells you a bit about making accuracy a priority.

12

You are showing your age :grinning_face_with_smiling_eyes:. That was true years ago, but now the power grid is not corrected as long as it is close with the changing loads. Yes, I did sync my first digital clock with the power line.

There was a similar problem with using the TV color burst frequency (before analog TV disappeared). Originally it was locked to a standard, but then stations began re syncing it with local oscillators. All the neat projects syncing with the color burst were then mostly useless (depending on how accurate the local station was compared with what you had).

13

i was told the generators were sped up in the morning and slowed down as the load increased as people woke and and conversely were slowed down in the evening.

the are not freq accurate over the course of the day, but are accurate with respect to the # of cycles

14

Here is what I found on the US 60hZ accuracy.
The U.S. 60 Hz power grid is **very accurate over time, but not perfectly constant at every moment.

Short-term (seconds to minutes):

  • The frequency typically wanders about ±0.02 to ±0.05 Hz
  • During disturbances it can briefly stray a bit more
  • This variation reflects changing load vs. generation

Long-term (hours to days):

  • Utilities actively correct the frequency so the*total number of cycles stays on target
  • Over a 24-hour period, the accumulated error is usually less than a few milliseconds
  • In practice, the average frequency is extremely close to 60.000 Hz

Timekeeping implication:

  • Synchronous clocks that count line cycles stay accurate because lost cycles are later paid back
  • This is why old electric clocks kept good time even without crystals or RTCs

Typical numbers you can rely on:

  • Instantaneous accuracy: about ±0.03 Hz (typical)
  • Long-term time error: on the order of seconds per year or better, often much better

Bottom line:

  • The grid is not a precision frequency source moment-to-moment
  • It is an excellent long-term time reference due to correction mechanisms

That makes it useful for clocks, but less ideal for precision frequency measurements without averaging

15

My AI confirmed what I took away from my personal HI deep dive some years ago, viz:


LOL, my instant reaction!

a7

16

In Texas, ERCOT mandates that TEC (time error correction) maintain the grid frequency and one can find the instantaneous deviation at any time from the Ercot website. Since is not directly connected to the national grid there is no synchronization with it.
Time correction schedule is optional with local operators and the time can be off as much as +/-30 seconds before the correction is mandatory but can be counted on for +/-0.5 second accuracy during a 24 hour period.
e.g. it's currently 60.021Hz

17

All interesting, but it does not make clear whether a deficit of 30 seconds is made up to catch up to real time.

Correcting in this context can be read to mean just making the output 60 Hz accurate. If the errors were consistent and slow, clocks would fall behind.

It seems they do deliver the correct number of cycles over long periods. The ERCOT Nodal Operating Guide language mirrors the traditional NERC definition of “time error correction”, which is unambiguously:

A process of adjusting scheduled frequency to restore accumulated clock error and thereby deliver the correct number of cycles over time.

Nice but probably still not going to move to Texas. :expressionless:

a7

18

If you use a board with WiFi connectivity, my choice is ESP32 because it’s cheap, then you can get accurate time from the internet using NTP. I think an ESP32 would be cheaper than an Arduino + a RTC module.

19

There are many ways to keep accurate time, and there are among us ppl who want to do the best with… whatever.

So what's the best you can do with an Arduino is a legit inquiry.

I'd put a crystal clocked UNO in a temperature controlled box and see.

I've seen a 10 MHz crystal in an oven and you could "hear" the temperature falling when the heating element was off and rising when it kicked in via beat frequency with radio 10 MHz.

a7

20

Not a problem!:expressionless: