Accurate 8-bit timer using 16MHz crystal

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

I created a program that toggles an LED every 1 second. To achieve high accuracy, I used CTC mode in this way:

16MHz crystal (main MCU crystal oscillator), prescaler = 256, OCIE2A = 249, on every match variable timer2_cmc increases by 1, MCU sleeps between each timer tick.

When timer2_cmc is >= 250, MCU toggles LED.

When I simulate program, Stop Watch exactly increases 1000000us each time simulator hits led toggle breakpoint. So theorically, my code should be very accurate.

But when I compare the result on real hardware with time.is website, after several minutes (~20) it is noticeable that LED toggles aren't fully synchronous with time.is. Looks like LED toggle periods are slightly less than 1 second.

What is the problem? Is it because of crystal oscillator tolerance or I made a mistake in my code? Please don't suggest other crystal frequencies as solution.

Here are some parts of my code:

... Stack configuration

;Initialize Timer 1
    ldi buffer,(1<<wgm21)
    sts tccr2a,buffer
    ldi buffer,(1<<cs21)|(1<<cs22)
    sts tccr2b,buffer
    ldi buffer,249
    sts ocr2a,buffer
    ldi buffer,(1<<ocie2a)
    sts timsk2,buffer
    sei

... Set PORTB as output, Set sleep mode

loop:
    com status				;Invert state
    out portb,status        ;Here is LED toggle breakpoint
wait:
    in buffer,mcucr
    ori buffer,(1<<bods)|(1<<bodse)		;Disable Brown-Out Detection while sleep
    out mcucr,buffer
    andi buffer,~(1<<bodse)	;Also
    out mcucr,buffer
    sleep
    cpi timer2_cmc,250		;Clear carry if timer2_cmc >= 250
    brcs wait				;Go to wait if carry is set
    clr timer2_cmc			;Reset timer
    rjmp loop

timer2_cm:
    push buffer
    in buffer,sreg
    push buffer
    inc timer2_cmc
    pop buffer
    out sreg,buffer
    pop buffer
    reti

 

Slow and Steady!

Last Edited: Tue. Jan 21, 2020 - 10:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you sure this is a crystal and not a ceramic oscillator? e.g. the UNO R3 uses the latter, with 3000 PPM. That can be as much as 10 seconds per hour.

"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

joeymorin wrote:
ceramic oscillator
ceramic resonator?

MEMs Oscillators Make Inroads | Mouser

By Paul Pickering, Mouser Electronics
[1/4 page]

Table 1 compares these various options.

joeymorin wrote:
e.g. the UNO R3 uses the latter, with 3000 PPM.
likewise on mega328PB

Pololu - A-Star 328PB Micro

 


on sale :

Arduino Uno Rev3 | Arduino Official Store

 

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

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

joeymorin wrote:
e.g. the UNO R3 uses the latter.

I'm using a UNO CH340 Clone and what i see is more like a crystal oscillator than a ceramic resonator. My UNO is like this.

Slow and Steady!

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

Run a test using idle sleep mode, this mode keeps the xtal osc running during sleep, so the wake up time for xtal is much faster.

If your time is now ok, then your not accounting for the time (sut fuse) it takes a xtal to wake up and be stable enough to run the mpu.

Jim

 

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

gchapman wrote:

ceramic resonator

Yes.  Slip of the finger.

"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: 2

Do you get the same result when the MCU is not put into sleep mode?

 

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

Also, if those sleep checks don't find an issue, double check that you do not have a "one-off" error (I did NOT check your code).  That is a very common flaw.....so you think something happens every 41378 counts, but  does it start at 0 or or 1?  Also, things like > versus  >= .....makes a difference!

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

Tried both changing and disabling sleep mode; no difference. Also changing values make timer more inaccurate.

Note: I'm using power-save sleep mode. Oscillator is running and timer is ticking during sleep.

Slow and Steady!

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

Have you measured the actual crystal frequency?

Ross McKenzie ValuSoft Melbourne Australia

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

Be careful if you try to measure the oscillator  frequency. Putting a scope probe on the crystal can shift the frequency. Turn on the CKOUT if your MCU has it and measure that. M328x has it.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

valusoft wrote:

Have you measured the actual crystal frequency?

So do you think the problem is from oscillator and my code is correct? I don't have any oscilloscope or a multimeter with frequency test mode. Probably I'll test it in my school lab if I find an oscilloscope there!

