Oscillator calibration. Or decallibration

Go To Last Post
58 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So if we’re using the internal oscillator, there is usually an associated calibration register.
If there is a reason for runnng “as fast as possible”, I might just pick the top value and throw it in there. I won’t know for fast it is till I measure it, but it should be the fastest I can get.
Likewise, if I want lower power, I might set the calibration to the lowest possible values...

Are ther non-obvious disadvantages to having the calibration register at “the extreme endpoints”?
Less stability perhaps?

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

Which chip ?

 

the PLL on a tiny85 would not like it.

 

some chips have a warning that single steps only can be 2%, so you should no just make it in one jump.

 

Make sure that it's not to fast for the chip (at the used voltage).

 

Temp and Voltage drift will be bigger, than normal.

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

sparrow2 wrote:
Which chip ?
+1

Modern ones have CLKPR so if it's about reducing speed to reduce power then the +/-30% (or whatever it is) that OSCCAL adjustment would allow pales into insignificance against a major change to CLKPR.

 

(of course you can't "speed things up" that way).

 

If your goal is the other way: "as much grunty power as I can squeeze out of this baby!", then why not simply attach an "overclocking" crystal to the thing and drive it to the limit?

 

As we all know the truly useful use of OSCAL is making your UART or RTC accurate ;-)

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

Power saving is best done with SLEEP or CLKPR.

Fast running could be done with OSCCAL but I suggest that you test it very carefully.    I doubt if the RC will be happy at the extreme ends.

 

I overclock Xmegas with PLL to 62MHz without any problem (as a hobbyist)

Brad overclocks even faster.

 

Obviously what is fine for a hobbyist is unwise (tm) for a commercial product.    Especially since there are plenty of other chips with faster spec.

 

David.

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

westfw wrote:
So if we’re using the internal oscillator, there is usually an associated calibration register. If there is a reason for runnng “as fast as possible”, I might just pick the top value and throw it in there. I won’t know for fast it is till I measure it, but it should be the fastest I can get. Likewise, if I want lower power, I might set the calibration to the lowest possible values... Are ther non-obvious disadvantages to having the calibration register at “the extreme endpoints”? Less stability perhaps?

 

Less stability I'd call more obvious, than not 'non obvious'.

Also obvious to watch out for, are the setting exceeding the device rating, and the setting varying with PVT.

I recall another thread where someone was pulling an AVR a long way up the re-calibrate cure, and they 'ran out of graph' on some process/date codes.

Atmel (of course) designed these to trim the centre variants, so the outer limits are going to be (much) more of a lottery.

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

westfw wrote:
I might just pick the top value and throw it in there.

There have been fairly thorough threads on this.  As I recall, there may be other subsystems clocked by the main oscillator that may be thrown off.

 

Echoing the others:  Which model/generation?  What supply voltage level?

 

sparrow2 wrote:
some chips have a warning that single steps only can be 2%, so you should no just make it in one jump.

Also discussions in the past.  a)  Isn't the dire warning dealing with the external clock?  b)  If dangerous, then why do people load the factory value to OSCCAL at app startup?  What if >>that<< is off more than two percent?

[edit] re a), Mega88PA datasheet

When applying an external clock, it is required to avoid sudden changes in the applied clock fre-quency to ensure stable operation of the MCU. A variation in frequency of more than 2% ...

 

Who-me wrote:
Less stability I'd call move obvious, not 'non obvious'.

Not obvious to me.  [I think I've been lambasted on this before.]  At which OSCCAL value do we start seeing "less stability"?

 

LOL -- which is easier -- try to dig out those past threads, or start working through all the claims again?

 

Anyway, as mentioned just slowing down the main clock may not be the best power saving approach.  In fact, it is usually a "good thing" to run as fast as possible to be able to get to deep sleep faster.  The answer will depend on your particular app and calculated power budget numbers.

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Wed. Feb 13, 2019 - 09:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

sparrow2 wrote:
some chips have a warning that single steps only can be 2%, so you should no just make it in one jump.

Also discussions in the past.  a)  Isn't the dire warning dealing with the external clock?  b)  If dangerous, then why do people load the factory value to OSCCAL at app startup?  What if >>that<< is off more than two percent?

 

