Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Pete Stephenson]

I ended up doing just this and it worked out nicely. Using the timer
hardware as a counter freed up the CPU for other tasks and could run
in the background so I wouldn't miss any ticks. It turns out that
using the built-in timer hardware was a lot easier than using external
"jellybean" logic to accomplish the same thing, even if it took a bit
of reading to better understand it.

I whipped up a quick-and-dirty Arduino sketch that I've made available
at https://github.com/heypete/Frequency_Counter_32kHz/ for anyone
who's interested.

I make no claims to its quality, but I've tested it with runs from 10
seconds to 20,000 seconds and it seems to produce the expected results
on both a standard Arduino Uno and a bare 16MHz ATmega328P. Any
suggestions or improvements would be welcome.

Also, thanks to everyone for your assistance. It was a fun learning
experience and excursion outside the standard Arduino commands into
the mysterious depths of the datasheet and hardware registers.

Cheers!
-Pete

On Wed, Jun 29, 2016 at 6:49 AM, Scott Stobbe  wrote:
> For pulse counting, the timer hardware is the way to go. Setup a 16-bit
> timer clocked off your DUT. Then input capture on your PPS edge. This
> leaves you plenty of processor time for string formatting and other tasks
> you may wish to perform.
>
> If you do the decimation as post-processing on your PC (i.e. log cycle
> count every PPS), you can use a zero-phase moving average filter, which may
> provide more visual insight over just a single data point every 1000s.
>
> On Tue, Jun 28, 2016 at 3:48 PM, Hal Murray  wrote:
>
>>
>> p...@heypete.com said:
>> > I have seen those, but I have little experience with PICs and the Wife
>> > Acceptance Factor of buying more stuff for a one-off measurement is low.
>>
>> The PIC family is very similar to AVRs.  The picPET and friends are 8 pin
>> DIPs so the Wife is unlikely to notice the additional clutter.
>>
>>
>> >> The PPS input on a PC may be be useful.
>> > Indeed. I normally use it for NTP.
>>
>> Than you want a second serial port for things like this.
>>
>> Or maybe you can use the parallel port if your system is old enough to have
>> one.  I haven't tried it, but I think Linux has a module that supports it.

-- 
Pete Stephenson
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Brooke Clarke]

Hi David:

I built a number of clocks based on PIC uC and using interrupts. The idea is to use the output from a frequency standard 
as the heart beat of the clock.
Depending on what the PIC was doing when interrupted the delay can different by one cycle and a simple test corrects 
that.  Clock settable to 1ms and keeps perfect time.

http://www.prc68.com/I/PRC68COM.shtml#07092006
I wrote this directly using the Microchip assembler.  I'm not a fan of C.

My first uC was the SWTP kit that came with no software.  I learned to write directly in hex machine language.  The 
problem with that is every time code is changed inside a loop the target address needs to be recomputed.  Later I got a 
copy of the Motorola assembler and editor which was a big help.

http://www.prc68.com/I/comp.shtml#SWTP

--
Have Fun,

Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/2012Issues.html
The lesser of evils is still evil.

 Original Message 

O M G..

So I followed the link and saw how they do it.Wow.  They write interrupts 
like the DMV processes applications. I can only imagine what this looks like on 
the PIC, where every instruction takes 4x as many cycles.
All of that pushing and popping is PRECISELY what you need to avoid.
Pushing any register that the ISR does not actually change is totally insane.
My average ISR is far shorter than their intro and outro code.

"C" does not cooperate easily with this, but you can declare your interrupts 
"naked" and write them in assembler so as to avoid this insanity.

I say this as someone who has been developing on the AVR platform for something like 20 
years.   My first application was on the 8515, and they didn't even have production 
silicon yet. My development was done on a chip with date code "ES"  
(Engineering Sample)


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Nick Sayer via time-nuts]

> 
> For more precise stuff timing, I have a Thunderbolt and other goodies.
> (Speaking of which, I really need to figure out how to use the
> Thunderbolt as an external clock source for my Arduinos.)
> 

I don’t think you can do it for an Arduino without hardware changes. The CLKI 
pin is shared with XTAL1. But you can clock almost any AVR from an external 
clock source as long as the Vcc vs frequency “safe operating area” is respected 
(see the datasheet for your particular device). Note that if you fuse the 
device for an external clock source of any kind, that source must be present 
during (non-HV) programming as well as operation.

I use a DC blocking cap and self-biased inverter nowadays as an input 
conditioner for external clock inputs. It allows me to accept sine as well as 
square inputs if necessary. My principle use for this is my Crazy Clock 
calibrator, which I clock from one of my GPSDOs. It’s not 100% reliable, and 
I’m not sure why. Every once in a while, the AVR will lock up, even with the 
watchdog turned on. The square wave on CLKI looks *perfect*. I can only guess 
that there’s a glitch every once in a while that screws something up, but I 
haven’t figured it out yet.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Van Horn, David]

>That all assumes you have turned interrupts off for some reason. Common 
>reasons  could be that you are in another interrupt service routine or that 
>you are executing interrupt related code. 
>
>Bob


What I saw in their interrupt routine was a "full boat" implementation, pretty 
typical for C code, saving registers without regard for what happens in the 
ISR, but nothing about the interrupts being turned off. 
If you mean not having re-enabled ints during the ISR, then yes, and that is 
how I would urge anyone to write an ISR.   The reason that you would re-enable 
ints during an ISR is that your ISR takes too long.
Making the ISR take even longer isn't really a solution.   Write faster ISRs. 

The key is to do absolutely as little housekeeping as needed, and have the ISR 
do as little as possible.

I have had cases where I didn't even preserve SREG because what I was doing in 
the ISR didn't alter SREG. 

Don't blame the hardware for poor implementation of software.

There really is no actual minimum code in an ISR.  In one case, I had a useful 
ISR that had actually no code in it!.  A very special case, but they happen. 
What I showed is my typical intro and outro code for probably 90% of what I 
write.  I avoid pushing and popping because it wastes time.  Copying SREG into 
a dedicated register is faster. Using dedicated ISR registers is faster than 
pushing and popping to free up registers.  

