Long term stability of internal RC oscillator

Hi,
has anyone experience with long term stability of internal RC oscillator and/or WDT oscillator of AVRs? If I calibrate such oscillator against precise time source (GPS, RTC) may I use it as reasonable source of time provided regulated voltage and near constant (indoor) temperature or will it drift too much? I mean +/- minute in a month or so.

My experience with internal RC oscillator:
By tuning you can get a reasonable accuracy of about +/- 1% for a given voltage and temperature. So the frequency may be "good enough" for UART if (and only if) voltage and temperature stay constant (UART serial requires timing to within +/-2% or so).

Smajdalf:
I mean +/- minute in a month or so.

So let's calculate how many minutes it may be off within one month:
60 * 24 * 30 = 43200 minutes per month
1% of 43200 = 432
So it may be +/- 432 minutes off within a month (that is about 7 hours).
Way too much...

But even with a crystal (50 ppm) you may not meet your needs.
I would recommend a real time clock: DS3231 (accuracy +/- some seconds per year).

You are speaking about short term accuracy. I imagine the frequency is fluctuating around "mean frequency". While the fluctuations may be quite large and interfere with precise measuring or asynchronous communication the "mean frequency" may be stable. For example if it takes 121,954 seconds for WDT set to 1s timeout to overflow 100,000 times it is reasonable to expect next 100k overflows will take very close to 121,954 seconds - much closer than +/- 1%. But I have no idea how close it will be. And how close it will be after a year?

...much closer than +/- 1%...

For the internal oscillator I'm going with "maybe".

For the watchdog oscillator I'm going with "no".

However, "much closer" are weasel words making it impossible to answer your question.

bcook:
For the internal oscillator I'm going with "maybe".

For the watchdog oscillator I'm going with "no".

However, "much closer" are weasel words making it impossible to answer your question.

Do you know anything about the topic or are you just trying to "look smart"? I don't understand what you don't understand about my statement.

Smajdalf:
I don't understand what you don't understand about my statement.

"Much closer". Would that be 0.1%? 0.001%? 0.05%? 0.9999%?

While "much closer" may mean something concrete to you it means nothing to anyone else.

Smajdalf:
... much closer than +/- 1%. But I have no idea how close it will be. And how close it will be after a year?

[quote author=Coding Badly date=1493353951 link=msg=3239032]
"Much closer". Would that be 0.1%? 0.001%? 0.05%? 0.9999%?

While "much closer" may mean something concrete to you it means nothing to anyone else.[/quote]

While "much closer" may not be rigorously defined I still don't see how it makes my questions impossible to answer since they don't use it.

Smajdalf:
You are speaking about short term accuracy. I imagine the frequency is fluctuating around "mean frequency". While the fluctuations may be quite large and interfere with precise measuring or asynchronous communication the "mean frequency" may be stable. For example if it takes 121,954 seconds for WDT set to 1s timeout to overflow 100,000 times it is reasonable to expect next 100k overflows will take very close to 121,954 seconds - much closer than +/- 1%. But I have no idea how close it will be. And how close it will be after a year?

Clock error is going to have both a bias from the desired mean and a random variation. It's the bias term which contributes to long term drift. Getting drift significantly better than 1%* is simply not going to be possible with an IC RC circuit. "Significantly better" in this context is "approaching 0.002%" per your 1 minute per month drift requirement (see uxomm's post above).

2E-5 performance will require a crystal oscillator time base. Good crystals intended for timekeeping with performance on the order of 1E-6 are not expensive items.

Given the constraints you have given...

...provided regulated voltage and near constant (indoor) temperature...

For example if it takes 121,954 seconds for WDT set to 1s timeout to overflow 100,000 times it is reasonable to expect next 100k overflows will take very close to 121,954 seconds - much closer than +/- 1%.

...I stand by reply #3.

The watchdog oscillator is very sensitive to temperature / voltage. Minor temperature changes of the die (e.g. manipulating digital I/O) will likely prevent you from getting "much closer than +/- 1%". Unless you are building an application that performs no useful work.

The internal oscillator is less sensitive. You may be able to get "much closer than +/- 1%".

Smajdalf:
If I calibrate such oscillator against precise time source (GPS, RTC) may I use it as reasonable source of time provided regulated voltage and near constant (indoor) temperature or will it drift too much? I mean +/- minute in a month or so.

Why dont you calibrate the oscillator as you suggest, monitor it over a month or so, and report back ?

srnet:
Why dont you calibrate the oscillator as you suggest, monitor it over a month or so, and report back ?

