RTC (DS1307 or other) with millisecond resolution

I'm trying to build a clock that can show milliseconds and keep time accurately in general (also thinking about making a "metric" clock in the future... in which one second would be .864 real seconds, so I would need to see the millis) but, while I know I can use the millis() function, I cannot find any RTC circuit that actually returns milliseconds.

Does anything like this actually exist?

As far as I know there does not exist unless you go in the timeservers. A work around that may be interesting is to log the "position" of the millis() at the moment you set the RTC.

Suppose it is 16837 millisec. Then you remember the last 3 digits 837 so can use that as an offset. When time is requested you get the seconds minutes etc from the RTC then you fetch the millis(), subtract 837 and get the last 3 digits. (maybe you should add/sub few millisec to correct the time to calculate all this)

hopes this helps.
rob

Wouldn't that run into the issue of the inaccuracy of the ATMega timer? And the rollover?
Maybe at each 1 second rollover from the RTC, I could readjust the offset, just seems like a kludge to me...

As said its a workaround if you want a workaround. Another option is to use the Ethernetshield and get connected to an internet time server (S)NTP. If you know the average roundtrip time you can get (I guess) approx 10 msec accuracy. You just need an NTP server near you with the shortest turnaround time

NTP servers:

The time lib can sync with an NTP server and a RTC can too:


Could you tell more about your metric clock concept?
How many hours per day, minutes per hour? seconds per minute? metric assumes multiple factor 10 => 100.000 seconds a day?

robtillaart:
As said its a workaround if you want a workaround. Another option is to use the Ethernetshield and get connected to an internet time server (S)NTP. If you know the average roundtrip time you can get (I guess) approx 10 msec accuracy. You just need an NTP server near you with the shortest turnaround time


Could you tell more about your metric clock concept?
How many hours per day, minutes per hour? seconds per minute? metric assumes multiple factor 10 => 100.000 seconds a day?

Hmmm... good thought, but that would definitely add a lot of cost and complexity. Will keep it in mind though.

As for the metric clock, it's actually a concept that's been around for a while (late 1700s actually).
I've always understood the concept to be as follows:
10 hours per day (full standard 24 hour period)
100 minutes per hour
100 seconds per minute
therefore,
10,000 seconds per hour
1,000 minutes per day.

Now, you obviously can't just cram 100 seconds in a minute without redefining the timespan of 1 second. So, under metric time, are the following conversions:
1 metric second = 0.864 seconds
1 metric minute = 1.44 minutes
1 metric hour = 2.4 hours

Which is how you can span 10 metric hours over the course of a 24 hour day.

Originally, when the metric measurement system was adopted, many people tried to get the world to switch to metric time, but it just didn't stick.
You will still see references to it though... mainly in Sci-Fi. My favorite is in the 1927 film "Metropolis", where all the clocks show only 10 hours... I guess the point was that it was the future and they were more advanced, so they had adopted the metric system for everything.

I would definitely not be the first person to create a metric clock, however. I actually got the idea from a metric watch made by Swatch that I came across years ago. I mostly just want to do it for the hell of it... and because, while they exist, metric clocks are very hard to find. Or at least true metric clocks... you can often find analog clocks with the face replaced to only show 10 hours... but the clock hands still move based on the 12 hour analog system, so it merely crams 12 hours into a 10 hour scale.

you can often find analog clocks with the face replaced to only show 10 hours... but the clock hands still move based on the 12 hour analog system, so it merely crams 12 hours into a 10 hour scale.

why not use an 5 hour scale for 12 hours ??????

5 hours day, 5 hours night ??

robtillaart:
why not use an 5 hour scale for 12 hours ??????

5 hours day, 5 hours night ??

Well, that's how it's supposed to work... but what I meant was that they were taking a standard analog 12-hour clock where one rotation of the hour hand is always 12 hours and slapping a face on it that only shows 10 hours. But since they didn't changing the timekeeping of the clock it self, it still takes 12 real hours to traverse their version of 10 metric hours. You are absolutely right of how it's really done, my point was that those are a mere novelty and not correctly representative of metric time.

understand, the hour hand could work as it should just by changing the face. But you need another gearbox to get the minutes and the seconds right.

Did you ever try to make your metric clock as a windows app e.g. in processing or C#, VB ?
(code not tested)

uint8_t mSecond = 0;
uint8_t mMinute = 0;
uint8_t mHour = 0;

void setup()
{
  Serial.begin(115200);
  Serial.println("Metric Clock Simulator");
}

void loop()
{
  unsigned long t = millis() % 864;  // metric seconds since startup;
  
  mHour = (uint8_t) t / 10000;
  t -= mHour * 100;
  mMinutes = (uint8_t) t / 100;
  t -= mMinutes * 100;
  mSeconds = t;
  
  Serial.print(mHour);
  Serial.print(":");
  Serial.print(mMinutes);
  Serial.print(":");
  Serial.print(mSeconds);
}

(thinking out loud)
The current clock is heavily based upon the circle and 360 degrees. A metric clock should have a new basic form in which the metric scale is more natural.

