58 posts / 0 new

## Pages

kigeb wrote:
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.

What they are saying, is that the curve is non-monotonic, with a 'step' mid-way, so you really have two curves in play., and that could vary from device to device,

Hopping over the boundary, would need to be done with care, if you ever need to do it.

Ok, I saw the graph now. My mind is blocking when seeing graph in datasheet. Now the frequency of almost all the range between 128 to 208 is less than OSCCAL of 127. Thank you.

We are missing what you really want to do.

If it's something like a UART where you need something like better that 3% (or 4% or 2% depends) it's fine to calibrate.

But it's a function like a clock just measure the error and build the software so it can adjust Like if 1 sec. is 7852547 clk and not 8000000, that way you can adjust way finer than with OSCCAL.

If you have a regulated Vcc and the temperature that is relative stable you make ok clock in the ballpark of 10-20 sec a day (100-200ppm).

If your power come from the grid you could get 50/60 Hz (or 100/120) as a adjustment signal.

My idea is compensate using bluethooth manually once per day or two. For example for 8MHz. maybe using the difference b/n real and avr time used to estimate frequency. then using OSCCAL, (8.0-calculatedfrequency)/(20MHz/40unit) => get the approximate units needed. Then calibrate the clock.

kigeb wrote:
My idea is compensate using bluethooth manually once per day or two. For example for 8MHz. maybe using the difference b/n real and avr time used to estimate frequency. then using OSCCAL, (8.0-calculatedfrequency)/(20MHz/40unit) => get the approximate units needed. Then calibrate the clock.

That will sort of work, but will be constrained by the coarse jumps in the trim which are some portion of 1%.

If you are checking once a day, you may be better to do a SW calibrate, and run your time-keep from a fixed calibrate value.

example: Running 8MHz to a 5ms tick, is nominally /40,000, so LSB there is 25ppm, and if that's not enough, you can run a slower rate multiplier correction where another byte of correction, is good enough to trim even a crystal oscillator.

bluethooth

If you have  Bluetooth I would expect it have a good clk can't you use that ?

Don't make jumps, rather make a "very" slow PLL(or PID), so if it's behind inc speed etc.(don't need to be fancy ind or dec the value should work)

(If it's used as a controller it also have the benefit that it never jump over a time something should happen :) )