I recall reading somewhere that the CPU will always execute

a NOP correctly even when changing the clock speed.  So if

you follow a write to OSCCAL by some minimum number of

NOPs, the clock will settle and you can then continue at the

new speed.

 

--Mike

 

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

Who, me?!?  Is this implicitly what indirectly tells us that OSCCAL cannot be set to whoopee level?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

theusch wrote:
LOL -- which is easier -- try to dig out those past threads, or start working through all the claims again?

https://www.avrfreaks.net/forum/...

This thread mentions many of the topics brought up here.  Unfortuantely the link in the OP of that thread to a prior discussion is broken.

 

"temporary instability" mentioned here: https://www.avrfreaks.net/forum/...

 

More considerations on older generations: https://www.avrfreaks.net/forum/...

theusch wrote:
Anyway, cranking up the speed with OSCCAL on a Mega128 may not be the best long-term solution. The datasheet warns that flash & EEPROM writing can fail when high OSCCAL values are used.

 

david.prentice has mentioned a couple times about cranking the clock ~50% with OSCCAL; one mention https://www.avrfreaks.net/commen...

In that thread, AVR053 is referenced:

maximax wrote:
According to AVR053 - Figure 2-2 the maximum achievable frequency is just shy of 13MHz.

 

https://www.avrfreaks.net/commen...

DocJC wrote:
One might ASSUME, (sometimes dangerous to do so), that this warning about abruptly changing the clock would apply to other clock sources as well, and that it just never occurred to the data sheet writers that someone would do so...

 

Actually, that thread has all the back-and-forth.  We could continue to pull out one post at a time...

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Yes,   I expect that you might get 4MHz - 13MHz from the 8MHz RC.   The core should operate correctly.

You only need to worry about the RC oscillating.   And I would expect it to work throughout the OSCCAL range.   But it is your responsibility to test it.

 

The EEPROM is self-timed from a separate RC.

ADC, USART etc are clocked from the OSCCAL system RC clock.   4-13MHz is within spec.

 

David.

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

"The EEPROM is self-timed from a separate RC" - what RC is that and what AVR model?

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

david.prentice wrote:
The EEPROM is self-timed from a separate RC.
Nope.  It's the calibrated RC oscillator:

 

 

 

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Oops. I should have checked the datasheet before making wild assertionns.
I was thinking of the Watchdog timer.
.
The EEPROM timing @13Mhz is going to be longer than in-spec EEPROM @20Mhz.
.
I am not sure what the physical requirement is for changing the state of an EEPROM cell.
Is it a minimum time or is it an internal erase-program-verify loop with timeout?
.
The first 8051 flash programming could either be done with a fixed cycle time or by polling for completion.
Like you do with 24Cxx or 25Cxx EEPROM chips.
.
All the same. If your app never writes to EEPROM, fast RC should not matter.
If you want to write, slow down OSCCAL to 8Mhz until completion.
.
David.

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

Thanks for digging up the old threads; I couldn't figure out what to use for a search (although I guess OSCCAL would have worked pretty well.)

 

  >>  Less stability I'd call move obvious, not 'non obvious'.

Not obvious to me.

Nor to me.   I mean, it's an RC oscillator, right?  Shouldn't that be pretty stable regardless of R and C?  People push oscillators made from basic gates from blinky speeds to multiple MHz...  (for the cases where there's a PLL or something involved, it's more obvious...)

 

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

I agree. I would guess that you have a fixed on-chip C and a fixed on-chip R with a programmable on-chip R.
The effective RC has a limited range. Far smaller range than most PLL.
.
The obvious experiment is to test until failure e.g. external clock for EEPROM, core etc.
And test RC for frequency stability, failure, ...
.
You can do what you like as a hobbyist.
.
David.

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

