Problem with clock accuracy.

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

I've been working on a clock that displays the time in hexadecimal, and so each tick of the clock is 86400/65536s or 1.318359375s. I decided to install an external crystal oscillator as using the internal clock I noticed that the clock was gaining quite a lot of time after a few hours, and was pretty noticeable even after only a few minutes. I know that the problem must have to do with the clock frequency because using the same code (with timing adjusted) on an ATmega168pb xplained board (with 16MHz external crystal on-board) it runs spot on.

 

So I programmed the fuses to use the external crystal, and adjusted the compare match value for a 1.024MHz system clock (CLOCKDIV8 is programmed, so the real clock speed is 1.024MHz). Now, using the external crystal with the new compare match value, it instead runs too slow! I mean, its kinda close, but it becomes noticeable after 10-20 seconds. The way I test it is using a desktop version I wrote, I set the time on the attiny clock to the desktop clock (in hexadecimal) and then let it run for a while then restart the desktop version to see if it is too fast or too slow. I do know that the desktop version isn't perfect because it isn't using interrupts, but I'm familiar with what the small error is, and each time the program is started the current time is calculated so it does start out correct.

 

Here's the hardware set up that I'm having issue with:

ATTINY2313a

8.192MHz external crystal (tolerance: 30ppm load capacitance: 18pf)

2 x 33pf 5% ceramic capacitors for crystal

 

What I think it could be, is that the crystal isn't running at the right frequency, but 30ppm should be way too accurate to become noticeable so soon. Could it possibly be that I'm using the wrong capacitor values? In the datasheet for the microcontroller it recommends 12-22pf caps for a crystal of this frequency, but the crystal itself says that it's load capacitance is 18pf, so I calculated the capacitance from that value using a formula I found C1 * C2 / C1 + C2.

 

Here are the fuse settings:

avrdude: safemode: lfuse reads as 7F
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as FF
avrdude: safemode: Fuses OK (E:FF, H:DF, L:7F)

Here's some relevant snippets from my code dealing with the actual time-keeping:

LINK TO FULL CODE:

http://pastebin.com/8Agr5eSP

 9 #define F_CPU 1024000UL

51 #define OCR0A_VAL   127
52 #define OCR1A_VAL   21092
53 #define OCR1A_SLIP  3

123 void init_timer(void)
124 {
125     /* -- Using 16 bit Timer1 -- */
126     // Clear TCCR1A
127     TCCR1A = 0;
128     
129     // Clock Select -- clk/64
130     TCCR1B = _BV(CS11) | _BV(CS10);
131 
132     // Clear on Compare Match (CTC)
133     TCCR1B |= _BV(WGM12);
134     
135     // Set Compare Match A Register
136     // Must slip clock every 4 matches to reduce drift
137     OCR1A = OCR1A_VAL;  // (1.31...s interval target)
138     
139     /* Output Compare Match A interrupt disabled until time is set */
140 
141     /* -- Using 8-bit Timer0 -- */
142     // Clear on Compare Match (CTC)
143     TCCR0A = _BV(WGM01);
144     
145     // Clock Select clk/8
146     TCCR0B = _BV(CS01);
147 
148     // Set Compare Match A Register
149     OCR0A = OCR0A_VAL;  // 1ms tick
150    
151     // Output Compare Match A interrupt enable (TIMER0/1)
152     TIMSK = _BV(OCIE0A);
153 }

307 ISR(TIMER1_COMPA_vect)
308 {
309     static uint8_t tick_acc;
310     static uint8_t slipped;
311 
312     /* 
313      * Every 4 ticks, slip clock compare register forward, a flag is set to
314      * indicate whether the clock has been slipped so the register can be
315      * reset to default but avoid doing this unless actually necessary.
316      */
317     if (tick_acc % 4) {
318         if (slipped) {
319             OCR1A = OCR1A_VAL;
320             slipped = 0;
321         }
322     } else {
323         // add to next compare match val to offset effects of clock drift
324         OCR1A += OCR1A_SLIP;
325         slipped = 1;
326     }
327 
328 
329     // Increment global time
330     ++g_time;
      
        // edited to fix error pointed out by dak664
        ++tick_acc;
331 }