A square with LEDS in an U (or H) shape. The X-axis is hours and the Yleft axis minutes and Y-right axis is seconds. On the Y axises every tenth LED has another color (or extra led) for faster counting.

A triangle with base = hours = LEFT = minutes RIGHT = seconds.

Or a decagon (10-angle?) and every side is one hour. But then we are close to a circle again.

A cube could also be nice... or ...

Maxim makes several RTCs with 0.01s resolution, e.g. DS1390-DS1394. See the parametric search:
http://para.maxim-ic.com/en/search.mvp?fam=rtc&tree=timers

Why don't you use an arduino with a crystal? I get about 0.000015 second resolution out of mine using a timer interrupt and various registers.

OK I worked over the time library and the DS1307 library pretty thoroughly and updated all the examples that I thought were useful (to me).

Find all the code here. It should help you get started. First install the time libraries, then add my DS1307 Library, and update the time library with the code and examples provided.

SEE HERE
http://arduino.cc/forum/index.php/topic,51802.0.html

All the code is embedded in the post...

and here
http://www.arduino.cc/playground/uploads/Code/Time.zip

From this page...
http://www.arduino.cc/playground/Code/Time

I use the millis() function (as suggested by others) to measure down to the millisecond. I use it to do data logging at the millisecond level.

Don't see why it won't work. Of course a clock that displayed milliseconds flashing away would probably give people fits... Just my $0.02 :stuck_out_tongue:

Many RTCs have a square wave output that can be set to various frequencies. For example the DS3231 has a 32kHz output, you can run that to an interrupt and increment a counter every 32 interrupts.


Rob

  • just a hint: RTCs like the DS1307 have a rather limited precision, loosing or gaining usually a few seconds per day. They are however typically a factor 10 better than a timing based on the Arduino-clock (i.e. millis()).

In fact, clock-crystals are usually operating at the rather low frequency of 32.768 Hz and are rated with 25 ppm, which gives you +- 2.16 secs error per day (25e-660sec60*24). The crystal the Arduino derives it's clock from (and the millis()-timing) is even rated worse.

In addition: the clock-crystal of a DS1307 drifts away if not operated @25 degrees of Celsius. Do not expect to achieve a timing precision with DS1307-breakout boards available on the market which matches the precision of your wrist watch. There are RTC-clocks which are temperature-compensated, which might fare a little bit better.

If you can, I would suggest using a DCF77 module like the one described here http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1266858603 to get exact time information from an offical time server. If you need a finer resolution than a second (which your title suggests), use the DCF77 module to sync your time code every second or so. You could even try to figure out a correction factor for the Arduino-millis, giving you sub-second precision just with an Arduino and a DCF77 module.

  • cpixip

Yes the normal RTC chips aren't very good, however the DS3231 I mentioned above has an internal TCXO and should be accurate to about +-2ppm which should be good enough for a clock.

By using a 32kHz interrupt and writing a quick ISR you would have a very accurate "millis()".


Rob

cpixip:

  • just a hint: RTCs like the DS1307 have a rather limited precision, loosing or gaining usually a few seconds per day. They are however typically a factor 10 better than a timing based on the Arduino-clock (i.e. millis()).

In fact, clock-crystals are usually operating at the rather low frequency of 32.768 Hz and are rated with 25 ppm, which gives you +- 2.16 secs error per day (25e-660sec60*24). The crystal the Arduino derives it's clock from (and the millis()-timing) is even rated worse.

There is obviously some confusion here, probably induced by clones with ceramic resonators, or units running on internal clocks.

But if you have an arduino or clone, or any microcontroller chip, that is driven by a crystal, then there is little to no reason to use an external rtc just to keep accurate time. An rtc uses a crystal too. And the timer interrupts work as well as or better than using an external interrupt with a square wave.

http://www.arduino.cc/playground/Code/Time

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1245423319#3

The accuracy of the millis() function is governed by the clock in your Arduino board which is driven by either a crystal or ceramic resonator. A crystal has an accuracy of roughly +/- 50 parts per million (ppm) or so (some are more accurate some are less, but 50ppm is about right for a cheap crystal).

50 ppm = 0.005% accuracy which in your case equals about 0.72 seconds deviation from the nominal delay over 4 hours at 16MHz

A ceramic resonator is about 0.5% accurate = 72 seconds over 4 hours or about 1 minute 12 seconds at 16MHz.
...
The same kind of clock accuracy calculations apply to a DS1307 RTC, the fundamental accuracy of the crystal determines the accuracy of the time it keeps, there's nothing special about the DS1307 in terms of accuracy and it could in fact be worse than the Arduino's internal clock. It all comes down to the simple question of how accurate you need the timing to be for your application and then select an appropriate oscillator.

so you can see that it is not anywhere near "a factor 10 times worse", and for pennies you can easily retrofit a more accurate crystal if the stock one is not accurate enough for you.

I'm not confused, at least I don't think I am :slight_smile:


Rob