Just to make it clear:

On a chip osc. you don't just have a R and a C.

 

The tolerance of R and C is very big on a chip (like the input pullup resistor can be 2x and 1/2 X), but 2 resistors on the same chip scale well so the design is very different than the way you would do it. 

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

I am aware that R, C tolerances are very big on a silicon chip. But the R can be laser trimmed or extra Rs can be switched in and out. Either at manufacture or with User accessible registers.
.
Modern MCUs have pretty accurate RC oscillators. Plenty good enough for UART and sometimes good enough for USB.
.
The important question is whether the extreme limit of the RC exceeds the allowable clock. e.g. can OSCCAL achieve > 20Mhz?
.
David.

Last Edited: Thu. Feb 14, 2019 - 10:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But on chips like this they are good by design, no laser or other things.

 

At test they programe the best value.

 

I guess for 10% chips they only test some, and 2% all.

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

I would guess that OSCCAL is a resistor ladder.   No need for complex laser trimming.    The OSCCAL calibration value will be determined at Wafer-test.   

 

They must test every die on the Wafer.   Ok,   adjacent dies will have similar characteristics but there is little to be gained by omitting tests.    Of course some tests may be done on the Wafer and some on the packaged chip.

 

Yes,   the Silicon oscillator design will determine the temperature, voltage, ... stability.

I guess that modern Silicon design is "better" than the first AVR RC silicon.

But resistor ladders have been integrated on silicon for decades.    A User accessible OSCCAL is not modern technology.

 

Please note.    I just make wild assertions without prior investigation.    My working life was milking cows.    Not semiconductor design.

 

David.

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

sparrow2 wrote:
The tolerance of R and C is very big on a chip

You sparkies are getting down into the good stuff.  But I think my query is a bit simpler:  The "less stability" WAS MENTIONED.  Remembering that this discussion deals with cranking up the AVR8 internal oscillator to whoopee with a high OSCCAL value, then:

1)  The same R and C are used when OSCCAL is 128 and when the OSCCAL is 255, I would think.  Is that your point, with the mention of the resistor ladder?  That the whole OSCCAL mechanism is done through switching in a different resistor?

2)  Yes, sparrow, the internal oscillator doesn't have great nominal accuracy.  And it will vary with supply V and temperature.  But will those variations, the curves in the datasheet, change with OSCCAL value?

3)  What will become "less stable"?  What would those symptoms be?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I guess it's ok to say now when there is no Atmel and it's so long ago (and I guess I already have told some of it).

 

Back in the Atmel 8051 days I was the first in DK to get Atmel die's. And the problem for them was that die's normally wasen't testet ,it was cheaper for atmel NOT to test the wafer, but just mold all chips and test later.(read at a cheaper place)

 

 

 

 

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

Whether you test at the Wafer or after packaging is a matter of practical convenience.

If a die fails on the Wafer,  there is little point in packaging it.

 

On the other hand,  you still have to test the final packaged product and write the Signature Row.

Perhaps it is easier to package every die before any tests.

 

I have never seen a Fabrication plant.    According to gchapman,   some wafers go to a separate factory for test and packaging.

From sparrow2's experience,   that is what happened to the 8051.

 

David.

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

david.prentice wrote:
The EEPROM timing @13Mhz is going to be longer than in-spec EEPROM @20Mhz.
I'm not sure what you're driving at.  If you're suggesting that EEPROM writes are timed using whichever oscillator has been selected for the system clock, that's not the case.  Regardless of system clock (external, RC, WDT, crystal), the RC oscillator is used to time EEPROM and flash writes.  If the RC oscillator is not also the system clock, then it is switched on, the EEPROM write is timed, and then the RC oscillator is switched off again.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

My argument was completely WRONG.

 