Only thing that I can think of is that it's because I am using the wrong capacitors. What could it be?

This topic has a solution.

Last Edited: Fri. Aug 7, 2015 - 02:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think your capacitors are too big. Try more like 9pf.

 

I made a clock a while ago with an xMega and 16MHz crystal. At first it kept horrible time.

 

1. First mistake was a "fence-post problem." I'd forgotten to count 0 as a cycle, so I'd set my timer 1 tick too long.

 

2. Second mistake was 22pf capacitors.

 

Fixing these two got my clock within the 10ppm spec for the crystal and I was very pleased. Then, one of the freaks pointed out that I could adjust the timekeeping much closer by setting the timer one count shorter 238 out of 256 interrupts and wow, did that thing ever keep time! It's been shipped off to the user, and I haven't heard a thing about it since. It replaced a timer that drifted about 2 minutes per week. Of course, users don't notice when it does what it's supposed to do, only when it doesn't.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

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

Aside: % is a very costly operation - why not just count something up (++) and reset to 0 when it reaches 4?

 

Anyway what's all the slippage adjustment stuff about. If you pick the right crystal and the right CTC OCR value then you just get a tick every 1ms or 10ms or whatever you are trying to achieve and increment your 1ms/10ms counter. It should be as simple as that.

 

When I put the numbers into avrcalc.exe for 1.024MHz and 1000ms with /64 it says 0x3E7F (15,999) should given an exact 1000ms

 

I'm just trying to work out where:

#define OCR1A_VAL   21092

comes from exactly? What is your target tick rate? 1.024MHz/64 = 16kHz (62.5us). So 21093 ticks (which is what you get using CTC and OCR=21092) is 1.3183125 seconds. Why would you want interrupts at that rate?

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

I think your capacitors are too big. Try more like 9pf.

 

How did you come up with the value 9pf?

 

Also, what were the effects of 22pf, and why is this recommended in the datasheet if this is wrong? I was under the assumption that this was just a ballpark value and that the exact values depend on the exact crystal?

 

I guess I ought buy some 9pf capacitors and try that, i'll be damned if its still slow.

Last Edited: Fri. Aug 7, 2015 - 12:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

it's not because of the modulo. I am aware that modulo is very expensive. in fact, originally i was using bitwise AND (4 is a power of 2) but after some experimentation I found that avr-gcc was always optimizing it to a bitwise and instruction anyway and using mod is more clear. avr-gcc only uses code for an actual mod when the divisor isn't a power of 2, or isn't known at compile time. The reason this is done is to make up for the tiny bit of inaccuracy due to the exact OCR1A value I would need not being an integer (21092.75). After 4 interrupts, the extra 0.75 adds up to 3, which is added to OCR1A but only for the next interrupt.

 

I'm not actually trying to get an even "regular second". the value 21092 is to give the interrupt rate of 1.3183125 seconds, which you have confirmed that value should give me . The "clock" keeps time in hexadecimal where the time of day is represented as a single 16bit number. So on this clock, each tick, or "second" is actually 86400/65536 of one day, or 1.318359375 seconds. For some reason though, the actual time between interrupts is slightly less than that so the clock runs slow suggesting that the crystal frequency is off, or else there's some weird mistake in my code.

 

https://en.wikipedia.org/wiki/Hexadecimal_time

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

Not enough code is shown: where is tick_acc modified?

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

I just tried removing the caps completely, same thing. I can't tell if it's any "better" or not, but not good enough :\ In only about 2 minutes it loses 2 seconds .. after many hours or days that will add up enough to make it useless.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dak664 wrote:

Not enough code is shown: where is tick_acc modified?

 

good catch ... it isn't being. i just now fixed that, that code is only to correct a tiny amount of error by making every fourth "second" just a tiny bit longer but the error that I am seeing is way too large to only be caused by this. In fact, this is a recent addition, the same code (modified accordingly for the chip and it's 16MHz crystal) for an ATmega168pb xplained mini board is very accurate even without this clock slipping code.

 

I didn't post the full code originally, anyway here is a link to the the full code, with that mistake corrected. I didn't want to post all of it here because it's kinda long, people would have to scroll and wouldn't want to read it.

