Time Stability of Internal RC Oscillator

Go To Last Post
18 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Many thanks to the Freaks who helped out with initial questions about the accuracy of the internal RC Oscillator.

I've read AVR053 and successfully used the source code/procedure to calibrate OSCCAL.

My current question is about time-drift of the RC oscillator frequency. Reading the ATTiny85 datasheet,
I see the factory calibration of the RC oscillator is 10% and the initial OSCCAL value is burned into the signature area of the MCU. The datasheet futher states the accuracy of "User" calibration is 1% over -40 to 85C. I assume this means at a given temperature and voltage. Looking at the calibrated RC oscillator frequency versus temperature, I see the accuracy remains within 2% over 0-85C @ 5V.

Initial tests of two ATTiny85s show a factory OSCCAL of 0x55. At 25C and 5V, that turned out to be a frequency of 7.45MHz. Using the AVR053 calibration
procedure, I get an OSCCAL of 0x4C and a measured frequency of 7.97MHz.

Thus, AVR053 gets me adequate calibration. However, the difference in factory calibration and user calibration has me worried about potential time-drift of the RC oscillator. It seems that if the RC-oscillator is time-stable, then the factory calibration can be closer than 10%, more like 1-2%.
So, while it's easy to perform AVR053 calibration at time of device progamming and product creation, does anyone have any experience or knowledge about how the accuracy will remain over time? My concern is the accuracy could drift over years by more than 2% making my RS-232 transmission unreliable.

I'm comparing using a 8-pin PIC (yuk!) for the design soley for the reason the PIC datasheet shows a factory 1% accuracy at room temperature and 2% accuracy from -40-85C. This has advantage there is no worry to periodically consider recalibrating the PIC oscillator (indeed the PIC oscillator is not
able to be calibrated).

Does anyone have thoughts about the AVR RC oscillation maintaining a 1-2% accuracy over years?

Thanks once again.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I calibrate the OSCCAL every time the device is started. That should be much better than only calibrating it during production time and will also free space from the bootloader as the calibration routine may now be placed in the application area. I worked some days schrinking my osccal routine (below 90 bytes FLASH) before changing to this method.

Since my application may be used in- or outdor I think this aproach is much better.

/edit. Spelling

My favorites:
1. My oscilloscope, Yokogawa DLM2024.
2. My soldering iron, Weller WD2M, WMRP+WMRT.
3. JTAGICE3 debugger.

Last Edited: Sat. Oct 13, 2007 - 06:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This question came up at the PicoPower workshop. The RC oscillator should remain stable over time since the R's and C's used in the internal RC oscillator are based on the same technology used to create the R's and C's used throughout the IC.

Perhaps someone else that was at the Seattle workshop will be able to explain this more completely.

Tom

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The R and Cs should be stable because all the other R and Cs on the chip are made in the same process :? What if all those others are not such good R and Cs? I can imagine that for most R and Cs the value and stability aren't that important; except for the RC osc.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bengtr wrote:
I calibrate the OSCCAL every time the device is started...Since my application may be used in- or outdor I think this aproach is much better.
If that were possible, since my application requires at least 2% accuracy for RS-232 transmissions. However, my application will be running on an 8-pin AVR (or PIC) and I don't have the luxury of including an external calibration source (or, I wouldn't have posted the original message).

Thanks for your thoughts, though!

Kevin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Don't you receive anything?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

zoomcityzoom wrote:
This question came up at the PicoPower workshop. The RC oscillator should remain stable over time since the R's and C's used in the internal RC oscillator are based on the same technology used to create the R's and C's used throughout the IC.
Thanks for the specific feedback -- that is helpful. Did the question come up why factory calibration is so far off from user calibration for the RC oscillator (at least @ 5V & room temperature)?

I think I will ship the product with AVR's while at the same time monitoring the RC stability on a few ATTiny85's that I keep on my shelf. I just bought a PM6680B/TXCO that should help with initial calibration and frequency drift.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jayjay1974 wrote:
Don't you receive anything?
I'm sorry, is that question directed at me? I don't understand the question. My original post is how stable the internal RC oscillator will be over years.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
If that were possible, since my application requires at least 2% accuracy for RS-232 transmissions. However, my application will be running on an 8-pin AVR (or PIC) and I don't have the luxury of including an external calibration source

