Tuesday, April 24, 2012

ATMega Oscillator Stability

Now that I have my HP 5328A frequency counter up and running, I figured I'd show you the contrast between the stability of the internal RC oscillator built into the ATMega328 (the brains of the Arduino) and the external 16MHz crystal that you usually need to use with it.

Video:


Datasheets referenced in the video are for the ATMega328P and a random 16MHz crystal I found on Digikey.  I bought the specific crystal used for this demo on eBay, so I know almost nothing about it, but these crystals are usually rated in the range of 20-50ppm.

The two avrdude commands I used were:
avrdude -p m328p -c usbtiny -U lfuse:w:0x86:m -U hfuse:w:0xd9:m
avrdude -p m328p -c usbtiny -U lfuse:w:0xa2:m -U hfuse:w:0xd9:m

This really demonstrates how both oscillators, but particularly the internal one, are very sensitive to temperature changes around the microcontroller.  This is why my counter's oscillator is contained in a small oven, such that it's held at a specific elevated temperature and doesn't change temperature along with the room.  Another compensation option is to not try and control temperature (which takes a lot of power), but instead merely compensate for it.  High-end real time clocks such as the DS3232 do this, by measuring the ambient temperature and trying to compensate the crystal in the other direction.  It's better than nothing, but this does still introduce uncertainty.

When buying this counter, I specifically looked for one with the HPIB  option on the back, because it means that I will eventually be able to connect this meter up to my computer and take these measurements over a LONG period of time.  Once that is possible, we can start asking more subtle stability questions about better oscillators, such as real time clocks, and even my Rb reference.

13 comments:

  1. Do you have a plan for how to use the HPIB interface? I recently worked on a HP 8753C network analyzer and used agilents GPIB to usb interface and pyvisa, which proved really easy to get working.

    /Johan

    ReplyDelete
    Replies
    1. Once I can use HPIB to collect measurements at regular intervals long-term, I plan to use it to measure the period between the GPS 1pps and a Rb 1pps, and plot the change over the course of hours or days.

      $550 is way beyond my price range as an amateur, but home-brewing an HPIB to USB adapter shouldn't be too hard; I'll just need the free time to do it (and access to a copy of Fisher's HPIB book).

      Delete
  2. I use a Prologix GPIB/USB bridge (there is now a GPIB/Ethernet bridge available too). But at $149 USD, the current model is getting a bit too pricey IMO:

    http://prologix.biz/

    A really great resource that is compatible with the Prologix bridge is the free GPIB Toolkit from KE5FX:

    http://prologix.biz/

    In the past, I have seen some people hack-up their own GPIB/USB type bridges using a micro-controller (links evade me). If you go this route, I suggest you try to make it compatible with the Prologix device where possible as that seems to be a pivot point for many users.

    Regards, David

    ReplyDelete
  3. Sorry, the GPIB Toolkit from KE5FX is here:

    http://www.thegleam.com/ke5fx/gpib/readme.htm

    David

    ReplyDelete
    Replies
    1. Sooo... I found an NI 4882 ISA GPIB card for $3 yesterday at Weird Stuff. I haven't tested it yet, but I typically get a 75% yield from their junk bins, so I'm guardedly optimistic.

      Delete
  4. could you please post the picture of that oven?
    I guess the same relates to attiny? how do I assess the error of my speedometer working form 8Mhz internal oscillator, if it grabs the period between 2 pulses on each wheel rotation, and the wheel perimeter is 1.34m? will it be the same 10%? I guess not? v=l/(t±10%). I still guess using external oscillator is better if I want to use my speedometer within the temperature range of -30ºC to 40ºC.
    btw, one more idea for the blog - could you please investigate the problem of powering microcontrollers in the automotive environment? How do we protect the inputs from sensors? (specifically Hall sensors) which are sourced from the same 3.3V power source as the whole microcontroller?

    ReplyDelete
  5. Great job. I've always erred on the side of using an external crystal only because I didn't have a way to measure the frequency accurately. I'll share this video with ANYONE who asks "should I use the internal frequency?"

    ReplyDelete
    Replies
    1. Yep. But then again, even with 5kHz jitter in an 8MHz clock, it's pretty easy to justify that being ok. Knowing is half the battle, right?

      Delete
  6. okay, i put it on paper. If I am not mistaken in my calculations, with the actual speed of 56.25 km/h in my setup (as measured with external oscillator), it would range from 55,6 to 56,8 km/h (provided that AVR allows for no more than 10% fluctuations). This seems quite reasonable, considering the fact that external quartz in automotive environment would become the major part exposed to interference in this noisy environment.
    What I would like to learn is what is how these fluctuations will affect the ADC.

    ReplyDelete
    Replies
    1. I wouldn't be able to say anything without an actual model of the oscillator drift, but I would have expected 10% oscillator uncertainty to give 10% velocity uncertainty...

      A good rule of thumb about the performance of the ADCs on AVRs is that if you care about how accurate they are, don't use them.

      Delete
  7. 1. The uncertainty depends upon the methods of velocity measurements. I just used 8MHz internal oscillator and the 16-bit counter with /64 divider, the wheel length was 1.35 m and I had 2 pulses per wheel rotation. With this model, with 5000 ticks per halfrev I got the above accuracy. with external quartz each tick would last 8.00µs. With the internal oscillator (if we can trust the datasheet) it would range from 7.92µs to 8.08µs. ((1.35/2)meters/5000*tick)seconds in km/h would give 55.6 to 56.8 km/h. For my application it is not that much to think of an external quartz. As you see, it's not 10% uncertainty.

    2. it's not a rule of a thumb. I need to assess its accuracy to decide whether I want to continue with it or not. Probably, it's not a difficult task considering that you have an atomic clock/counter at hand (like yours), a stable variable reference voltage source, an accurate voltmeter and some ice and a heat gun to cool down and warm up the microcontroller ;-)

    ReplyDelete
    Replies
    1. Embarrassingly enough, I actually have no good way to measure voltage. I know one of my volt meters is out a good 2-3%, and have never gotten the other one in the same room as a good reference since the day I pulled it out of a dumpster.

      I do kind of want to do a whole set of demos checking an AVR's performance, but I'm still missing a few pieces of equipment in the data path, and am definitely missing the time for it this summer.

      Delete
    2. I guess, once I get home this summer and get to my mega8, I'll try a simple test, sending the readings of the voltage of an AAA cell to UART while heating/cooling the avr. Probably, I'll see the fluctuations of voltage, but I won't have an opportunity for proper monitoring the avr's frequency or its actual temperature.

      Delete