http://pastebin.com/8Agr5eSP

 

edit: fixing this seems to make it a lot more accurate ... I suppose that this was of more consequence than i originally thought when I originally replied since it would have actually been increasing OCR1A each and every time. I suppose letting it run long enough we would have eventually started to see some extremely short seconds for a while :p

 

i'm gonna play with the capacitors and watch it for a bit ... it seems to work very well now though, definitely an improvement, won't be able to tell for sure until waiting a while.

Last Edited: Fri. Aug 7, 2015 - 02:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well,  I built your code and Simulated in AS6.    Told the Simulator that it was running at 1024000Hz.

 

ISR(TIMER0_COMPA_vect, ISR_NOBLOCK) fires every 1000us.   With the occasional latency of 0.98us

 

The TIMER1 interrupt takes too long to simulate.   But I would just calculate:

OCR1A = (F_CPU / 64) * 1.318359375 - 1;   //12135.2963

 

This has little relation to your #define OCR1A_VAL   21092 value.

And it is not even an integer value.

 

Yes,   you can make a software correction every few ticks.

Your crystal should run fine with 22pF capacitors.   It will also run fine with two 33pF.    It will probably run with 9pF if there is some extra stay capacitance.    It does seem to be an unusual crystal frequency.   Can you post a link or part number ?

Bear in mind that two 33pF in series mean that the crystal "sees" 16.5pF (plus any strays)

 

Incidentally,   it is not wise to change OCR1A unless you have checked that it is safe to do so.   i.e. when TCNT1 is well out of range.    Otherwise you get a wraparound.

 

David.

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

seems to be pretty dead on now :)

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

david.prentice wrote:

Well,  I built your code and Simulated in AS6.    Told the Simulator that it was running at 1024000Hz.

 

ISR(TIMER0_COMPA_vect, ISR_NOBLOCK) fires every 1000us.   With the occasional latency of 0.98us

 

The TIMER1 interrupt takes too long to simulate.   But I would just calculate:

OCR1A = (F_CPU / 64) * 1.318359375 - 1;   //12135.2963

 

This has little relation to your #define OCR1A_VAL   21092 value.

And it is not even an integer value.

 

Yes,   you can make a software correction every few ticks.

Your crystal should run fine with 22pF capacitors.   It will also run fine with two 33pF.    It will probably run with 9pF if there is some extra stay capacitance.    It does seem to be an unusual crystal frequency.   Can you post a link or part number ?

Bear in mind that two 33pF in series mean that the crystal "sees" 16.5pF (plus any strays)

 

Incidentally,   it is not wise to change OCR1A unless you have checked that it is safe to do so.   i.e. when TCNT1 is well out of range.    Otherwise you get a wraparound.

 

David.

 

crystal is a 9B-8.192MAAJ-B manufactured by TXC. still a bit confused on how to choose the right caps. I used the formula load capacitance = C1 * C2 / C1 + C2.n I didn't take stray capacitance into account because I have no idea what it's value might be but I assume its low. Can you simply add the stray capacitance to get to the load capacitance, or does capacitance not work that way?

http://www.mouser.com/ProductDetail/TXC-Corporation/9B-8192MAAJ-B/?qs=65dIHZNch5uAZO9vE9A9Xg%3D%3D

 

about what you mentioned about changing OCR1A and having the value wrap:

 

I'm using CTC mode so what should happen is this:

TCNT1 reaches 21092

TCNT1 reset to 0

Interrupt is fired

OCR1A is set to 21095

 

is this right? shouldn't TCNT1 always be 0 whenever OCR1A is changed, or am I missing something?

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

Your crystal wants a load capacitance of 18pF. E.g. two 33pF and 4pF of stray means 16.5 + 4 or 20.5pF. This is not too far off 18pF.
But two 22pF and 4pF stray gives 15pF. OTOH, through hole pcbs may have about 7pF of stray i.e. 18pF load.

I really would not worry too much about the capacitor values. Especially since you are intending to do software correction anyway.

Regarding OCRIA change. Yes, you should be safe with up to 1000000us interrupt latency. Remember that interrupt latency only matters when you have frequent interrupts.