Slow and Steady!

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

pajuhesh80 wrote:
Note: I'm using power-save sleep mode. Oscillator is running and timer is ticking during sleep.

That doesn't sound right. On most AVRs Power-Save turns off the Main Clock leaving only the secondary clock (and watchdog) running.

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

N.Winterbottom wrote:

On most AVRs Power-Save turns off the Main Clock leaving only the secondary clock (and watchdog) running.

I think you are talking about power-down mode. It is different with power-save mode.

Refer to ATmega328P datasheet, 9. Power Management and Sleep Modes.

Slow and Steady!

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

pajuhesh80 wrote:

...Probably I'll test it in my school lab if I find an oscilloscope there!

 

But how will you know if the oscilloscope is correct? Welcome to the world of Metrology.

 

First things first is to quantify how much in error you think the frequency is. You say after 20 minutes you see an error. How much of an error? Knowing that you can assign a percentage figure. Knowing that you can start to narrow it down.

 

A cheap crystal is going to be better than 100 ppm (part per million) or 0.01% or 1 second in 2.8 hours.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

pajuhesh80 wrote:

I think you are talking about power-down mode. It is different with power-save mode.

 

Show your code where you setup the sleep mode.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

If you use equipment, you need a good freq counter with a solid timebase (as most are "decent", many are excellent).  If you use a scope, it must have a digital timebase...an old analog  "scanner" scope won't cut it. You also need an extended memory or zooming so you can see whether you are at 216.8 divisions or 216.6 divisions (or 2.168 vs 2.166 div) ...a freq counter is prob better/easier.  Don't forget to check for one-off errors.

 

But when I compare the result on real hardware with time.is website, after several minutes (~20) it is noticeable that LED toggles aren't fully synchronous with time.is

What is the latency between your PC & them?  I'd use my PC clock, or something  local....though it's not likely it would be so far off that it would affect a 1 second blink...how much error are you seeing? 10ms? 100ms?  500ms?

 

What exactly is your xtal osc?  Part number? Specs?

 

A cheap crystal is going to be better than 100 ppm (part per million) or 0.01% or 1 second in 2.8 hours.

Just 2 days ago, I was stocking up on some Xtals from the 'bay...was about to order when I noticed they were 300 ppm!!  I changed sellers & paid 2 cents more and got 50 ppm parts (or at least they say so, to keep me smiling).

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Tue. Jan 21, 2020 - 09:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I get about 0.12 seconds of plausible error out of a 100ppm 16MHz XTAL over 20 minutes.  That would be easily detectable by eye.

 

Suggestion for the OP:  Put it in the fridge for those 20 minutes.  If it's drastically worse (or better!) you have a crystal problem, because crystals are somewhat thermally sensitive (or play a heatgun over it (gently!), and see if that changes anything...).  They make thermally-controlled crystal oscillators (usually called TXCOs) but they do cost more, both in money and power;  In return, you get a lot more precision (and accuracy).  S.

 

PS - I had a lousy little ~36KHz watch crystal that I tried to use to make a clock.  It lost seven seconds a day - less than one in 10,000 (==100ppm(!)), not bad for some things, but atrocious for a clock.  Clocks are hard!  S.

 

Edited to add PPS:

PPS - Get a full-can oscillator instead of a loose crystal with your own caps on it.  They too are much more stable.

Last Edited: Tue. Jan 21, 2020 - 10:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm pretty sure the sleep mode is OK. I set SM0, SM1 and SE.

Brian Fairchild wrote:
But how will you know if the oscilloscope is correct?

You are right. Probably I'll test with more than one oscilloscopes.

