characterizing the performance of the teensy oscillator
jimlux, are you aware of Constantin's work
tuning the time and temperature features? I'm no time expert myself, but there are a few folks around here who seem pretty knowledgeable. Also there has been some detailed exploration into chasing down all the variability due to standard interrupts and running code out of flash vs RAM. Sorry to say, I didn't find a good links.
In this case, the FreqMeasure library uses the K20's FTM to latch a counter whenever the 1pps comes in, and then it's unloaded by a (timing non-critical) ISR.
I was prompted to do this by a comment on the time-nuts mailing list (
http://www.leapsecond.com/time-nuts where folks are interested in precise measurement of time and frequency) that mentioned the FTM module. What would have been more interesting is the ability to use an external clock (e.g. a stable 5 or 10 MHz) rather than the processor clock, but unfortunately, the external clock input pins are also used as the 16 MHz crystal pins.
There's an approximate block diagram in the K20 manuals, but it's always nice to get some real data. There can be extra resynchronizing stages between external pin and internal latch, for instance, which can add some non-determinstic delays. And if you're interested in nanosecond kind of timing, there's always the whole metastability issue in the synchronizer. The K20 appears to have a standard "two D latches in series" synchronizer driven by the 48 MHz internal clock at the input to the FTM logic.
In any case, I was interested in the relative performance of the on-board crystal too. I have a system which uses 5 teensys, and an application which relies on them being synchronized. Knowing the magnitude of the clock differences lets me figure out how often I need to synchronize them. For instance, if they need to be synchronized to within 1 millisecond, a 1ppm oscillator frequency difference will drift out of sync in 1000 seconds.
And, of course, I'm just curious. I don't know the part number for the crystal so I can't go look up it's nominal type. I suspect it's a AT cut (most common).
The idea of measuring the temperature to compensate for frequency shifts in software has been around for a while, and particularly with cheap CPU or FPGA horsepower, it's attractive as an alternative to a TCXO. A TCXO uses a temperature sensitive hardware component to "pull" the crystal frequency and compensate. That means the Q of the crystal has to be less (so it's pullable), which means the close in phase noise and jitter will be worse. The challenge is getting a sufficiently accurate temperature measurement (the most accurate thermometers are quartz crystals). A halfway decent crystal will have a frequency variation of 10s of ppm over 10s of degrees, so that implies that to get better than 1ppm (which is easy TCXO territory) you need to have temperature measurement to small fractions of a degree, which is difficult. In any case, if you're driving a digital direct synthesizer (DDS) with the oscillator, it's easy to program in a new frequency.
In fact, one of the cleverest schemes is to use a crystal that oscillates at both the fundamental and the third overtone, and compare those two frequencies. As temperature varies, the overtone doesn't go in strict x3 of the fundamental, and the difference is very predictable and can be used to accurately measure the temperature of the crystal. (This is called a MCXO in some of the literature).