All this pushing and popping causes deep stack usage, which isn't even an 
option on some processors.  When your stack collides with your data, you're 
toast. It is to your significant advantage to minimize stack usage.

I will typically put a stack guard below where I expect the stack to live, and 
monitor that in the "sanity check" routine for any changes.  The sanity check 
routine looks at this and other things that I know should never change, and if 
they are not the correct values, then the watchdog won't be reset.  The sanity 
check routine is also the only place that the watchdog gets reset.WDRs 
scattered through the code are symptomatic of poorly written code.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Van Horn, David]

O M G..

So I followed the link and saw how they do it.Wow.  They write interrupts 
like the DMV processes applications. I can only imagine what this looks like on 
the PIC, where every instruction takes 4x as many cycles.
All of that pushing and popping is PRECISELY what you need to avoid. 
Pushing any register that the ISR does not actually change is totally insane.
My average ISR is far shorter than their intro and outro code.

"C" does not cooperate easily with this, but you can declare your interrupts 
"naked" and write them in assembler so as to avoid this insanity.

I say this as someone who has been developing on the AVR platform for something 
like 20 years.   My first application was on the 8515, and they didn't even 
have production silicon yet. My development was done on a chip with date code 
"ES"  (Engineering Sample)


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Bob Camp]

Hi

> On Jun 29, 2016, at 5:08 AM, Pete Stephenson  wrote:
> 
> On Tue, Jun 28, 2016 at 12:14 AM, Van Horn, David
>  wrote:
>> 
>> 
>> p...@heypete.com said:
>>> I'm a little concerned about the speed at which the pulses need to be
>>> counted. The 32kHz pulses come in every ~30.5 microseconds, and handling an
>>> interrupt on an ATmega328 running at 16MHz takes about 5.125 microseconds[1]
>> 
>> Huh?
>> 
>> Instruction cycle time is 62.5nS for almost all instructions at that clock.
>> That’s a pretty long ISR by my standards.
> 
> According to the "How long does it take to execute an ISR?" part of
> http://www.gammon.com.au/interrupts, it takes 82 cycles total to
> service an external interrupt (i.e. one triggered by an interrupt
> pin), including the time needed to enter the ISR and to leave it after
> it's done whatever you needed it to do. At 62.5nS for each clock
> cycle, that's 5.125uS just to process the interrupt. That doesn't
> include the time needed to execute whatever code you want it to do.

That all assumes you have turned interrupts off for some reason. Common 
reasons  could be that you are in another interrupt service routine or that
you are executing interrupt related code. 

Bob


> 
>> 1: Reserve a couple of registers for handling data inside ISRs, avoiding 
>> push and pop.
>> 2: Reserve a register for holding SREG during the ISR.
>> 
>> ISR:in STEMP,SREG
>>At this point you can fearlessly trash SREG and ITEMP and ITEMP2
>>Do Stuff using ITEMP and ITEMP2.
>>Do as little as practical in the ISR, letting the non-isr code do the 
>> heavy lifting.
>>Out SREG,STEMP
>>RETI
>> 
>> Optionally, set a register (I usually call it "ZERO") to 0x00 to speed up 16 
>> bit operations.
>> Keep data you need FAST in registers in the low page, rather than in RAM.
> 
> Thanks! I think that may be a bit beyond my ken for the time being,
> but I'll definitely keep it in mind for when I know more.
> 
> Cheers!
> -Pete
> 
> -- 
> Pete Stephenson
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Pete Stephenson]

On Tue, Jun 28, 2016 at 12:14 AM, Van Horn, David
 wrote:
>
>
> p...@heypete.com said:
>> I'm a little concerned about the speed at which the pulses need to be
>> counted. The 32kHz pulses come in every ~30.5 microseconds, and handling an
>> interrupt on an ATmega328 running at 16MHz takes about 5.125 microseconds[1]
>
> Huh?
>
> Instruction cycle time is 62.5nS for almost all instructions at that clock.
> That’s a pretty long ISR by my standards.

According to the "How long does it take to execute an ISR?" part of
http://www.gammon.com.au/interrupts, it takes 82 cycles total to
service an external interrupt (i.e. one triggered by an interrupt
pin), including the time needed to enter the ISR and to leave it after
it's done whatever you needed it to do. At 62.5nS for each clock
cycle, that's 5.125uS just to process the interrupt. That doesn't
include the time needed to execute whatever code you want it to do.

> 1: Reserve a couple of registers for handling data inside ISRs, avoiding push 
> and pop.
> 2: Reserve a register for holding SREG during the ISR.
>
> ISR:in STEMP,SREG
> At this point you can fearlessly trash SREG and ITEMP and ITEMP2
> Do Stuff using ITEMP and ITEMP2.
> Do as little as practical in the ISR, letting the non-isr code do the 
> heavy lifting.
> Out SREG,STEMP
> RETI
>
> Optionally, set a register (I usually call it "ZERO") to 0x00 to speed up 16 
> bit operations.
> Keep data you need FAST in registers in the low page, rather than in RAM.

Thanks! I think that may be a bit beyond my ken for the time being,
but I'll definitely keep it in mind for when I know more.

Cheers!
-Pete

-- 
Pete Stephenson
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Scott Stobbe]

For pulse counting, the timer hardware is the way to go. Setup a 16-bit
timer clocked off your DUT. Then input capture on your PPS edge. This
leaves you plenty of processor time for string formatting and other tasks
you may wish to perform.

If you do the decimation as post-processing on your PC (i.e. log cycle
count every PPS), you can use a zero-phase moving average filter, which may
provide more visual insight over just a single data point every 1000s.

On Tue, Jun 28, 2016 at 3:48 PM, Hal Murray  wrote:

>
> p...@heypete.com said:
> > I have seen those, but I have little experience with PICs and the Wife
> > Acceptance Factor of buying more stuff for a one-off measurement is low.
>
> The PIC family is very similar to AVRs.  The picPET and friends are 8 pin
> DIPs so the Wife is unlikely to notice the additional clutter.
>
>
> >> The PPS input on a PC may be be useful.
> > Indeed. I normally use it for NTP.
>
> Than you want a second serial port for things like this.
>
> Or maybe you can use the parallel port if your system is old enough to have
> one.  I haven't tried it, but I think Linux has a module that supports it.
>
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Hal Murray]

p...@heypete.com said:
> I have seen those, but I have little experience with PICs and the Wife
> Acceptance Factor of buying more stuff for a one-off measurement is low. 

The PIC family is very similar to AVRs.  The picPET and friends are 8 pin 
DIPs so the Wife is unlikely to notice the additional clutter.


>> The PPS input on a PC may be be useful.
> Indeed. I normally use it for NTP. 

Than you want a second serial port for things like this.

Or maybe you can use the parallel port if your system is old enough to have 
one.  I haven't tried it, but I think Linux has a module that supports it.



-- 
These are my opinions.  I hate spam.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Van Horn, David]

p...@heypete.com said:
> I'm a little concerned about the speed at which the pulses need to be
> counted. The 32kHz pulses come in every ~30.5 microseconds, and handling an
> interrupt on an ATmega328 running at 16MHz takes about 5.125 microseconds[1]

Huh?

Instruction cycle time is 62.5nS for almost all instructions at that clock.
That’s a pretty long ISR by my standards.

1: Reserve a couple of registers for handling data inside ISRs, avoiding push 
and pop.
2: Reserve a register for holding SREG during the ISR.

ISR:in STEMP,SREG
At this point you can fearlessly trash SREG and ITEMP and ITEMP2
Do Stuff using ITEMP and ITEMP2.
Do as little as practical in the ISR, letting the non-isr code do the 
heavy lifting.
Out SREG,STEMP
RETI

Optionally, set a register (I usually call it "ZERO") to 0x00 to speed up 16 
bit operations.
Keep data you need FAST in registers in the low page, rather than in RAM.





___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Mark Sims]

Back when that local high school kid was arrested for bringing his "home made" 
alarm clock to school,  I bought a "bomb clock game" off of Ebay.  It looks 
like 7 sticks of dynamite with a circuit board with LEDs strapped to it.  The 
game part is you press a button and it starts counting down 10 seconds.  You 
have to disconnect one of 4 wires or it "goes off".   When not running the 
game, it is a standard alarm clock.  It has a 18650 lipo cell with charger 
circuit plus runs off the (5V) input.

It uses what looks like an ATMEGA328 series chip with a standard 10 cent 16 MHz 
microprocessor crystal.  The strange thing is it is VERY accurate.  It seems to 
hold +/- two seconds over several months.   I'm guessing that either I was very 
lucky (not likely, those crystals are rather iffy) or the maker did some sort 
of measurement of the processor clock and programmed an adjustment factor into 
EEPROM to compensate for the true frequency.  I've done the same thing with 
several AVR projects that had software clocks in them and the compensated 16 
MHz clocks beat any of the RTC chips.


  
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Tom Van Baak]

Instead of using a timer and ISR, consider clocking the MCU directly from the 
external 32 kHz signal.
Sample code: http://leapsecond.com/pic/src/pd33.asm
It's a $1 solution; acts like a 4-pin, stand-alone, divide-by-32768 counter; 
works extremely well.

/tvb

- Original Message - 
From: "Pete Stephenson" <p...@heypete.com>
To: "Discussion of precise time and frequency measurement" <time-nuts@febo.com>
Sent: Tuesday, June 28, 2016 1:47 AM
Subject: Re: [time-nuts] How to properly characterize 32kHz oscillators 
manually and with a microcontroller?


Hi Nigel,

Using the internal timer as a divide-by-256 counter is a clever way of
doing things. Thanks!

I'm not familiar with using the timers as an input, so it looks like I
need to do some light, relaxing reading of the datasheet. From what I
can tell, using timer2 as an input ("asynchronously clocked") requires
that the microcontroller run on its internal RC oscillator rather than
the standard crystal/ceramic resonator since it shares the pins for
the timer input with the crystal.

I think I have some divide-by-n counters in discrete logic lying
around somewhere. As a quick test, I might just use those to divide
down the 32kHz signal by 10 and use a pin interrupt to count the
number of overflows. At the end of 1000 seconds (or whatever), I could
read the counter state. It's likely not as precise as using the
internal timer on the ATmega, and I'd need to make sure I read the
counter state quickly before any pins change, but it should get me
close.

Cheers!
-Pete