Is my maths wrong?

David.

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

most people making clocks use a 32.768khz watch crystal if they want accuracy.

It's temperature and vibration stable, AND divides nicely into seconds.

 

A standard crystal won't keep accurate time.

a 7.3728mhz crystal will also divide properly, but isn't as stable

Keith Vasilakes

Firmware engineer

Minnesota

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

david.prentice wrote:

Your crystal wants a load capacitance of 18pF. E.g. two 33pF and 4pF of stray means 16.5 + 4 or 20.5pF. This is not too far off 18pF.
But two 22pF and 4pF stray gives 15pF. OTOH, through hole pcbs may have about 7pF of stray i.e. 18pF load.

I really would not worry too much about the capacitor values. Especially since you are intending to do software correction anyway.

Regarding OCRIA change. Yes, you should be safe with up to 1000000us interrupt latency. Remember that interrupt latency only matters when you have frequent interrupts.

Is my maths wrong?

David.

 

right now, it's on a breadboard so the stray capacitance is probably more than it would be on a pcb. I do plan on maybe designing a PCB in the future, and would try and keep the traces to the crystal as short as possible. About the math, the formula is right, the result wasn't. Probably had something stored in the calculator memory that affected the result.

 

Anyway, the real problem turned out to be a careless mistake where I intended to increment a variable but never actually did, which ended up "slipping the clock" ever interrupt. So would you recommend a 22pf capacitor value over a 33pf, for a final PCB? What is typical stray capacitance on a PCB if one were to keep the traces as short as possible to the microcontroller (ideally directly next to the chip)? Is this something where you would have to design the board first, then measure the capacitance to choose the caps?

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

22pF is a sensible value. As you can see from my maths, it gives you 18pF load with 7pF from chip, traces, ...
A 15pF capacitor would need 11.5pF strays. A 27pF would need 4.5pF strays.

No, you do not need to do massive calculations. I think most people would just use a rule of thumb. e.g. typical stray on a short trace is 3pF to 7pF.
I am just a hobbyist. I expect that a professional will chime in with "2pF for SMD" "5pF for TH" if it is short. There are tables that you can look up for long bus traces. The chip data sheet will tell you the capacitance of an integrated circuit pin.

David.

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

I don't think it was mentioned yet, so I'll throw it out for completeness.

 

As you get your Xtal/caps/PCB capacitance etc. all sorted out, and get the clock running optimally in this regard, it may still be off a bit when you measure the accuracy over a longer period of time, say 24 hrs, or 48 hrs.

 

Lets say your short term accuracy that you are measuring now is quite good, but it still turns out the clock is off by 4 seconds / 24 hrs.

 

An additional option is to add (subtract) 4 seconds from the clock every 24 hrs, hence cancelling out the day's error.

 

Or add (subtract) 2 seconds every 12 hrs,

or 1 Sec every 6 hrs,

or 0.5 Sec every 3 Hrs,

etc.

 

The point is, you can still add an additional layer of time correction, to correct for much of the error.

 

If the clock is Mains powered, then the long term accuracy of the 50/60 Hz power line is also pretty good in many countries.

Occasionally synching with this is an option.

I saw a GPS module recently for < $10 USD.

Incredibly inexpensive for a very good time reference, if the device can "see" the satellites.

WWV and similar radio time signals are another synch option.

 

JC

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

In my case, I think the 9pf came from the capacitance specified in the crystal datasheet less like 5pf for the capacitance of the chip and traces divided by 2 'cause there are 2 caps. Reading an article at hack-a-day, I wonder if the capacitors are actually in series.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

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

well, I had been letting the clock run for a couple days, starting at a known time so that I could compare the clock time to what the correct time would be to do that last bit of correction. unfortunately the power went out during the night so I must start over with this process.

 

I don't anticipate any problems with this approach, and it should be pretty accurate after the correction depending on how many days I wait before measuring the error.

 

