Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?
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?
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?
> > 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?
>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?
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?
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?
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?
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?
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?
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?
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?
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" To: "Discussion of precise time and frequency measurement" 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 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 cas
Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?
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?
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 is doing something, it knows an interrupt is pen
Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?
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?
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?
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?
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?
> 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?
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?
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 takes about > 5.125
Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?
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?
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.