On Mon, Jun 27, 2016 at 9:46 PM, Nigel Vander Houwen
<timenuts-nige...@nigelvh.com> wrote:
> Pete,
>
> Instead of doing this in an ISR, feed the 32KHz into one of the timer/counter 
> inputs, and clock the timer off of that (probably TIMER2), then just have an 
> ISR for the overflow vector. So, when your X bit timer overflows, you can 
> just add that to your total, when you reach your 1000s (or whatever interval 
> you prefer, simply grab the current timer/counter value, add it to what 
> you’ve stored from the overflows, and you have your counts without all the 
> CPU load of an ISR for every cycle of 32KHz.
>
> Nigel
>
>> On Jun 27, 2016, at 08:22, Pete Stephenson <p...@heypete.com> wrote:
>>
>> Hi all,
>>
>> I have a few Maxim DS3231 temperature-compensated real-time clock
>> chips I use for various embedded hobby projects. They're specced to
>> have an accuracy +/-2ppm between 0 Celsius and 40 Celsius. One is from
>> a standard, reputable vendor, while a few are from somewhat more
>> dubious internet sellers. While all the chips work and seem to
>> maintain reasonable time over a period of a few weeks, it's possible
>> that some don't meet spec and I'd like to test them and make sure they
>> do what they're supposed to.
>>
>> Here's what I've been doing manually, and what I hope to accomplish
>> using a microcontroller. Any tips are very welcome.
>>
>> = Manual Approach =
>>
>> I've manually tested a few of the chips using a digital storage
>> oscilloscope and a Trimble Thunderbolt's PPS output. Here's how I've
>> set things up:
>>
>> 1. Enable the 32kHz output on the DS3231 and wire it appropriately.
>> (The 32kHz output shows up on the oscilloscope.)
>>
>> 2. Set the oscilloscope to trigger on the Thunderbolt's PPS output. As
>> expected, the DS3231's 32kHz output drifts slowly relative to the PPS,
>> so the pulse train seems to move slowly to the left or right
>> (depending on the chip) on the scope.
>>
>> 3. Wait until the rising edge of one of the 32kHz pulses is (visually)
>> lined up with an arbitrary line on the scope's graticule, then start a
>> timer.
>>
>> 4. Wait until the rising edge of the next pulse drifts to the same
>> line on the graticule -- that is, it has drifted by one cycle -- and
>> then stop the timer.
>>
>> If I'm particularly motivated, I'll watch the scope for longer and
>> count the time it takes for the clock to drift two or three cycles.
>>
>> As an example, one of the clocks drifts by one cycle in 120 seconds.
>>
>> I then calculate the stability as follows:
>>
>> Stability = (1 cycle / 120 seconds) / (32768 Hz)
>> = (1 cycle / 120 seconds) / (1 second / 32768 cycles)
>> = 2.54*10^(-7)
>> = 0.254 ppm.
>>
>> Is this right so far? If so, that clock seems to be well-outperforming
>> the specs.
>>
>> I've tested a few chips at a few different temperatures (e.g in the
>> freezer, in direct sunlight, etc.) and they seem to drift faster for a
>> minute until the chip measures and corrects for the temperature
>> change, at

Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Pete Stephenson]

On Mon, Jun 27, 2016 at 10:51 PM, Hal Murray  wrote:
>
> I assume you are doing this for fun.  That means you get to do whatever you
> think will be fun.

Indeed, this is strictly for fun. I have strange values for "fun".

> The DS3231 is pretty crappy by time nuts standards.  If you can also measure
> the temperature, you should be able to make neat graphs.  If you watch it as
> the temperature ramps up slowly, you should see a sawtooth pattern.  The
> crystal will track the normal freq/temp curve until the temperature changes
> enough for the correction logic to add in another step.

Oh, I know the DS3231 isn't terribly great. The datasheet calling it
an "Extremely Accurate...RTC/TCXO/Crystal" makes me laugh, as it's
tooting its own horn.

For more precise stuff timing, I have a Thunderbolt and other goodies.
(Speaking of which, I really need to figure out how to use the
Thunderbolt as an external clock source for my Arduinos.)

Still, the DS3231 is a reasonably accurate RTC, inexpensively priced,
is easy to interface with my Raspberry Pis, Arduinos, etc., and
provides a handy 32kHz output. It also has an internal temperature
sensor that it checks every 64 seconds, the output of which is also
accessible. Your idea of plotting the temperature vs. frequency is a
good one; I'll add it to the project list.

> Have you looked at tvb's PICPET and friends?
>   http://www.leapsecond.com/pic/picpet.htm
>   http://www.leapsecond.com/pic/picdiv.htm
>
> I think he has one that turns 32KHz into PPS.  You could feed that PPS into a
> picPET running off your Thunderbolt.

I have seen those, but I have little experience with PICs and the Wife
Acceptance Factor of buying more stuff for a one-off measurement is
low.

> If you have a spare counter, you can run that in frequency mode and feed that
> to a PC.

Alas, I'm ashamed to say I have no frequency counter at all.

> Where are you going to collect the data?

My plan was to have the ATmega328 simply output the data over a serial
connection so I can put it in a spreadsheet or something.

> The PPS input on a PC may be be useful.

Indeed. I normally use it for NTP.

Thanks for the advice!

Cheers!
-Pete

>
> p...@heypete.com said:
>> I'm a little concerned about the speed at which the pulses need to be
>> counted. The 32kHz pulses come in every ~30.5 microseconds, and handling an
>> interrupt on an ATmega328 running at 16MHz takes about 5.125 microseconds[1]
> ...
>
> Use one of the counters to divide things down to a rate that is easier to
> handle.
>
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.



-- 
Pete Stephenson
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Pete Stephenson]

Hi Nigel,

Using the internal timer as a divide-by-256 counter is a clever way of
doing things. Thanks!

I'm not familiar with using the timers as an input, so it looks like I
need to do some light, relaxing reading of the datasheet. From what I
can tell, using timer2 as an input ("asynchronously clocked") requires
that the microcontroller run on its internal RC oscillator rather than
the standard crystal/ceramic resonator since it shares the pins for
the timer input with the crystal.

I think I have some divide-by-n counters in discrete logic lying
around somewhere. As a quick test, I might just use those to divide
down the 32kHz signal by 10 and use a pin interrupt to count the
number of overflows. At the end of 1000 seconds (or whatever), I could
read the counter state. It's likely not as precise as using the
internal timer on the ATmega, and I'd need to make sure I read the
counter state quickly before any pins change, but it should get me
close.

Cheers!
-Pete

On Mon, Jun 27, 2016 at 9:46 PM, Nigel Vander Houwen
 wrote:
> Pete,
>
> Instead of doing this in an ISR, feed the 32KHz into one of the timer/counter 
> inputs, and clock the timer off of that (probably TIMER2), then just have an 
> ISR for the overflow vector. So, when your X bit timer overflows, you can 
> just add that to your total, when you reach your 1000s (or whatever interval 
> you prefer, simply grab the current timer/counter value, add it to what 
> you’ve stored from the overflows, and you have your counts without all the 
> CPU load of an ISR for every cycle of 32KHz.
>
> Nigel
>
>> On Jun 27, 2016, at 08:22, Pete Stephenson  wrote:
>>
>> Hi all,
>>
>> I have a few Maxim DS3231 temperature-compensated real-time clock
>> chips I use for various embedded hobby projects. They're specced to
>> have an accuracy +/-2ppm between 0 Celsius and 40 Celsius. One is from
>> a standard, reputable vendor, while a few are from somewhat more
>> dubious internet sellers. While all the chips work and seem to
>> maintain reasonable time over a period of a few weeks, it's possible
>> that some don't meet spec and I'd like to test them and make sure they
>> do what they're supposed to.
>>
>> Here's what I've been doing manually, and what I hope to accomplish
>> using a microcontroller. Any tips are very welcome.
>>
>> = Manual Approach =
>>
>> I've manually tested a few of the chips using a digital storage
>> oscilloscope and a Trimble Thunderbolt's PPS output. Here's how I've
>> set things up:
>>
>> 1. Enable the 32kHz output on the DS3231 and wire it appropriately.
>> (The 32kHz output shows up on the oscilloscope.)
>>
>> 2. Set the oscilloscope to trigger on the Thunderbolt's PPS output. As
>> expected, the DS3231's 32kHz output drifts slowly relative to the PPS,
>> so the pulse train seems to move slowly to the left or right
>> (depending on the chip) on the scope.
>>
>> 3. Wait until the rising edge of one of the 32kHz pulses is (visually)
>> lined up with an arbitrary line on the scope's graticule, then start a
>> timer.
>>
>> 4. Wait until the rising edge of the next pulse drifts to the same
>> line on the graticule -- that is, it has drifted by one cycle -- and
>> then stop the timer.
>>
>> If I'm particularly motivated, I'll watch the scope for longer and
>> count the time it takes for the clock to drift two or three cycles.
>>
>> As an example, one of the clocks drifts by one cycle in 120 seconds.
>>
>> I then calculate the stability as follows:
>>
>> Stability = (1 cycle / 120 seconds) / (32768 Hz)
>> = (1 cycle / 120 seconds) / (1 second / 32768 cycles)
>> = 2.54*10^(-7)
>> = 0.254 ppm.
>>
>> Is this right so far? If so, that clock seems to be well-outperforming
>> the specs.
>>
>> I've tested a few chips at a few different temperatures (e.g in the
>> freezer, in direct sunlight, etc.) and they seem to drift faster for a
>> minute until the chip measures and corrects for the temperature
>> change, at which case the drift returns to the normal value.
>>
>> = Automated Approach =
>>
>> The manual approach is handy, but only measures short-term drift and
>> is subject to errors. I'd like to automate the measurements using a
>> microcontroller (I'm familiar with AVRs, mainly the ATmega328 and
>> ATtiny85 using the Arduino IDE, for what it's worth).
>>
>> My plan was to have the microcontroller count the number of cycles of
>> the 32kHz clock over a period of time, say 1000 seconds. If all was
>> perfect, it'd count exactly 32768000 cycles during this time.
>>
>> I'm a little concerned about the speed at which the pulses need to be
>> counted. The 32kHz pulses come in every ~30.5 microseconds, and
>> handling an interrupt on an ATmega328 running at 16MHz takes about
>> 5.125 microseconds[1] plus whatever's done in the interrupt routine
>> (e.g. incrementing the PPS counter). Would it make sense to use
>> interrupts for both the PPS counter and the 32kHz counter? Even if the
>> CPU 

Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Hal Murray]

dan...@verizon.net said:
> Maybe, but simply by adjusting mine by measuring the 32 kHz output with  an
> accurate counter I can get them to keep to within about one second a  month.

What did you adjust?  I assume it's software.

How well do typical VCO adjustments work with tuning forks?

My sample runs about 2 ppm fast but it's stable with 0.2 ppm peak-peak.

http://users.megapathdsl.net/~hmurray/time-nuts/Temp-tcxo32khz-a.png


dan...@verizon.net said:
> I doubt that any of the fancy schemes being proposed  for measurement will
> improve the basic accuracy much.

I assumed the discussion was for the fun of measuring something rather than 
than trying to make it significantly better.



-- 
These are my opinions.  I hate spam.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Dan Rae]

On 6/27/2016 1:51 PM, Hal Murray wrote:

I assume you are doing this for fun.  That means you get to do whatever you
think will be fun.

The DS3231 is pretty crappy by time nuts standards.
Maybe, but simply by adjusting mine by measuring the 32 kHz output with 
an accurate counter I can get them to keep to within about one second a 
month.  I have two incorporated in homebrew HF transceivers that I built 
and find that their performance is actually pretty impressive, /for what 
they are/.  Being able to set time zones and UTC offset from the radio's 
front panel is also handy.   After all they only claim to be a fairly 
accurate clock.  I doubt that any of the fancy schemes being proposed 
for measurement will improve the basic accuracy much.


Dan


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Hal Murray]

t...@patoka.org said:
> For very long time, may be Main Frequency (60 Hz) could be utilised.  Say,
> MCU could count and compare Zero-Crossings and impulses from DS32xx  chips.
> After several days, you'll see where it goes. 

Power in Silicon Valley isn't stable enough to make that approach interesting.

Here is the long range view:
  http://users.megapathdsl.net/~hmurray/time-nuts/line/Calif-60Hz-2014-2015.pn
g
  http://users.megapathdsl.net/~hmurray/time-nuts/line/Calif-60Hz-2015-Jul.png

If you average over long enough to smooth out the daily wobbles, you run the 
risks of hitting one of their big shifts.

25 seconds over 3 days is almost 100 PPM.


-- 
These are my opinions.  I hate spam.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Hal Murray]

I assume you are doing this for fun.  That means you get to do whatever you 
think will be fun.

The DS3231 is pretty crappy by time nuts standards.  If you can also measure 
the temperature, you should be able to make neat graphs.  If you watch it as 
the temperature ramps up slowly, you should see a sawtooth pattern.  The 
crystal will track the normal freq/temp curve until the temperature changes 
enough for the correction logic to add in another step.