This might not be a good approach for a mass produced device, as the error may not be constant across all crystals and the correction in software may be specific to just this one unit? How would you get around this? Someone mentioned a 32.768kHz crystal, and I know mega chips have timers that can run in asynchronous mode so that the timer could run off the crystal, and the system clock use a different clock source, like the internal oscillator but ATTiny doesn't have this capability that I know of. I don't plan on mass producing this, but it might be good to know. There's also the issue of the current wiring solution utilizing a breadboard, the capacitors have pretty long leads and stick up pretty tall above the breadboard and could be carrying some stray capacitance that way affecting things.

 

Can a chip actually run at such a low system clock as 32kHz?

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

An AVR can run at 32kHz but it is a pretty foolish thing to do.

 

In practice,   the 8MHz HF crystal is quite stable.    e.g. a few seconds a week.

A 32768Hz crystal is a bit more stable but a Tiny has no facility for ASSR clock like the Mega.

 

Regarding your calibration.    You can check the time via your kitchen clock (mine is radio controlled by MSF).    Easily good for 1 second in 24 hours.

 

Once you have trimmed a real crystal oscillator (e.g. by kitchen clock or wristwatch),   you can use this as a calibration source for your production.

It will take about 3 seconds to determine the 24 hour accuracy.   In fact,  you could probably spot the drift on an oscilloscope display within a fraction of a second.

 

If you are intending the device to run in an office environment,   the HF crystal will be fine.   After all,   your room temperature only has a small range.    If you use in a car or factory,   it may get hot or cold.

 

David.

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

badcode wrote:
Can a chip actually run at such a low system clock as 32kHz?
You bet your boots.

"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

badcode wrote:

Can a chip actually run at such a low system clock as 32kHz?

You bet your boots.

I cannot disagree, and I suspect that e.g. my indoor/outdoor LCD thermometer that has run forever on a coin cell might do that.

 

However, I've never seen the appeal on an AVR8.  Overall power consumption is lower by going fast [a relative term] to get the work done and get back to sleep faster, than e.g. running continually at 32kHz ad just barely getting the job done with no cycles for anything else.

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

As already mentioned, the tiny (like the '85) cannot do that. If you want to keep accurate time on an '85 and maintain low power consumption, a low frequency crystal is really the only option.
If you don't need to do anything else, what does it matter?

"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: Mon. Aug 10, 2015 - 08:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So, then, where is OP going to get this perfect clock source?  As I've already posted in similar threads, even the international time standards are an average of several "atomic clocks".

 

Putting a several/many dollar cooked oscillator on a $1 Tiny, 'cause that doesn't have built-in watch crystal support?  Hmmm...

 

I don't think anyone has yet mentioned trim caps.  But I don't know how they might drift over time and temperature and Vcc.

 

The "interesting" starting frequency as a postulate also introduces other troublesome aspects.

 

 

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:
Putting a several/many dollar cooked oscillator on a $1 Tiny, 'cause that doesn't have built-in watch crystal support?  Hmmm...
Huh?  I've re-read the thread, and I can find no post suggesting this as a solution.

 

The OP hasn't mentioned how his hexidecimal clock is used.  Binary LED display?  Seven-segment LED display?  LCD module?  Serial link to a host?  Without details it will be impossible to give a firm recommendation, but for example with a 4-digit LED display I can see no reason not to clock the tiny at 32.768 kHz, and 5 ppm crystals (nominal) can be had for $0.60 in single quantities.

 

Since such a crystal is best suited to 'normal' timekeeping, the software will need to adjust for the 1.318359375-second 'hexidecimal second'.

 

However if the clock doesn't need to be low-power, there is of course no reason to go to the trouble.  Run it at 4 MHz, or 8, or whatever and be done with it.

 

 

 

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

The OP hasn't mentioned how his hexidecimal clock is used.  Binary LED display?  Seven-segment LED display?  LCD module?  Serial link to a host?  Without details it will be impossible to give a firm recommendation, but for example with a 4-digit LED display I can see no reason not to clock the tiny at 32.768 kHz, and 5 ppm crystals (nominal) can be had for $0.60 in single quantities.

 

Since such a crystal is best suited to 'normal' timekeeping, the software will need to adjust for the 1.318359375-second 'hexidecimal second'.

 

However if the clock doesn't need to be low-power, there is of course no reason to go to the trouble.  Run it at 4 MHz, or 8, or whatever and be done with it.

 

 

 

The display is a 4-digit seven segment display. The 8.192MHz crystal was chose because it yields slightly better to "hexadecimal seconds" than other common crystal frequencies. The 32.768KHz crystal would actually be just as good, just wasn't sure if they were suitable as system clock. Apparently they are, so long as theres not too much to be done that the avr cant get it done fast enough at that clock. The biggest workload in this application would be updating the display, which I am currently doing at 62.5hz ... meaning that that all four digits are updated every 16ms. At this rate the the flickering is very subtly perceptible by me, but probably no one else. Higher rates are completely completely imperceptible, but 60ish hertz is fine ... it couldnt be any lower than that though because any slower and its definitely noticeable and gives you a headache to look at. I tend to get the impression that the 32.768kHz clock would be fine for this?

Last Edited: Tue. Aug 11, 2015 - 12:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you multiplexing the four digits in software?  Or is this a seven segment 'module' with a serial interface?

 

If you're multiplexing 4 digits in software at 62.5 Hz, that means 250 Hz digit update rate.  At 32.768 kHz, that's 131 cycles.  Might be a bit tight, but it is doable.

 

Bear in mind, I'm not >>recommending<< that you go with a 32.786 kHz crystal, I was only answering your query with a 'yes it can'.
 

"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. Aug 11, 2015 - 12:23 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:

Are you multiplexing the four digits in software?  Or is this a seven segment 'module' with a serial interface?

 

If you're multiplexing 4 digits in software at 62.5 Hz, that means 250 Hz digit update rate.  At 32.768 kHz, that's 131 cycles.  Might be a bit tight, but it is doable.

 

Bear in mind, I'm not >>recommending<< that you go with a 32.786 kHz crystal, I was only answering your query with a 'yes it can'.
 

yes, data is sent serially to a shift register using software bit-bang style. I'm using 3 pins for the shift register and 4 additional pins to drive transistors (to control the common anodes of each digit). The 7-segment serial "modules" are a bit expensive ... i actually have one but Im not using it in this project.

I'll probably order a few of these crystals and see what happens :)

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

You can phase lock a high frequency CPU clock to the 32kHz crystal. Run a timer off the CPU clock, interrupt every millisecond off the crystal or so and adjust OSCCAL based on the timer phase error. Why would you do this? Because you can :)

 

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

