Temperature stability of AVR 8-bit processors

[jgalak]

I Would like to use an AVR processor (starting with an Atmega328p, may try to get the code down to an ATTiny eventually) to generate signals in the 1-2kHz range that need to be relatively stable.  The project is intended to go into a high altitude balloon (and may be a Cubesat some day, but that's more aspiration than anything else). 

As such, it's important that the signal remain stable across a wide temperature range. Probably a low of -30 to -50C and a high of +50 to +80C. 

So how stable are these chips at those temperatures, especially in terms of clock speeds?  Most seem to have 3-4 options for regulating the clock speed: external oscillator, external crystal, internal oscillator, and for some, a low power internal oscillator.  Are any of these significantly more stable over these temperatures than others?

[wraper]

Quartz crystal oscillator is much more stable than the rest. External oscillator stability does not have any relation to MCU itself. It can be the same quartz crystal oscilator, TCXO (Temperature compensated crystal oscillator), OCXO (oven-controlled crystal oscillator) or even atomic clock.

[slugrustle]

Page 422 of http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-42735-8-bit-AVR-Microcontroller-ATmega328-328P_Datasheet.pdf
gives internal 8MHz RC oscillator tolerance vs. temperature and voltage for the ATMEGA328P. At 3V, it ranges from ~7.7MHz at -40C to ~8.2MHz at 85C. Page 369 of the datasheet says a user calibration of this oscillator can reach +/-1% from -40C to 85C. Page 396 has watchdog oscillator Frequency vs. Temperature, which ranges from 111kHz @85C to 118kHz @-40C for 3.3V supply. I am totally guessing, but is this the 128kHz internal oscillator? 

External oscillators can be much more accurate.

The -50C temperature might be more difficult to reach than -40C. The ATMEGA328P has a -55C to 125C maximum operating temperature range (datasheet page 365), but most of its characteristics are only rated from -40C to 85C or 105C. This MSP430
https://www.digikey.com/product-detail/en/texas-instruments/MSP430F2274MDATEP/296-25813-1-ND/
is rated from -55C to 125C. It costs $14.60 for a reason.

Here is a TCXO rated for +/-500ppb from -55C to +95C:
https://www.digikey.com/product-detail/en/abracon-llc/AST3TQ-10.000MHZ-2/535-12446-ND/
http://www.abracon.com/Oscillators/AST3TQ.pdf

Note that it takes up to 4mA at 10MHz output into a 15pF load and wants a 3.3V supply. This woul be used as the external oscillator for your microcontroller. This device family (Abracon AST3TQ) was the only in stock TCXO at digi-key rated to -50C or lower.

Since you said "relatively stable", this standard crystal oscillator might do:
https://www.digikey.com/product-detail/en/ecs-inc/ECS-3953M-080-AU-TR/XC1444CT-ND/
http://www.ecsxtal.com/store/pdf/ECS_3951_53m_AU.pdf

It is rated for +/-100ppm from -55C to 125C and can draw up to 16mA at 3.3V (8MHz version). Again, it would be the external oscillator for your micro.

I picked 3.3V oscillators operating at 10MHz and below because the ATMEGA328P needs 4.5V-5.5V supply to go above 10MHz.

This ordinary crystal (not oscillator):
https://www.digikey.com/product-detail/en/ecs-inc/ECS-80-20-5PXDU-TR/XC1526CT-ND/
http://www.ecsxtal.com/store/pdf/CSM_7X_DU.pdf

Is rated for +/-100ppm from -55C to 125C. The tricky part about bare crystals vs. oscillators is the board layout and choosing the right loading capacitors. If your micro can output its clock on a separate pin, this is a great way to measure your clock and make sure the crystal is loaded correctly. Measuring the crystal directly will change its behavior due to oscilloscope probe capacitance.

Be aware that the temperature range listed in the parts search on places like Digi-Key may have the "Storage Temperature", which is usually quite broad, instead of the "Operating Temperature", which is what you really want. Always check the datasheet.

[jgalak]

The trade off seems to be power consumption, another major concern.  Internal oscillators take less power.  May just need to experiment on things....

[2N3055]

There is no experimenting.. If you need stable it must be crystal or external high stability oscillator.

Internal oscillator is not good enough for RS232 communication.. It can drift many percent up or down...
And every single processor will be different...

If you don't need it to be fast you can use 32 kHz RTC crystal for low power.
But do you need a processor at all ? Do you need only frequency generator?

CD4060 with 32768 Hz crystal will give you 2kHz, 1kHz, 500 Hz, 250Hz .......... And power will be very low, much lower than AtMega, dominated by load on output...

[wraper]

Internal oscillators will drift by at least few % within temperature range. Check the datasheet.

[RES]

You could adjust the internal RC oscillator at runtime by measuring the temperature (case, use internal temperature sensor) and update OSCCAL (within 10%)
Another way to get a more stable pulse width of the (USART) communication is by adjusting/correcting the baudrate using the internal- or an external temperature sensor.
http://www.avrfreaks.net/sites/default/files/m32osc.jpg

[jgalak]

CD4060 with 32768 Hz crystal will give you 2kHz, 1kHz, 500 Hz, 250Hz .......... And power will be very low, much lower than AtMega, dominated by load on output...

I'm not sure that gets me what I need.  I'm looking to generate AFSK signals, which require a 1200Hz tone and a 2200Hz tone, switching between the two at the correct timing.  I'm planning on the uC generating the tone and switching between the two tones, as appropriate.  How does the CD4060 help with that?

[2N3055]

No, in that case CD4060 cannot help you...
You can use uC for that, you will need crystal (and even a crystal will have to be good one with your temperature range)

But what you're trying to do is not so easy because of environment you are aiming...

Search the Internet, there are designs for high altitude balloon loggers and beacons, as well as open source microsatelites...
Study those designs and you will see.. Very low temperatures, even radiation when you start getting high...
Many design challenges...

[jgalak]

Search the Internet, there are designs for high altitude balloon loggers and beacons, as well as open source microsatelites...
Study those designs and you will see.. Very low temperatures, even radiation when you start getting high...
Many design challenges...

Sure are.  I'm trying a  variant on a design others have used in a HAB, we'll see if I can pull it off.

[2N3055]

Well good luck!

[Kalvin]

You could adjust the internal RC oscillator at runtime by measuring the temperature (case, use internal temperature sensor) and update OSCCAL (within 10%)
Another way to get a more stable pulse width of the (USART) communication is by adjusting/correcting the baudrate using the internal- or an external temperature sensor.
http://www.avrfreaks.net/sites/default/files/m32osc.jpg

I second this one. Sweeping the temperature and measuring the frequency of a signal derived from the internal oscillator as a function of temperature you can create a lookup table which could be used to adjust the oscillator at runtime using the on-chip temperature sensor. You can create the calibration data by placing the device into a [insulated] box in order to slow the temperature change rate, placing the box into a freezer and measuring the frequency as a function of the temperature. You can simultaneously measure the on-chip temperature and and print the temperature data to UART port. Combining the on-chip temperature reading with the measured frequency data you will get the calibration data. Probably you may need to iterate this few times to get it right. As each part will perform differently, you need to create calibration data for each individual [atmega328] chip you are going to use. If this doesn't work well enough, you can always use the TCXO or OCXO as others have already suggested.

[slugrustle]

The trade off seems to be power consumption, another major concern.  Internal oscillators take less power.

Using an ordinary crystal (not an external crystal oscillator) should take similar active run current to the internal oscillator at the same clock frequency. It will probably take quite a bit longer to start than the internal oscillator.

[coppice]

The trade off seems to be power consumption, another major concern.  Internal oscillators take less power.

Using an ordinary crystal (not an external crystal oscillator) should take similar active run current to the internal oscillator at the same clock frequency. It will probably take quite a bit longer to start than the internal oscillator.

That shouldn't be true in any device designed for low power operation. Although a decent 32kHz crystal oscillator should be well below a microamp these days, an internal oscillator might be an order of magnitude below that.

[Kalvin]

Alternative/addition to my previous post: If the power consumption of the external crystal oscillators is a problem, you could probably still use external crystal oscillator to calibrate the on-chip oscillator during flight when the temperature changes. Just design the circuit so that the microcontroller can enable and disable the external oscillator's power supply as needed ie. when the on-chip temperature changes. Then you can use the external oscillator to calibrate the on-chip oscillator as needed and minimize the overall power consumption. This will add some complexity in the software, but it will reduce the power consumption. No free lunch here.

[wraper]

If current consumption is a major concern, then AVR MCU is not a good choice to begin with. The same goes for lowest operating temperature range. However AFAIK for high altitude balloons usually have some sort of internal heater, therefore if you reduce power consumption of electronics, you will need to waste more power in heater.

[jgalak]

So I just had an interesting thought.  The project will have a GPS reciever.  It seems I should be able to use that to adjust the internal calibrator, no?

[wraper]

So I just had an interesting thought.  The project will have a GPS reciever.  It seems I should be able to use that to adjust the internal calibrator, no?

You can, however IMO it's unlikely that you'll better than say 0.2% short term. Internal RC oscillator in AVR is quiet crap even for MCUs in average. And if there will be GPS module, I don't see how using internal RC oscillator will save any power on the grand scheme of things.

[ogden]

So I just had an interesting thought.  The project will have a GPS reciever.  It seems I should be able to use that to adjust the internal calibrator, no?

Consumption of GPS receiver in tracking mode is around 20mA (uBlox data), AVR in idle (CPU halted) consumes around 1mA (12MHz @ 3.3V). Therefore I suggest to not bother about CPU consumption. uBlox receivers (maybe other as well) have programmable clock output which is synchronized to GPS - you can use that to clock your CPU at virtually any frequency you want.

[jgalak]

Can the GPS receivers not be put to sleep?  I don't need constant positioning, waking it up every 30 seconds, or even every few minutes, seems quite reasonable.  The uBlox has various sleep modes (I'm still reading the datasheets), and any can just be turned off with a GPIO pin controlling a FET or something.