Have you looked at tvb's PICPET and friends?
  http://www.leapsecond.com/pic/picpet.htm
  http://www.leapsecond.com/pic/picdiv.htm

I think he has one that turns 32KHz into PPS.  You could feed that PPS into a 
picPET running off your Thunderbolt.

If you have a spare counter, you can run that in frequency mode and feed that 
to a PC.


Where are you going to collect the data?

The PPS input on a PC may be be useful.


p...@heypete.com said:
> I'm a little concerned about the speed at which the pulses need to be
> counted. The 32kHz pulses come in every ~30.5 microseconds, and handling an
> interrupt on an ATmega328 running at 16MHz takes about 5.125 microseconds[1]
...

Use one of the counters to divide things down to a rate that is easier to 
handle.



-- 
These are my opinions.  I hate spam.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Nick Sayer via time-nuts]

> On Jun 27, 2016, at 1:34 PM, Nick Sayer  wrote:
> 
> 
> In the firmware, the timer that has the input capture ability is set to 
> free-run at the system clock frequency. The ICP interrupt reports back the 
> timer delta from the last interrupt. Nominally, you’d expect 16,384 counts. I 
> calculate the delta and accumulate that for 10 seconds before reporting the 
> result on the LCD.

Correction…

Nominally, you’d expect 10,000,000 / 16,384 counts.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Vlad]

For very long time, may be Main Frequency (60 Hz) could be utilised. 
Say, MCU could count and compare Zero-Crossings and impulses from DS32xx 
chips. After several days, you'll see where it goes.


On 2016-06-27 11:22, Pete Stephenson wrote:

Hi all,

I have a few Maxim DS3231 temperature-compensated real-time clock
chips I use for various embedded hobby projects. They're specced to
have an accuracy +/-2ppm between 0 Celsius and 40 Celsius. One is from
a standard, reputable vendor, while a few are from somewhat more
dubious internet sellers. While all the chips work and seem to
maintain reasonable time over a period of a few weeks, it's possible
that some don't meet spec and I'd like to test them and make sure they
do what they're supposed to.

Here's what I've been doing manually, and what I hope to accomplish
using a microcontroller. Any tips are very welcome.

= Manual Approach =

I've manually tested a few of the chips using a digital storage
oscilloscope and a Trimble Thunderbolt's PPS output. Here's how I've
set things up:

1. Enable the 32kHz output on the DS3231 and wire it appropriately.
(The 32kHz output shows up on the oscilloscope.)

2. Set the oscilloscope to trigger on the Thunderbolt's PPS output. As
expected, the DS3231's 32kHz output drifts slowly relative to the PPS,
so the pulse train seems to move slowly to the left or right
(depending on the chip) on the scope.

3. Wait until the rising edge of one of the 32kHz pulses is (visually)
lined up with an arbitrary line on the scope's graticule, then start a
timer.

4. Wait until the rising edge of the next pulse drifts to the same
line on the graticule -- that is, it has drifted by one cycle -- and
then stop the timer.

If I'm particularly motivated, I'll watch the scope for longer and
count the time it takes for the clock to drift two or three cycles.

As an example, one of the clocks drifts by one cycle in 120 seconds.

I then calculate the stability as follows:

Stability = (1 cycle / 120 seconds) / (32768 Hz)
= (1 cycle / 120 seconds) / (1 second / 32768 cycles)
= 2.54*10^(-7)
= 0.254 ppm.

Is this right so far? If so, that clock seems to be well-outperforming
the specs.

I've tested a few chips at a few different temperatures (e.g in the
freezer, in direct sunlight, etc.) and they seem to drift faster for a
minute until the chip measures and corrects for the temperature
change, at which case the drift returns to the normal value.

= Automated Approach =

The manual approach is handy, but only measures short-term drift and
is subject to errors. I'd like to automate the measurements using a
microcontroller (I'm familiar with AVRs, mainly the ATmega328 and
ATtiny85 using the Arduino IDE, for what it's worth).

My plan was to have the microcontroller count the number of cycles of
the 32kHz clock over a period of time, say 1000 seconds. If all was
perfect, it'd count exactly 32768000 cycles during this time.

I'm a little concerned about the speed at which the pulses need to be
counted. The 32kHz pulses come in every ~30.5 microseconds, and
handling an interrupt on an ATmega328 running at 16MHz takes about
5.125 microseconds[1] plus whatever's done in the interrupt routine
(e.g. incrementing the PPS counter). Would it make sense to use
interrupts for both the PPS counter and the 32kHz counter? Even if the
CPU is doing something, it knows an interrupt is pending so it
wouldn't miss any counts (assuming it could handle the interrupt
before the next one comes in). Alternatively, I could use a tight loop
to see if the pin for the 32kHz signal goes high and just use
interrupts for the PPS pulse. Time-sensitive code on microcontrollers
straddles the edge of my knowledge, so any advice would be
appreciated.

Seem reasonable? Any tips on doing this better?

Cheers!
-Pete

[1] http://www.gammon.com.au/interrupts


--
WBW,

V.P.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Nick Sayer via time-nuts]

I went through this exercise some time ago with my Crazy Clock.

The Crazy Clock is itself an ATTiny45 clocked with a 32 kHz crystal. I desired 
to determine the accuracy of the oscillator. I wound up making a purpose-built 
frequency counter.

First, the device under test gets special firmware that copies the system clock 
to a pin. The best I could do there is set up a timer to toggle an output on 
overflow and have it overflow constantly. The result is 16.384 kHz nominal.

The counter is a “backpack” on a 2x16 LCD display (I make a lot of those). The 
controller is an ATTiny84. 6 of its pins go to the LCD (some shared with the 
programming interface). The system clock is derived from an external input, 
which for me is supplied by a GPSDO. The board has a self-biased inverter and 
DC blocking cap on the input.