dak664 wrote:
You can phase lock a high frequency CPU clock to the 32kHz crystal. Run a timer off the CPU clock, interrupt every millisecond off the crystal or so and adjust OSCCAL based on the timer phase error. Why would you do this? Because you can :)
Not with an ATtiny2313A, you can't.

 

And now that I look at the datasheet, I see that the 2313A can't use a 32 kHz crystal at all, so you're out of luck there, @badcode.  Save yourself the 60 cents.

 

The ATtiny25/45/85 can be clocked from a 32 kHz crystal, though.

"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

What I ended up doing is let the clock run for a week, after that time IIRC it had lost about 18 hexseconds. So I compared the time on the clock, to the time that SHOULD be on the clock if it was running the correct speed, calculated how much shorter each second would have to be made for it to tick at the correct speed and applied the correction in the software.

 

Seems to be pretty accurate, without losing even one second over 24 hours. Haven't let it run any longer than that because I've been working on other features again but it ought to be at least as good as 1 second per week or better. Out of curiosity I synchronized the second's hands of two mechanical clocks in the house and let them run for the same amount of time, at the end of which they differed by about 12 seconds (actual seconds, not hex seconds in this case). So after the correction my clock is better than these so I guess I can accept it. If I were to do things again, I'd probably design around a watch crystal then choose a MCU with that capability, then finally any other features I needed. Live and learn I guess.

 

Oh btw, the actual correction factor that was needed was 0.999947705355 .. which is very close to 1 but indeed made a difference.

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

Quote:
Oh btw, the actual correction factor that was needed was 0.999947705355 .. which is very close to 1 but indeed made a difference.
Well that's about 52 ppm, so it seems to be within the realm of reason.

"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

Live and learn I guess

As it is with most projects.

 

The second time around you can do it better because of all of the lessons learned the first time!

 

JC 

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

But it is only correct at that temperature (and voltages)!