Because it will take a month. I tried to ask before I try it if someone tried this and failed or succeeded.
Looks like noone (here) knows about it, just guessing.

Smajdalf:
Looks like noone (here) knows about it, just guessing.

When I started participating in this conversation I was willing, if needed, to dug up the several months of data I have collected for the watchdog oscillator over various voltages and temperatures. Given the fact that I'm "just guessing" I guess I won't bother.

I cant see what would be gained even if you had a view as to what what the stability was.

Any test of that type would only be valid for one particular micro and could not be used to accuratly predict and guarantee how another example might behave.

Thus most reasonable designers, when they want such long term stability, would not be relying on the internal RC clock or WDT.

Sorry, I didn't want to insult you. Your answer used wods as "likely" and "may" without any closer information. I thought it is just your opinion withot analysing such data. I am aware this question may be interesting for me but there is little real use of it so I was not suprised noone came with much information. If you have such data I would be glad if you found them and be willing to share.

Smajdalf:
Because it will take a month.

You can get a pretty good idea of drift rate much quicker than that. I've done alignment of 5E-11 rubidium standards in under an hour staring at Lissajous patterns on an analog scope back in the day.

I've looked at the AVR datasheet and some application notes and one thing to consider is that the resolution of the calibration register is about 0.3% so that rules out using the hardware directly. One could do additional compensation in software, perhaps even performing some form of temperature compensation, but it doesn't seem like a particularly robust approach.

In any case, the question has piqued my curiosity enough that I'm working on a test configuration to collect some data. Since I've been playing in the stm8/stm32 domain recently, I'll be collecting against those rather than AVRs, at least initially, but I expect the behaviors are broadly the same. I'll post some data to this thread when I have it.

Note that while the "internal 8MHz RC Oscillator" is "high accuracy" and able to be calibrated via the OSCCAL register, that is NOT true of the 128kHz watchdog oscillator. I haven't measured anything on an ATmega328p, but on an ATtiny11 (which uses a similar (?) watchdog oscillator as THE internal clock (nominally 1MHz)), I can tell you that the frequency varies dramatically and visibly (on a blinking-LED-like program) depending on supply voltage; perhaps 60% going from 3V to 5V...

westfw:
Note that while the "internal 8MHz RC Oscillator" is "high accuracy" and able to be calibrated via the OSCCAL register, that is NOT true of the 128kHz watchdog oscillator. I haven't measured anything on an ATmega328p, but on an ATtiny11 (which uses a similar (?) watchdog oscillator as THE internal clock (nominally 1MHz)), I can tell you that the frequency varies dramatically and visibly (on a blinking-LED-like program) depending on supply voltage; perhaps 60% going from 3V to 5V...

Figure 1-2 in this application note shows the 8 MHz sensitivity to supply voltage for an Atmega8: Atmel-2555-Internal-RC-Oscillator-Calibration-for-tinyAVR-and-megaAVR-Devices_ApplicationNote_AVR053.pdf It's on the order of 10% but certainly significant. It indicates the full range temperature sensitivity is of similar magnitude. This doesn't directly address the question of what happens under moderately well controlled voltage and temperature, but improving four orders of magnitude seems really unlikely.

Funny, I'm designing a test circuit for this very purpose right now. I'm testing the reliability of the watchdog RC oscillator in power down mode, both for longer periods of time and 24 hours for the ATtiny10 (extremely small, 1 kb mc, not programmable by the arduino IDE yet. But it's awesome). The setup is:

An ATtiny10 powered by one single CR2032 battery, running a code that puts it into sleep mode for 24 hours in 8 second intervals. When it wakes up, it fires of a pulse through one of its IO-pins. The pulse triggers an interrupt on an ESP8266 connected to an RTC. It logs the time, calculates the interval and resets the ATtiny10. It also runs a server that dispays the list of intervals to incoming connections.
I will also test longer intervals and one running code.

Right now I have some problems getting the voltage provided by the ATtiny's IO pin to successfully provoke an interrupt on the ESP. The level is too low to be read as a pin change. If anyone has any idea how to change the level needed I would be very grateful! And naturally post my findings here.

What level is needed?
Buffer the signal with cd74HC4050, powered from the ESP8266 Vcc supply. Output will then be low and high that is compatible with ESC8266.

I think 3V is the trigger level, but the datasheet for ESP is not as detailed and extensive as those for AVR:s, so I reach that figure by trial and error. If anyone knows how to find out for sure, I'm all ears.

And thank you so much for the tip! I will check out the cd74HC4050 immediately.