The crazy clock interface is a 1.8v LDO to supply power and an input line that 
goes to the 16.384 kHz output from the DUT. That sample line goes to the ICP 
pin on the controller.

In the firmware, the timer that has the input capture ability is set to 
free-run at the system clock frequency. The ICP interrupt reports back the 
timer delta from the last interrupt. Nominally, you’d expect 16,384 counts. I 
calculate the delta and accumulate that for 10 seconds before reporting the 
result on the LCD.

The LCD shows the actual delta, what that means in ppm and the two byte 
calibration value I write into the DUT’s EEPROM. The DUT’s *normal* flash code 
has the ability to trim the system clock by the factor stored in the EERPOM 
(signed value in 100 ppb units).

I never made this whole thing public, because it seemed to me at the time to be 
a very specialized item useful to nobody else. But I can cobble together my 
schematics and firmware. The way I wrote the code, it ought to be easy to have 
it work for other frequencies (both reference and DUT).

> On Jun 27, 2016, at 8:22 AM, Pete Stephenson  wrote:
> 
> Hi all,
> 
> I have a few Maxim DS3231 temperature-compensated real-time clock
> chips I use for various embedded hobby projects. They're specced to
> have an accuracy +/-2ppm between 0 Celsius and 40 Celsius. One is from
> a standard, reputable vendor, while a few are from somewhat more
> dubious internet sellers. While all the chips work and seem to
> maintain reasonable time over a period of a few weeks, it's possible
> that some don't meet spec and I'd like to test them and make sure they
> do what they're supposed to.
> 
> Here's what I've been doing manually, and what I hope to accomplish
> using a microcontroller. Any tips are very welcome.
> 
> = Manual Approach =
> 
> I've manually tested a few of the chips using a digital storage
> oscilloscope and a Trimble Thunderbolt's PPS output. Here's how I've
> set things up:
> 
> 1. Enable the 32kHz output on the DS3231 and wire it appropriately.
> (The 32kHz output shows up on the oscilloscope.)
> 
> 2. Set the oscilloscope to trigger on the Thunderbolt's PPS output. As
> expected, the DS3231's 32kHz output drifts slowly relative to the PPS,
> so the pulse train seems to move slowly to the left or right
> (depending on the chip) on the scope.
> 
> 3. Wait until the rising edge of one of the 32kHz pulses is (visually)
> lined up with an arbitrary line on the scope's graticule, then start a
> timer.
> 
> 4. Wait until the rising edge of the next pulse drifts to the same
> line on the graticule -- that is, it has drifted by one cycle -- and
> then stop the timer.
> 
> If I'm particularly motivated, I'll watch the scope for longer and
> count the time it takes for the clock to drift two or three cycles.
> 
> As an example, one of the clocks drifts by one cycle in 120 seconds.
> 
> I then calculate the stability as follows:
> 
> Stability = (1 cycle / 120 seconds) / (32768 Hz)
> = (1 cycle / 120 seconds) / (1 second / 32768 cycles)
> = 2.54*10^(-7)
> = 0.254 ppm.
> 
> Is this right so far? If so, that clock seems to be well-outperforming
> the specs.
> 
> I've tested a few chips at a few different temperatures (e.g in the
> freezer, in direct sunlight, etc.) and they seem to drift faster for a
> minute until the chip measures and corrects for the temperature
> change, at which case the drift returns to the normal value.
> 
> = Automated Approach =
> 
> The manual approach is handy, but only measures short-term drift and
> is subject to errors. I'd like to automate the measurements using a
> microcontroller (I'm familiar with AVRs, mainly the ATmega328 and
> ATtiny85 using the Arduino IDE, for what it's worth).
> 
> My plan was to have the microcontroller count the number of cycles of
> the 32kHz clock over a period of time, say 1000 seconds. If all was
> perfect, it'd count exactly 32768000 cycles during this time.
> 
> I'm a little concerned about the speed at which the pulses need to be
> counted. The 32kHz pulses come in every ~30.5 microseconds, and
> handling an interrupt on an ATmega328 running at 16MHz 

Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Nigel Vander Houwen]

Pete,