So run off the internal RC, wake up the GPS, say once a minute, measure time for 1 second to adjust RC, get position data, turn off GPS.  Process and transmit data.  Repeat.

Would this not work better than having a crystal running the whole time? 

The uBlox NEO-M8M has a typical tracking current of 4.8mA. 

I've been poring over the Atmega328p datasheet trying to figure out the difference in current between an external crystal and the internal RC oscillator.  So far, can't find it.  There's characterization curves for the Internal RC, but not the crystal-based clock.  Is that dependent on the crystal?

[wraper]

There is no way AVR internal oscillator will be precise enough for 30 seconds, especially if temperature will be changing.

[ogden]

I don't need constant positioning, waking it up every 30 seconds, or even every few minutes, seems quite reasonable.

Yes, reasonable indeed. Make sure you test such mode first and measure max & average power draw. After wake-up receiver shall go through acquisition phase which takes extra time and extra current as well.

So run off the internal RC, wake up the GPS, say once a minute, measure time for 1 second to adjust RC, get position data, turn off GPS.  Process and transmit data.  Repeat.

Honestly I don't like idea to use AVR with (risky) RC oscillator calibration "tricks" just because AVR (oscillator) consumes too much. After all RC oscillator can drift away during long runs so you shall think about recalibration & stuff. Kinda weird engineering - pick inferior solution, then think how to improve it Better just use proper low power microcontroller with flexible clock system, like msp430, stm32L0 or similar. Then you can manage sleep states, oscillators, external clocks coming from GPS as you wish.