You do have the external RS232 transmissions that you receive. Have you thought of using this as a source of re-calibration? Obviously, you have to be calibrated initially in order to receive the data in the USART.

Tom

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kmr wrote:
jayjay1974 wrote:
Don't you receive anything?
I'm sorry, is that question directed at me? I don't understand the question. My original post is how stable the internal RC oscillator will be over years.

I mean, does your AVR receive any signals, like incoming RS232 or maybe any other frequent signal that might be suitable for recalibration? ;)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jayjay1974 wrote:
I mean, does your AVR receive any signals, like incoming RS232 or maybe any other frequent signal that might be suitable for recalibration? ;)
Sorry for being dense -- that's a good question. Unfortunately for calibration purposes, the answer is no.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

zoomcityzoom wrote:
You do have the external RS232 transmissions that you receive. Have you thought of using this as a source of re-calibration? Obviously, you have to be calibrated initially in order to receive the data in the USART.
Good thought, unfortunately no.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Did the question come up why factory calibration is so far off from user calibration for the RC oscillator (at least @ 5V & room temperature)?

Yes. The calibration and testing process happens in the oven at 85C and before the case is applied. The pressure needed to add the case can change things greatly. Though I believe they try and account for this, 10% is the best that they can guarantee. Once calibrated by you, it should remain fairly accurate.

With the RS232 in particular, this could still be problematic since the UBRR values can only get you within a certain percentage, depending on the cpu frequency. For applications that require RS232, I would suggest rather than calibrating the frequency to say, 8MHz, calibrate it to get your desired baud rate as accurate as possible.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Koshchi wrote:

Yes. The calibration and testing process happens in the oven at 85C and before the case is applied. The pressure needed to add the case can change things greatly. Though I believe they try and account for this, 10% is the best that they can guarantee. Once calibrated by you, it should remain fairly accurate.

Excellent, Steve -- that's exactly the information I needed.

Quote:
With the RS232 in particular, this could still be problematic since the UBRR values can only get you within a certain percentage, depending on the cpu frequency.
I'll be bit-banging the RS-232 output (the ATTiny series does not have UARTs). UBBR accuracy is a good point, though.

Edit: Spelling

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So, this is effectively an output-only device? Is it possible that your receiving program can perform the auto-baud to compensate for out-of-spec timings? I don't *think* that the PC serial port can be micro-tweaked, but *most* chipsets will deliver all the possible bit-rates available from the original divider frequency.

Alternatively, do you *have* to use RS232? Perhaps you could use a self-clocking signal such as Manchester encoding or biphase-mark encoding? That could be decoded either at the PC or by an add-on box (e.g. a USB adaptor with a small micro) if that would be an acceptable cost.

Neil

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One way to improve stbility against aging is to do a accelarated aging of the parts before using them. In most parameters change with the square root of time since production, so starting with an older part helps to get slower aging.
Faster Aging is done a higher temperatures (e.g. 100°C).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

barnacle wrote:
So, this is effectively an output-only device? Is it possible that your receiving program can perform the auto-baud to compensate for out-of-spec timings? I don't *think* that the PC serial port can be micro-tweaked, but *most* chipsets will deliver all the possible bit-rates available from the original divider frequency.
All good thoughts. Yes, output only. The product will be sold to be used with generic RS-232 input systems that I don't have control over.

Quote:
Alternatively, do you *have* to use RS232? Perhaps you could use a self-clocking signal such as Manchester encoding or biphase-mark encoding? That could be decoded either at the PC or by an add-on box (e.g. a USB adaptor with a small micro) if that would be an acceptable cost.
Another good point. The goal of the 8-pin device is to convert a complicated, untimed, bidirectional serial signal into a more accessible serial signal for end users. So, outputting another serial protocol that needs decoding defeats the purpose of the device.

But, Steve's point was that from Atmel the 1-2% user accuracy should hold over time. So, the AVR 8-pin device should be fine.

I'll also offer a 14-pin device that can use SPI for untimed serial access to eliminate timing issues.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kleinstein wrote:
One way to improve stbility against aging is to do a accelarated aging of the parts before using them. In most parameters change with the square root of time since production, so starting with an older part helps to get slower aging.
Faster Aging is done a higher temperatures (e.g. 100°C).
Thanks for the idea! I'll likely do some long-term frequency measurement with both "raw" and "cooked" devices.