Yes,   if the EEPROM takes 3.3ms @ 8MHz RC,  it will only have 2.03ms @ 13Mhz.   Which is significantly shorter.

Especially when #12 advises that 8.8MHz is the safe limit for RC.  i.e. allowing 3.0ms for an EEPROM write.

 

It should be easy enough to test.   I can use a 20MHz crystal as system clock.

Then vary OSCCAL.  And time for completion.

 

I don't even have to worry about changing fuses.   OSCCAL will still vary the EEPROM timing.    Anyone can test on an Arduino.    And calculate the RC frequency.

 

Incidentally,   if the AVR designers had used the WDT RC for EEPROM timing it would be safe from User interference.     Of course the WDT RC is not accurate.

 

David.

Last Edited: Thu. Feb 14, 2019 - 02:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wrote a simple sketch.    It should run on any AVR with OSCCAL.    Note that micros() has some latency but it shows the range of RC frequency as you alter OSCCAL.    It shows a typical range from 4.4MHz to 14MHz.   And the EEPROM write actually succeeded at 14MHz (which is well beyond the datasheet advice i.e. limit of 8.8MHz)

uint8_t eeprom_var EEMEM;  //a typical EEPROM location

void setup()
{
    Serial.begin(9600);
    Serial.print("Factory Calibration for OSCCAL = ");
    Serial.println(OSCCAL);
    for (int cnt = 15; cnt < 256; cnt += 16) {
        OSCCAL = cnt;
        write_ads_val(&eeprom_var, 0x55);
        write_ads_val(&eeprom_var, 0xAA);
    }
}

void write_ads_val(uint8_t *ads, uint8_t val)
{
    uint32_t t;
    t = micros();                 //4us resolution
    eeprom_write_byte(ads, val);  //start write
    while (EECR & (1 << EEPE)) ;  //wait for completion
    t = micros() - t;             //perhaps some ISR() latency
    Serial.print("writing 0x");
    Serial.print(val, HEX);
    Serial.print(" took ");
    Serial.print(t);
    Serial.print("us ");
    Serial.print("OSCCAL = ");
    Serial.print(OSCCAL);
    Serial.print(" RC = ");
    Serial.print(8.0 * 3300 / t);
    Serial.print("MHz ");
    uint8_t c = eeprom_read_byte(ads);
    Serial.println(c == val ? "good" : "bad");
    delay(1000);                 //allow Serial to drain
}

void loop()
{
}

David.

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

westfw wrote:

Thanks for digging up the old threads; I couldn't figure out what to use for a search (although I guess OSCCAL would have worked pretty well.)

 

  >>  Less stability I'd call move obvious, not 'non obvious'.

Not obvious to me.

Nor to me.   I mean, it's an RC oscillator, right?  Shouldn't that be pretty stable regardless of R and C?  People push oscillators made from basic gates from blinky speeds to multiple MHz...  (for the cases where there's a PLL or something involved, it's more obvious...)

 

At first glance it is "an RC oscillator", but looking at the stability curves, shows Atmel have a lot of additional compensation work going on in those oscillator blocks.

That means they have carefully tracking tempcos, which will be centered on the nominal average  and move away from that, and the tracking will get worse.

 

 

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

Who-me wrote:
looking at the stability curves,

What stability curves are those?  Can you post curves that show this instability with a high OSCCAL value?

 

Perhaps you need to define what you mean by instability here.  Are you referring to the temperature/supply charts in the datasheet?  I wouldn't call them instability.  If the frequency wasn't consistent under the same environmental conditions -- I'd call that instability.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I am new to the forum I do not know if I should create new thread. Here is my problem. I ran a clock using avr and it has delay of 15 minutes in a day. What does it mean? F_CPU constant is 8MHz. Data sheet range is 7.3MHz to 8.1MHz. Should I set 105 which is (15/24*60)(8) => 1−0.9895833 -> 7916666.4 Hz.
(7.91-7.3)/(8.1-7.3)*128 -> 105. Should I set OSCCAL 105=0x69H.

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