Instead of doing this in an ISR, feed the 32KHz into one of the timer/counter 
inputs, and clock the timer off of that (probably TIMER2), then just have an 
ISR for the overflow vector. So, when your X bit timer overflows, you can just 
add that to your total, when you reach your 1000s (or whatever interval you 
prefer, simply grab the current timer/counter value, add it to what you’ve 
stored from the overflows, and you have your counts without all the CPU load of 
an ISR for every cycle of 32KHz.

Nigel

> On Jun 27, 2016, at 08:22, Pete Stephenson  wrote:
> 
> Hi all,
> 
> I have a few Maxim DS3231 temperature-compensated real-time clock
> chips I use for various embedded hobby projects. They're specced to
> have an accuracy +/-2ppm between 0 Celsius and 40 Celsius. One is from
> a standard, reputable vendor, while a few are from somewhat more
> dubious internet sellers. While all the chips work and seem to
> maintain reasonable time over a period of a few weeks, it's possible
> that some don't meet spec and I'd like to test them and make sure they
> do what they're supposed to.
> 
> Here's what I've been doing manually, and what I hope to accomplish
> using a microcontroller. Any tips are very welcome.
> 
> = Manual Approach =
> 
> I've manually tested a few of the chips using a digital storage
> oscilloscope and a Trimble Thunderbolt's PPS output. Here's how I've
> set things up:
> 
> 1. Enable the 32kHz output on the DS3231 and wire it appropriately.
> (The 32kHz output shows up on the oscilloscope.)
> 
> 2. Set the oscilloscope to trigger on the Thunderbolt's PPS output. As
> expected, the DS3231's 32kHz output drifts slowly relative to the PPS,
> so the pulse train seems to move slowly to the left or right
> (depending on the chip) on the scope.
> 
> 3. Wait until the rising edge of one of the 32kHz pulses is (visually)
> lined up with an arbitrary line on the scope's graticule, then start a
> timer.
> 
> 4. Wait until the rising edge of the next pulse drifts to the same
> line on the graticule -- that is, it has drifted by one cycle -- and
> then stop the timer.
> 
> If I'm particularly motivated, I'll watch the scope for longer and
> count the time it takes for the clock to drift two or three cycles.
> 
> As an example, one of the clocks drifts by one cycle in 120 seconds.
> 
> I then calculate the stability as follows:
> 
> Stability = (1 cycle / 120 seconds) / (32768 Hz)
> = (1 cycle / 120 seconds) / (1 second / 32768 cycles)
> = 2.54*10^(-7)
> = 0.254 ppm.
> 
> Is this right so far? If so, that clock seems to be well-outperforming
> the specs.
> 
> I've tested a few chips at a few different temperatures (e.g in the
> freezer, in direct sunlight, etc.) and they seem to drift faster for a
> minute until the chip measures and corrects for the temperature
> change, at which case the drift returns to the normal value.
> 
> = Automated Approach =
> 
> The manual approach is handy, but only measures short-term drift and
> is subject to errors. I'd like to automate the measurements using a
> microcontroller (I'm familiar with AVRs, mainly the ATmega328 and
> ATtiny85 using the Arduino IDE, for what it's worth).
> 
> My plan was to have the microcontroller count the number of cycles of
> the 32kHz clock over a period of time, say 1000 seconds. If all was
> perfect, it'd count exactly 32768000 cycles during this time.
> 
> I'm a little concerned about the speed at which the pulses need to be
> counted. The 32kHz pulses come in every ~30.5 microseconds, and
> handling an interrupt on an ATmega328 running at 16MHz takes about
> 5.125 microseconds[1] plus whatever's done in the interrupt routine
> (e.g. incrementing the PPS counter). Would it make sense to use
> interrupts for both the PPS counter and the 32kHz counter? Even if the
> CPU is doing something, it knows an interrupt is pending so it
> wouldn't miss any counts (assuming it could handle the interrupt
> before the next one comes in). Alternatively, I could use a tight loop
> to see if the pin for the 32kHz signal goes high and just use
> interrupts for the PPS pulse. Time-sensitive code on microcontrollers
> straddles the edge of my knowledge, so any advice would be
> appreciated.
> 
> Seem reasonable? Any tips on doing this better?
> 
> Cheers!
> -Pete
> 
> [1] http://www.gammon.com.au/interrupts
> -- 
> Pete Stephenson
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Pete Stephenson]

Hi all,

I have a few Maxim DS3231 temperature-compensated real-time clock
chips I use for various embedded hobby projects. They're specced to
have an accuracy +/-2ppm between 0 Celsius and 40 Celsius. One is from
a standard, reputable vendor, while a few are from somewhat more
dubious internet sellers. While all the chips work and seem to
maintain reasonable time over a period of a few weeks, it's possible
that some don't meet spec and I'd like to test them and make sure they
do what they're supposed to.

Here's what I've been doing manually, and what I hope to accomplish
using a microcontroller. Any tips are very welcome.

= Manual Approach =

I've manually tested a few of the chips using a digital storage
oscilloscope and a Trimble Thunderbolt's PPS output. Here's how I've
set things up:

1. Enable the 32kHz output on the DS3231 and wire it appropriately.
(The 32kHz output shows up on the oscilloscope.)

2. Set the oscilloscope to trigger on the Thunderbolt's PPS output. As
expected, the DS3231's 32kHz output drifts slowly relative to the PPS,
so the pulse train seems to move slowly to the left or right
(depending on the chip) on the scope.

3. Wait until the rising edge of one of the 32kHz pulses is (visually)
lined up with an arbitrary line on the scope's graticule, then start a
timer.

4. Wait until the rising edge of the next pulse drifts to the same
line on the graticule -- that is, it has drifted by one cycle -- and
then stop the timer.

If I'm particularly motivated, I'll watch the scope for longer and
count the time it takes for the clock to drift two or three cycles.

As an example, one of the clocks drifts by one cycle in 120 seconds.

I then calculate the stability as follows:

Stability = (1 cycle / 120 seconds) / (32768 Hz)
= (1 cycle / 120 seconds) / (1 second / 32768 cycles)
= 2.54*10^(-7)
= 0.254 ppm.

Is this right so far? If so, that clock seems to be well-outperforming
the specs.

I've tested a few chips at a few different temperatures (e.g in the
freezer, in direct sunlight, etc.) and they seem to drift faster for a
minute until the chip measures and corrects for the temperature
change, at which case the drift returns to the normal value.

= Automated Approach =

The manual approach is handy, but only measures short-term drift and
is subject to errors. I'd like to automate the measurements using a
microcontroller (I'm familiar with AVRs, mainly the ATmega328 and
ATtiny85 using the Arduino IDE, for what it's worth).

My plan was to have the microcontroller count the number of cycles of
the 32kHz clock over a period of time, say 1000 seconds. If all was
perfect, it'd count exactly 32768000 cycles during this time.

I'm a little concerned about the speed at which the pulses need to be
counted. The 32kHz pulses come in every ~30.5 microseconds, and
handling an interrupt on an ATmega328 running at 16MHz takes about
5.125 microseconds[1] plus whatever's done in the interrupt routine
(e.g. incrementing the PPS counter). Would it make sense to use
interrupts for both the PPS counter and the 32kHz counter? Even if the
CPU is doing something, it knows an interrupt is pending so it
wouldn't miss any counts (assuming it could handle the interrupt
before the next one comes in). Alternatively, I could use a tight loop
to see if the pin for the 32kHz signal goes high and just use
interrupts for the PPS pulse. Time-sensitive code on microcontrollers
straddles the edge of my knowledge, so any advice would be
appreciated.

Seem reasonable? Any tips on doing this better?

Cheers!
-Pete

[1] http://www.gammon.com.au/interrupts
-- 
Pete Stephenson
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.