I need to know something: Is my code (in post #1) correct? I'll take care of oscillator errors later. If you need my complete code, it is attached to this post.

Also, let me describe the hardware I use again: ATmega328P on a UNO Clone (CH340) with a 16.000 MHz crystall oscillator.

Attachment(s): 

Slow and Steady!

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


pajuhesh80 wrote:

I think you are talking about power-down mode. It is different with power-save mode.

Refer to ATmega328P datasheet, 9. Power Management and Sleep Modes.

 

I'm confused...

 

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

Look at the Power-save row. clkASY and Timer Oacillator are enabled. This is the mode which I use.

Slow and Steady!

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

You are right. Probably I'll test with more than one oscilloscopes.

Save the pain & use a freq counter...they are made to tell the difference between  17.68772 MHz & 17.68775 MHz. If you use a meas function on a scope, they often offer a limited number of digits.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

pajuhesh80 wrote:
Look at the Power-save row. clkASY and Timer Oacillator are enabled. This is the mode which I use.
Neither of those is the system clock!

 

clkASY is the async clock, and the timer oscillator refers to TIMER2, which >>can<< be configured to use clkASY.  Note (2) in the figure:

2. If Timer/Counter2 is running in asynchronous mode.

... is important.  You have not configured TIMER2 for async mode, and you can't if you're using an external crystal (or external clock) for the system clock.

 

EDIT:  Ah:

The Timer/Counter2 can be clocked both synchronously and asynchronously in power-save mode.

So there are conflicting claims in the datasheet.

 

"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]

 

Last Edited: Tue. Jan 21, 2020 - 05:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
;Initialize Timer 1

That's not true.  You're configuring TIMER2, not TIMER1.

 

I've skimmed your code, and looks OK for running the ISR at 250 Hz, and your logic for testing timer2_cmc seems OK for loop: at 1 Hz.

 

But when I compare the result on real hardware with time.is website

That site just pulls time from your local computer's clock.  While you can expect that to be reasonably accurate, any number of things can affect it, including deliberate drift used by your operating system to resynchronise your computer's clock with an NTP clock source.

 

 

"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

I recommend that if you are doing anything involving real-time to use a hardware solution.  For example this application, which requires the measurement of exactly one second, should use a DS3231 RTC (real-time clock) controller IC.  These DS3231 ICs are found used on inexpensive module PCBs (usually with included coin cell battery) selling on eBay for only 1.50 to 2.50  dollars/euros each.

 

  Unless you are making many hundreds or thousands of the same design, it is usually cheaper to implement a hardware solution, than it is to take MANY hours trying to determine why a CPU is losing several seconds a day.   Say your time as an embedded-systems designer cost your employer $30 an hour in salary and benefits.  If you spend more than a hour debugging and testing the software-based RTC, then you could have bought a  ten-pack of DS3231 module boards from eBay at less cost.  The DS3231 modules usually also come with a 4K byte serial EEPROM on the board, as well.

 

I put a DS3231 module on every AVR design that I make.  I have set these DS3231 clocks on prototypes, put the prototype aside for a year,  restarted the board, and have the DS3231 be correct within a minute.

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

Simonetta wrote:

I recommend that if you are doing anything involving real-time to use a hardware solution.

 

... scroungre edit ...

 

I put a DS3231 module on every AVR design that I make.  I have set these DS3231 clocks on prototypes, put the prototype aside for a year,  restarted the board, and have the DS3231 be correct within a minute.

 

Agreed.  They deal with thermal correction as well. 

 

I just wanted to throw in a suggestion of a "super" cap (say, one Farad or so) as an alternative to the coin cell.  Doesn't last as long - but is near-infinitely rechargeable.  S.

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

OP states that in the simulator the code runs perfectly.

In the real world, he notices a drift.

Either OP notices a drift that is not there

or the real world differs significantly from reality.

 

OP should find out how fast is CPU is actually running.

An ISR that activates once every 16,000,000 cycles should not be a problem.

The ISR should toggle the LED once in a hundred activations.

Use time.gov .

Refresh time.gov .

Wait for next toggle and note the time.

Wait for 99 toggles and refresh time.gov .

Wait for next toggle and note the times.

The CPU frequency is 16*10**10/(difference in noted times).

10,000 seconds is almost 3 hours,

so OP might want to scale it down a bit.

 

Iluvatar is the better part of Valar.

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

skeeve wrote:

or the simulator differs significantly from reality.

 

FTFY.  smileywink  S.

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

Agreed.  They deal with thermal correction as well. 

 

Accuracy ±2ppm from 0°C to +40°C    ...DS3231 pretty hard to beat!

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

pajuhesh80 wrote:
I think you are talking about power-down mode. It is different with power-save mode.

Refer to ATmega328P datasheet, 9. Power Management and Sleep Modes.

 

No I was writing about Power-Save as this is the mode I have always used. My designs always included a 32.765kHz watch crystal which clocked TIMER2 in asynchronous mode. TIMER2 was then used to keep Date&Time at very low power consumption.

 

I have learnt something here however: What I didn't realise was that if TIMER2 is clocked synchronously (ie from the Main clock) then Power-Save does not disable the Main oscillator. In fact it seems Power-Save maintains whichever oscillator is currently required for TIMER2.

 

None of this helps you solve your problem however.

 

I think your code should work.

Perhaps you have detuned your crystal with the wrong capacitors or the wrong fuse settings or even have a bad crystal.

 

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

joeymorin wrote:
You're configuring TIMER2, not TIMER1.

Oh! Sorry! I forgot to change that.laugh

joeymorin wrote:
That site just pulls time from your local computer's clock.  While you can expect that to be reasonably accurate, any number of things can affect it, including deliberate drift used by your operating system to resynchronise your computer's clock with an NTP clock source.

You are wrong. each time I refresh this website, it synchronizes its time with accurate atomic clocks. Read "About" in that website.

Simonetta wrote:
For example this application, which requires the measurement of exactly one second...

My application doesn't need exactly one second, but exactly one or some (2-5) millisecond.

Slow and Steady!

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

pajuhesh80 wrote:
You are wrong. each time I refresh this website, it synchronizes its time with accurate atomic clocks. Read "About" in that website
I am not wrong.  You did not mention refreshing the site until now.

 

Most time sites work like that.  They fetch the time from the site's time source, then clock from the local PC.  If you refresh, the time is again fetched.

 

For example time.gov as mentioned in #27, as well as https://nrc.canada.ca/en/web-clock/

 

The NRC site at least gives you an indication of the error due to network round-trip time.

"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]

 

Last Edited: Wed. Jan 22, 2020 - 04:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

pajuhesh80 wrote:
My application doesn't need exactly one second, but exactly one or some (2-5) millisecond.
I don't understand. Are you saying a 2000-5000 ppm error is acceptable? If so in 24 hours the time could be out by +/- 7.2 minutes.

 

A typical crystal might have an error something like 250-300ppm. That represents 0.43 minutes (26 seconds) in 24 hours.

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

Note: 1 second per day is 11.57 ppm, 1 sec per year is 0.0317 ppm....

You can also count AC cycles, depending on your application

 

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

clawson wrote:
Are you saying a 2000-5000 ppm error is acceptable?

No. I mean timer steps. not ppm. for example, in the program I posted above, the timer period is 4ms and 250x4 = 1000ms.

Some news:

1- There was an old CRT oscilloscope in my school. But I didn't find its probes! I reported it to our school principal.

2- I switched from power-save sleep mode to idle sleep mode. It caused some mess with timer prescaler and clock source in some situations (main problem isn't fixed yet). And I found something else about this mode: in older MCUs like mega32, it stops system clock source like power-down mode. m328p is an exception.

3- I changed some parts in my code to achieve 1ms timer steps instead of 4ms. It is attached to this post if you are interested.

4- I put my UNO in fridge (-20°C) and tested again! Looks like results are better (less drift). So probably the problem is from crystal oscillator.

 

Attachment(s): 

Slow and Steady!

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

1- There was an old CRT oscilloscope in my school. But I didn't find its probes! I reported it to our school principal.

That is rather useless for any high accuracy timing measurements (unless perhaps, you are comparing one known precision signal against an unknown).   

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

pajuhesh80 wrote:
2- I switched from power-save sleep mode to idle sleep mode. It caused some mess with timer prescaler and clock source in some situations (main problem isn't fixed yet). And I found something else about this mode: in older MCUs like mega32, it stops system clock source like power-down mode. m328p is an exception.
If you are talking about sleep modes do not consider the mega32 anyway. At the very least make it a mega32A but a mega328p is a much better platform. AVRs that have a "P" on the end are "picoPower", they have additional features that makes them more suited for sleeping battery apps.

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

Scroungre wrote:
FTFY.  smileywink  S.
Diagnosis is not fixing.

The principle applies to even the most successful autopsy.

 

HDJ

Iluvatar is the better part of Valar.

Last Edited: Thu. Jan 23, 2020 - 04:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

OK, real world measurements.

 

The code (ported to C)....

 

#include <mega328p.h>
#include <stdint.h>

volatile uint8_t timer2_cmc;
unsigned char tmp;

interrupt [TIM2_COMPA] void timer2_compa_isr(void)
{
	timer2_cmc++;
}


void main(void)
{
    // Timer/Counter 2 initialization
    // Clock source: System Clock
    // Clock value: 62.500 kHz
    // Mode: CTC top=OCR2A
    // OC2A output: Disconnected
    // OC2B output: Disconnected
    // Timer Period: 0.592 ms
    ASSR=(0<<EXCLK) | (0<<AS2);
    TCCR2A=(0<<COM2A1) | (0<<COM2A0) | (0<<COM2B1) | (0<<COM2B0) | (1<<WGM21) | (0<<WGM20);
    TCCR2B=(0<<WGM22) | (1<<CS22) | (1<<CS21) | (0<<CS20);
    TCNT2=0x00;
    OCR2A=249;
    OCR2B=0x00;

    // Timer/Counter 2 Interrupt(s) initialization
    TIMSK2=(0<<OCIE2B) | (1<<OCIE2A) | (0<<TOIE2);

	DDRB = 0xff;

	#asm("sei")

	/* Prepare the sleep in power save mode*/
	SMCR |= (1<<SE) | (1<<SM1) | (1<<SM0);

    TCNT2 = 0;

	while (1) {

        PINB = 0xff;				//Invert status

        do {
            /* Disable brown out detection in sleep */
            tmp = MCUCR | (1<<BODS) | (1<<BODSE);
            MCUCR = tmp;
            MCUCR = tmp & (~(1<<BODSE));

            #asm("sleep");

        } while (timer2_cmc < 250);

		timer2_cmc = 0;			//Reset timer
    }
}

 

 

Measurements made by a timer/counter checked against a GPS referenced TXCO...

 

Oscillator...16,000,943Hz

Period of 1Hz signal...999,941us

 

That's an exact division ratio of 256x250x250

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

Cool!

 

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

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

Brian Fairchild wrote:

OK, real world measurements.

...

Oscillator...16,000,943Hz

Period of 1Hz signal...999,941us

 

That's an exact division ratio of 256x250x250

 

To save someone else doing the sums, that's an error of...

 

0.1s over 30 minutes

5.1s in a day

31mins in a year

 

...from a cheap no name 16MHz crystal.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

Brian Fairchild wrote:
Period of 1Hz signal...999,941us

 

Any chance you could do that with XTL in low power mode (or if it was low power mode full swing).

 

low power

 

http://eleccelerator.com/fusecal...

 

full swing

 

http://eleccelerator.com/fusecal...

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

ron_sutherland wrote:

Brian Fairchild wrote:
Period of 1Hz signal...999,941us

Any chance you could do that with XTL in low power mode (or if it was low power mode full swing).

 

Making CKSEL3 = 1, with no other changes, shifts the 16MHz to 16,001,359Hz.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

The solution seems to be measure the CPU frequency and rewrite the code for that frequency.

Of course, if the CPU frequency is not stable enough, a hardware change will be needed.

Iluvatar is the better part of Valar.

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

The one number I can't see in the datasheet is the current consumption, when using power save mode, but when you keep the main xtal oscillator running.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

Brian Fairchild wrote:
Making CKSEL3 = 1, with no other changes, shifts the 16MHz to 16,001,359Hz.

Perhaps changing the two caps to a different value would help.

22pf to 18pf or 15pf

Jim

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

Brian Fairchild wrote:
Making CKSEL3 = 1, with no other changes, shifts the 16MHz to 16,001,359Hz.

 

Thanks, although it was not what I was expecting, I have been using a crystal that wants 20pf load capacitance (e.g., 27pf||27pf + 7pf_stray), and I measured better timing in low power mode (It takes multiple days, with time corrections, plus one junk computer).

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

 I measured better timing in low power mode

There are many chances there to fool oneself.  How about temperature & general drifting back and forth?  Maybe its drift just happened to occur mostly when you were in low power mode.   If you repeated the tests (alternating) that would give more statistical confirmation.   

 

How much difference did you measure for low/high pwr?  0.1 sec in a week?   

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

avrcandies wrote:
How much difference did you measure for low/high pwr?

 

I recall that the crystal was within specification +/-30ppm in low power and out of specification near 100ppm in full swing. It was a kluge, and data for statistics would take months, I probably need to add it to some of the long term things I have blinking outside, but maybe that should be indoors. Sadly the bootloader can not set the fuse, so I have to change the fuse manually. I can feel this is not going to happen soon.

 

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

If you do not have the frequency you love,

love the frequency you have.

Iluvatar is the better part of Valar.