What is the AVR clock source? Note that if you are using the internal RC it can be as much as 10% off. That is 100,000 parts per million inaccuracy. In 24 hours it could be as wrong a 2.4 hours either way. So 15 minutes is actually pretty good.

 

If you switch to a typical crystal you can expect something between 50 to 200 ppm accuracy. That is between about 4.32 and 17.28 seconds per day.

 

if you want real accuracy you can get a temperature compensated TXCO - they can be accurate to about 1 part per billion which equates to about 100us per day.

 

After that you need to look at something that gets regular, accurate time updates from atomic clocks. Things like DCF77 or GPS etc. If internet connected there's also thing likes NTP

 

So how accurate do you want your clock?

 

BTW if you really are using int RC then you are right to mention OSCCAL which can be used to calibrate it to get it more accurate - but to do that you need to calibrate against an accurate timing source.

 

On the whole, for alarm clocks an so on a 50-200ppm crystal is probably enough. Either clock the whole AVR from such a crystal or maybe just put a 32.768kHz "watch crystal" on the asynchronous timer and use that either to keep time itself or to calibrate the int RC to make it more accurate.

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

15 minutes in a day is just 1% error, that's to be expected from the internal oscillator. You really can't fix that with OSCCAL, IDK the exact size of OSCCAL steps, but you will never get an accurate clock from the internal oscillator.

It's to sensitive to voltage and temperature changes. You need an external crystal to get a reasonable accuracy.

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

Thank you I get the need for better accuracy sources. What I cannot understand is when we set OSCCAL, are we setting the current frequecy the RC clock is running or the compensation we want to be.

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

The OSCALL value comes preset from factory with a good value, that varies from chip to chip due to manufacturing process variability. So the value itself if kind of meaningless, but you can try do adjust it better against an external crystal.

There is an appnote about this I think.

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

Which AVR is this? If a "new" one (since about 2005) it will have a CLKOUT fuse and a CLKO pin. Set the fuse then monitor the pin with a scope to see the exact frequency the chip is running at. Then adjust OCSCAL by single steps one way or another and see the affect on the CLKO.

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

OSCCAL adjusts the RC oscillator.    It is not a linear function.

But you can look at the typical curve in the datasheet to determine the typical Hz variation per OSCCAL unit.

 

Then read the Factory Calibration value of OSCCAL.   And adjust OSCCAL value by the appropriate number of units.

 

The RC is fine for many projects.   e.g. 1% accuracy.

The RC is never going to be accurate enough for RTC (Real Time Clock)

 

HF crystals are cheap.  32768Hz crystals are cheap.   Achieve 20ppm - 50ppm accuracy.

Anything better costs money or complexity.

 

David.

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

Clock I built using 8535's and their "RTC" clock input ran about seven and a half seconds per day slow (on a 32kHz Xtal).  Not bad - less than one in 10,000 - but far from the crystal spec of parts per million.  It was stable, though, and with a calibration routine (every now and then it jumps a second) it keeps time well enough.  It's also highly temperature sensitive.  If you want to make a clock, get a real RTC chip.  Use a big cap (1F or so) as a battery backup as a bonus - most RTC chips have a Vbat input.  S.

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

32kHz crystals are designed for a specific parallel capacitance.

TOSC pins do not need external capacitors.

 

Does your 8535 RTC have external capacitors?

If the effective load capacitance is higher than the crystal spec capacitance,  the frequency will be lower.   Your RTC loses time.

 

If the crystal is mounted close to the TOSC pins,  the external stray pcb capacitance will be trivial.    The on-chip TOSC circuit should work fine.

 

Long term stability is the most important consideration.

You can easily trim an imperfect frequency in software e.g. adjust counter at midnight.

More convenient than attempting to trim in hardware e.g. with trimmer capacitor.

 

David.

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

