Another 'internal RC oscillator' question

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

Read some of the threads on this topic, but didn't see any real data....

I'm using a ATtiny88 and just trying to understand the internal-oscillator variation that I'll see over temperature.

So if I OSCAL it at room temp (to +/- 1%), what kind of variation am I likely to see when I deploy it as a Xmas light controller outdoors at -10F ?

The spec has "TBD" data.... anybody have real data or an applicable Atmel spec?

I can design for the variation, but need to know what it will be....

tnx,

-mark

Mark
Elgin, IL (near Chicago)

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

I'd select a similar chip that has been characterised and use those values. Atmel probably uses the same oscillator circuit in most of their chips.

Leon Heller G1HSM

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

Quote:
The spec has "TBD" data...

The current datasheet has a graph (Figure 22-46) that shows it. It looks like less than 1% for just temperature variation. It is more dependent on VCC than temperature.

Regards,
Steve A.

The Board helps those that help themselves.

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

I think that any frequency variations that may occur in the worst case will not be visible in a cristmass light controller as the timing delays are in the range of 100's milliseconds up to seconds,also setting the prescaller dividing frequency,divides any error too. And finally,the hole application itself i think is not a strict timing application that may be affected by 10's of microseconds.

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

Thank you all for quick responses - this board is an incredible resource of helpful collective knowledge.

Koshchi - I'll be darned.... must have skipped right over that figure somehow. THANKS !

Leon - thanks, would fallback to your suggestion if not for Koshchi noticing that the data was IN THE PRELIM SPEC.

GeoElec - You're thinking of simple on/off timing not being critical, but I'm using the ATtiny88 to activate lights on different brightness levels, timed through the 120hz 1/2-wave. So if, for instance, the oscillator varies 5% over temp, even 20 brightness levels could be mistimed and (cumulatively) slip into the next 1/2-wave. So the oscillator 'slop' will determine how many brightness levels I can support...

Interesting that the only spec for the ATtiny88 is from March-2009.... ATMEL must not be shipping many of these to OEM's, eh?

THANKS ALL !!

-mark

Mark
Elgin, IL (near Chicago)

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

Atmel just seems to be slow on updating data sheets! That is not the only thing they have been "slow" on.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

Since you talk about controlling lamps at 120Hz, it is not the oscillator you need to worry about, but about being in sync with the mains frequency. Any oscillator frequency at any tolerance will do then, as you are not doing anything that really requires anything from the oscillator, like UART communications, right?

So feed the mains frequency to AVR.

Edit: As a hint, the mains frequency is not exactly 60.000Hz either, it will drift depending on the load which again is dependent on time of day (morning=lots of coffee makers and factories on etc, evening=everyone gets to sleep).

For example, in my country, currently here the mains frequency is 49.98Hz, and time based on mains frequency is 9.21 seconds behind wall clock time. Based on that, the mains time continues to lag wall clock time even more. And few minutes later, they have gotten up to 50.03Hz and lag is only 9.15 seconds.

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

Jepael - what you describe is what I'm doing - sync to the zero-crossings, then activate lights at intervals during the ensuing 1/2-wave. Bright lights get activated early, dim ones late, in the 1/2-cycle.

Problem is that during the 1/2-wave I am using the RC oscillator to determine the intervals.... so for instance, with 32 briteness levels, the 1/2-wave is divided into 32 intervals and if the oscillator is running just 3.5% slower than what the software assumed, the 32 intervals overrun the end of the 1/2-wave.... and lights turned 'on' in the 32nd interval end up being activated in the ensuing interval at full-bright instead of the dimmest setting...

Plenty of solutions to this.... but they get tricky and are not necessary if the oscillator is fairly stable.

Anyhow, that was the problem.... sorry to be so wordy.

-mark

Mark
Elgin, IL (near Chicago)

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

Okay, but the absolute frequency still does not matter, nor stability over temperature. All you need is a timebase that is stable between two zero crossings.

The frequency of oscillator or mains does not change much between zero crossings, so if you measure X oscillator ticks between zero crossings, the next zero crossing will also take place after approximately X ticks too.

So count the time (in ticks) from zero crossing to another with a timer counter, so you get a value of X. then divide your X to whatever time slots of resolution you want, you said 32. You can easily get even more resolution.

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

I had thought of other possible solutions, but yours is better than the ones that had quickly occurred to me....

Constantly measure the clk-cycles between AC zero-crossings, and divide it up on-the-fly into 32 timeslots.... kinda like that although it does add a bit of complication to the software, as opposed to just assuming the clock is stable enough (over temp) to just sync on zero-crossings and keep a constant /32 ratio.

After reviewing the temp-drift data, it does appear that I can just stick with a static /32, but I may implement your idea as a more 'elegant' solution.

Thanks for the review!

-mark

Mark
Elgin, IL (near Chicago)

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

Okay, your original idea of counting time from the zero crossing is good too, and I don't think the temperature drift is a big problem there, since last timeslot would be a bit too short or too long nobody would notice, but you have to take the initial accuracy into account if it is large. If you build two devices, one AVR might have +1% speed of nominal, and the other AVR might have a -1% speed of nominal, so the two AVRs may have to use different constant for timing the 32 slots.

But you can use a hybrid between the two. As I said earlier, you could measure the zero-crossing time every minute and use that value for the rest of the minute. Or you can track the timing all the time to get a good average. Or you can just measure time between last two pulses. You can also use mains frequency to calibrate the oscillator.

But the real point in this is that if you just divide by 32 and use the integer part, your timings may drift a bit. For example if time between zero crossing is 320 timer ticks, you divide that with 32, you get exactly 10 timer ticks per slot. If the zero crossing period is 319 timer ticks, dividing that with 32 results to 9 ticks per slot, so after 32 slots you only have counted 288 ticks and think you are done, when 288 ticks out of 319 is 90%, so your timings are 10% off! The error will get smaller if you use bigger timer tick counts, like 3200 timer ticks per zero crossing gets you 1% accuracy, or you could take the fractional value into account too.

My estimate is that 8MHz/120Hz is too big value so you have to use a prescaler of 4 at least with a 16-bit counter so you get about 16666 counts per zero crossing, so 1 count here and there is 0.1%.

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

Method works good Jepael, and it was an easy change.

Now constantly measuring the 1/2wave duration and setting next 32 intervals based on that.... seems to work quite well - hooked up a waveform generator to sim the AC signal and varied the frequency from 30hz to 90hz and system adjusted just fine.

Thanks for the good recommendation - turned out so simple in the end that I was kicking myself for not thinking of it!

Happy new year!

-mark

Mark
Elgin, IL (near Chicago)