Can't find old topic on clock compensation

I want to read the CLKO pin on my standalone 328P and adjust the counter I'll be using.

I know I've bumped into a topic around here in the past couple days where someone posted their code that did just that.

Now that I actually want that code, of course, I have no idea what the topic was called. Lots of Googling has gotten me nowhere.

Does anyone remember that thread where that thread is?

(I don't particularly want to pay DigiKey twelve bucks for a TCXO, especially as Atmel says the TOSC pins are optimized for a crystal oscillator, but I might just do it anyway... thoughts?)

Thanks!

The CKOUT bit in the low fuse byte enables clock output, is that what you were looking for?

I do have thoughts, but what are your requirements. Some certain accuracy? Are you thinking of providing the system clock via a TCXO?

randomizer:
I want to read the CLKO pin on my standalone 328P and adjust the counter I'll be using.

There is no CLK0 pin. Do you mean XCK? XTAL1/2?

What are you trying to do exactly? Measure temperature and calculate a correction factor?

PORTB0 (Arduino D8) can be set to output the system clock. I once read, but can no longer find, a post by someone who wrote code to read the clock frequency and correct their timer for it.

I'm looking to create a clock. It doesn't have to be super-amazingly accurate, but the ~1sec/5min loss I'm getting with a 32.768 kHz crystal is not acceptable. I'm thinking the crystal's slow because it's at room temp, not skin temp—so I'm considering a TCXO (DigiKey no. DS32KHZ/DIP-ND), but I've read that the ATmega may not be designed for that. Could I just send the signal from that to TOSC1 for TIMER2 running asynchronously?

Still not clear exactly what you're trying to do, and exactly what the problem is. What is being used for the system clock, and what is the 32kHz crystal connected to? If you're clocking timer 2 from the 32kHz crystal, then that is not the system clock, so it can can't be output to the CLKO pin. One second in 5 min is 3333ppm, so something is terribly wrong. What is the load capacitance spec for the crystal? I've got a lot of DS1307s with 32kHz crystals around, most run within 20ppm, although I do have one or two flyers. I'd go for a Chronodot (±2ppm) or something similar before I'd go for that $12 TXCO (±7.5ppm).

A lot of the 32.768kHz crystals that get used with DS1307s have a load capacitance spec of 12.5pF. These will also work to clock timer2 asynchronously; I've done this once or twice just playing around, but haven't measured the frequency.

Past couple of days? Have you checked your browser history?

You're over my head but I remember seeing something in the near/medium past... yes, I found this in my browser cache. I looked at it and --given what I've read about arduino-not-very-accurate clock--wondered if it was even "on the level"...

johncc:
You're over my head but I remember seeing something in the near/medium past... yes, I found this in my browser cache. I looked at it and --given what I've read about arduino-not-very-accurate clock--wondered if it was even "on the level"...
http://www.instructables.com/id/Make-an-accurate-Arduino-clock-using-only-one-wire/

Seems like a roundabout way of just using the system clock for timing. Could have been done with zero wires, just configure an interrupt on one of the timers.

Yeah, looking at it more carefully I see that the gist of it is he is just adjusting his clock readings is software by ~ 1 sec per hour...

it was even "on the level"...

What he was doing is totally unnecessary, unimpressive, overly complicated and fairly inaccurate.

With NO external hardware (including a wire), you can achieve better timing than he did.

I've got the µC running at 8MHz internal osc; the watch crystal is hooked up to TOSC1/2 not on the breadboard—I bent the legs up and taped it on to avoid parasitic capacitance. Atmel note AVR4001 has a graph which shows frequency increasing with less capacitance and decreasing with more. I have crystals with 6pF, 8pF, and 12.5pF load capacitance. Right now I'm using the 12.5.

It does rather seem like something is very wrong—the datasheet for the DS32KHZ has a graph showing its ppm delta time compared to a non-compensated crystal, and at 15ºC (room temp here) the regular crystal should be max -40 ppm. I don't know.

From that datasheet, it seems that TCXO does have ±2 ppm stability in non-extreme temp ranges. But the ChronoDot (which is more expensive) comes with a battery and battery holder, which is nice... and it seems it can output a 32.768 kHz signal, which I'd want, as my binary clock uses up a lot of pins. Maybe I will do that.

Jimmy60:
Past couple of days? Have you checked your browser history?

You'd think I could find it there, wouldn't you? Very frustrating.

I bent the legs up and taped it on to avoid parasitic capacitance

"taped it on"? What do you mean by this please?

johncc:
"taped it on"? What do you mean by this please?

Y'know how you solder electrical components together, to connect them and let electricity flow through them?

This is like that, only I used tape. I stuck the crystal legs to the µC's pins and wrapped 'em up. :slight_smile:

How do you ensure that you don't get a cold tape joint?

If this is a clock project, why not use an external RTC. Yes most can supply a 32.768kHz signal, but that's just using it as a TXCO, when it has all the time, date, alarm, etc. functionality built in as well. Another option is to just use the chip (DS3231) as in the Chronodot or one of its siblings (DS3232, DS3234). They're not cheap, $9 or $10, so by the time the backup battery and all is added, it'd probably cost as much or more as the Chronodot.

Here's my blog post on the experiment I did, I just stuck the crystal in the breadboard. I don't remember checking accuracy, but if it was way off, I would have probably noticed. But it was strictly an experiment; it worked and I didn't worry about finer points like accuracy. But yes those breadboards do add some capacitance to things. But the tape business sounds pretty sketchy as well :smiley:

Turning the clock output on is simple enough with a fuse change. I suppose you could then check that with an accurate frequency meter and adjust the clock compensation byte in the processor, assuming you are using the internal RC oscillator. I don't think that can be stored, you would have to remember the value in EEPROM and set it in setup each time.

Just for interest, I wrote this fairly simple sketch:

void setup() { }

void loop() 
  {
  OSCCAL = analogRead (A0) >> 2;
  }

That takes the analog input from A0, divides it by 4 to get it into the range 0 to 255, and then puts that in the oscillator calibration byte.

I set the low fuse to: 0xE2 (on an Atmega328P). This uses the internal oscillator, and outputs the clock on pin D8 (pin 14 on the chip). I connected my scope to that pin.

Cranking a pot around from one end of the scale to the other I got:

Lowest: 4.8 MHz
Highest: 15.7 MHz

The datasheet warns:

Note that this oscillator is used to time EEPROM and Flash write accesses, and these write times will be affected accordingly. If the EEPROM or Flash are written, do not calibrate to more than 8.8 MHz. Otherwise, the EEPROM or Flash write may fail.

However certainly you should be able to empirically determine the value to correctly run at 8 MHz, and save that somewhere (eg. EEPROM).

He's using the internal RC osc for the system clock, and also using the low-freq xtal osc with a 32.768kHz crystal for timekeeping. OSCCAL adjusts the former, but I don't think it affects the latter. Of course one possibility is to dispense with the low-freq xtal, trim the internal RC osc, and then use it for time keeping as well as system clock.

I've been experimenting with a frequency counter sketch that uses a 1Hz GPS signal for gate timing, I think it's quite accurate. I've checked several PC boards that I've built with 16MHz and 8MHz crystals for the system clock and found them within 10ppm, which is probably as good or better than the average DS1307 RTC in my experience. Using the same parts on a breadboard doesn't do nearly as well, typically 40-60ppm. Once I have the code finalized, I'll make a post about it, it's been interesting.

Haha, wow! That does agree pretty closely with the characteristic chart in the datasheet (Fig. 30-368, p513). Note the discontinuity in the middle of the curve, though.

I've experimented with Coding Badly's TinyTuner and it works well, but of course its absolute accuracy is dependent on that of the clock for the µC that's doing the measuring.

As I think about it more, I realize I couldn't really use the µC to monitor the µC—how is it supposed to know what the "correct" frequency is when its internal osc is is the one that's off? Silly me.

I have a frequency meter—the MS8268. It reads 59.98 Hz from the wall, but gets nothing from the CLKO pin (which I know is putting the clock out, 'cause an LED glows when attached). I should have one test lead on CLKO and one on ground, right? Maybe it's just cheap Chinese junk...

I think I'll get the TCXO from DigiKey. All my code needs is an accurate 1Hz (or 0.2Hz, even) interrupt to count the seconds. I don't think an external RTC would work, as I want to be able to set the clock if needed.