david.prentice wrote:

32kHz crystals are designed for a specific parallel capacitance.

TOSC pins do not need external capacitors.

 

Does your 8535 RTC have external capacitors?

If the effective load capacitance is higher than the crystal spec capacitance,  the frequency will be lower.   Your RTC loses time.

 

If the crystal is mounted close to the TOSC pins,  the external stray pcb capacitance will be trivial.    The on-chip TOSC circuit should work fine.

 

It does not have external caps.  It is mounted about as close as can be done (the 8535 is in a PLCC44 socket) on the same side.

 

david.prentice wrote:

Long term stability is the most important consideration.

You can easily trim an imperfect frequency in software e.g. adjust counter at midnight.

More convenient than attempting to trim in hardware e.g. with trimmer capacitor.

 

David.

 

My software calibration routine runs once every odd hour at fourteen seconds past the hour.  It adds the calibration value (in this case, 75 (for seven and a half seconds)) to an accumulator.  When the accumulator overflows, the clock skips forwards from xx:00:14 to xx:00:16 without stopping at :15 (where 'xx' is 'any odd hour').  Technically, it's a binary rate multiplier.  Occasionally I can catch it at it, while watching carefully.  S.

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

It sounds as if your hardware is correct and your software trim is sophisticated.

 

What is your crystal part number?

 

I suspect that the AVR TOSC expects a 12.5pF crystal

The Farnell "selector" has a wide range of SMD and through hole.

 

David.

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

Scroungre wrote:
It's also highly temperature sensitive.  If you want to make a clock, get a real RTC chip.  Use a big cap (1F or so) as a battery backup as a bonus - most RTC chips have a Vbat input.
Abracon has an RTC that periodically calibrates its RC oscillator from the crystal with a backup that can be a MLCC.

Abracon has a DTCXO RTC that's 8ppm max or 30ppm max with a supercap backup.

 

Abracon Products - Standalone Real Time Clocks (RTC)