[ogden]

I've been poring over the Atmega328p datasheet trying to figure out the difference in current between an external crystal and the internal RC oscillator.  So far, can't find it.

RC oscillator (3mA @3V, 8MHz):
Page 380, Figure 33-5. Active Supply Current vs. VCC (Internal RC Oscillator, 8MHz)

Crystal (3mA @3.3V, 8MHz):
Page 379, Figure 33-2. ATmega328: Active Supply Current vs. Frequency (1MHz - 20MHz)

RC oscillator idle (~0.7mA @3V, 8MHz):
Figure 33-10.  ATmega328: Idle Supply Current vs. VCC (Internal RC Oscillator, 8MHz)

Crystal idle (~0.7mA @3.3V, 8MHz):
Figure 33-7.  ATmega328: Idle Supply Current vs. Frequency (1MHz - 20MHz)

[mikeselectricstuff]

There is another issue if minimum power is a concern and you're asleep most of the time - crystals have significant startup/stabilisation time, RC oscs are stable in a few cycles. In some cases it makes sense to run in RC mode until you need to do something timing-sensitive and only then switch to the crystal and wait for it to stabilise.

[martys]

Think insulation. Firstly, flights of balloons are usually short. What if the MCU circuit was well-insulated(double insulated) within a cylinder or box so that a minimal amount of heat exchange occurs, and it would not matter if a small amount of heat is added or lost or the circuitry could be held in extreme cold to a much warmer temperature by a tiny heater. This  could keep the temperature of the circuitry within a tightly controlled temperature range. It might even be that the time it would take the internal circuitry to wander out of temperature would take days without any heater, and by this time the balloon flight would be over. In this scenario the built-in 8-MHz MCU clock osc would be quite stable enough to achieve precise FSK tones generated by the MCU. Heat insulating materials can be very light in weight, vacuum is one good example.