AB08XX / AB18XX Real Time Clock Family - ABRACON | Mouser | Mouser (RTC by sub-threshold FETs, Abracon's die source for these : Ultra-Low Power RTC | Ambiq Micro)

AB-RTCMC-32.768kHz-EOZ9-S3-DBT ABRACON | Mouser (DTCXO RTC)

 

"Dare to be naïve." - Buckminster Fuller

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

I tried the sketch above and tried to set automatically good OSCCALs having the shortest eeprom-write time as best OSCCAL but become very slow. Maybe the cnt of 16 has big granularity. I changed to cnt+=8
No improvement. I print the factory default and added 4 for compensation and now for the last 8 hours difference is 3minutes. Why the sketch used cnt+=16?

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

Looking at Figure 29-368.ATmega328P: Calibrated 8 MHz RC Oscillator Frequency vs. OSCCAL Value in the datasheet

 

The typical slope is 2MHz / 40 units.   i.e. 50kHz per unit or 0.62%

If your calculations showed that your "8MHz" was 7.8MHz you can add 4 to OSCCAL

Or if it was 8.2MHz,  you can subtract 4 from OSCCAL.

 

Note that there is a horrible discontinuity at OSCCAL=128.

So be very careful with any "adjustment" that straddles 128.

 

Note that your best RC adjustment is 0.62% but this can still vary with voltage and temperature.   Look at the other typical curves.

 

Simple answer:  buy a crystal.

Your 4 minutes in 24 hours is 185 ppm

HF crystals are ~ 30 ppm

LF crystals are ~ 15 ppm

 

Since crystals are very stable,  you can improve 30 ppm with a software tweak.   Possibly achieve < 5 ppm.

 

David.

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

The whole point about calibration is that you can't possibly guess what adjustment is needed as it's likely to be different for each AVR (and also depends on temperature and Vcc). That is why you have to calibrate against a known timing reference (which may be your watch!).

 

If you say you tried OSCCAL+4 and you dropped from 15 minutes of inaccuracy to 3 minutes then maybe try a +5 adjustment instead. If, however found that instead of -3 minutes that changed it to +2 or something then you have to accept (because OSCCAL only takes integer values) that you cannot hit +0 exactly.

 

So in that case determine what the error actually is with the best OSCCAL you can find then add code to correct the clock.

 

So if you find the closest you can get is +2 minutes per day then a rather course correction to that is that each day at midnight you adjust the clock by -2 minutes. But that is quite a large jump and might be noticeable to the user (just before midnight the clock is going to be the best part of 2 minutes wrong!). So you divide the -2 minutes (-120 seconds) adjustment into small steps. -120 second per day is -5 seconds per hour (120/24). So now maybe set things up so that the thing makes a -5 s adjustment every hour. You could break that down still further and make a -1 second adjustment every 12 minutes. That way the clock would never appear to be more than 1 second wrong.

 

Or you could spend $0.10 and buy a crystal.

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

clawson wrote:

Or you could spend $0.10 and buy a crystal.

 

You can make a software adjustment like Scrounge.

In my experience,   a $0.10 HF crystal is pretty stable.

And a $0.10 32768 Hz Watch crystal is even better.

 

David.

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

Thanks all. My main problem is lack of pins. A crystal needs two pins. What is the experience of crystal on a single pin?

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

kigeb wrote:
What is the experience of crystal on a single pin?

 

That would be an external oscillator (external clock in AVR speak).

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

kigeb wrote:
Thanks all. My main problem is lack of pins. A crystal needs two pins. What is the experience of crystal on a single pin?

 

A "full-can oscillator" will cost more.  Say USD$1. 

They're bigger (take up more board space). 

They provide (synchronized) clock drive for lots of other chips

They work beautifully (even more stable than bare crystals), but get the RIGHT PIN for your clock input. 

 

Had a system where the wrong XTAL pin was used, and it worked fine on a 32k chip (mega3290) - and then quit working on an otherwise 'pin-compatible' 64k chip (6490).  Had to respin the board for that little oversight.  Oops.  S.

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

CLKPR impact on time library for power saving. I checked the library I am using depends on millis(). No issue it think.

Last Edited: Mon. Sep 23, 2019 - 08:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kigeb wrote:
Thanks all. My main problem is lack of pins. A crystal needs two pins. What is the experience of crystal on a single pin?

 

There are shiploads of 'crystal on a single pin'

 

https://www.digikey.com/products/en/crystals-oscillators-resonators/oscillators/172?k=oscillators

 

That shows prices start at 67c/1+, for 50ppm accuracy. 

 

Or, from China, cheaper

https://lcsc.com/products/SMD-Oscillators-XO_364.html

 

 

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

A "full-can oscillator" will cost more.  Say USD$1. 

They're bigger (take up more board space). 

 They also tend to consumer a depressing amount of power.  :-(

 

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

westfw wrote:

A "full-can oscillator" will cost more.  Say USD$1. 

They're bigger (take up more board space). 

 They also tend to consumer a depressing amount of power.  :-(

 

 

Yes, older ones were > 10mA, but newest models are better.

Clipped Sine OSC are usually sub 2mA and the new Jaunch Oscillator JO22 spec Icc vs MHZ and Vcc, and can give 20MHz at 1.4mA  and the  SiT8021 MEMS oscillators can give ~ 300uA at 16MHz

 

 

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

Still on calibration, from datasheet
"CAL7 bit determines the range of operation for the ocillator. Setting bit 0 gives the lowest frquency range, setting bit 1 gives the highest frequency range. The two ranges are overlapping OSCCAL=0x7F gives higher frequency than OSCCAL=0x80". I could not understand it. Can some body decode it for me? For example what is the lowest range equivalent of 168. After doing some thinking, 168-128=40. => 127-40=87.

Last Edited: Thu. Sep 26, 2019 - 05:53 PM

Pages