Teensy3.1 and Flextimer(s?)

Status
Not open for further replies.
@TelephoneBill - As there are several unused channels available, you could try using a delayed version of the signals that may provide more information for that statistical / probabilistic control loop. As the time intervals at stake are so small, perhaps a simple wire length could work as delay line.

Say, feed the same signal to channel 0 through a short wire and to channel 2 through a long, half meter, wire.
 
I see your idea. Have to have a think about it and whether worth the extra...

You may be pleased to know that removing that redundant zero statement did make a significant improvement Much improved "cyclic consistency" on timer values. What I found was that the flextimer counter value now decreased more slowly for every reading (at one second intervals) and "wrapped around under zero" to get back to 47,999. It took approx 65 seconds to complete a "value cycle". This decrease is because the flextimer system clock is not perfect (slightly under 48 MHz).

This prompted me to recall a previous debate (see post https://forum.pjrc.com/threads/28098-Crystal-pull-range-on-3-1?highlight=MHz+crystal). By altering the OSC0_CR register controlling the 16 MHz crystal oscillator (to OSC0_CR = 0x02) I then found that "wrap around under zero" slowed down even further to take 197 seconds for a complete value cycle.

Previous work showed for default OSC0_CR = 0x0A, crystal freq measured 15,999,762 Hz, and for OSC0_CR = 0x02 measured 15,999,922 Hz (much better only 78 Hz slow). This affects the flextimer by a factor of 3, so now my flex system clock is predicted 3 times 78 Hz = 234 Hz under the perfect value of 48,000,000 Hz. It is losing 234 "ticks" every second (compared to perfect), and this takes 48,000,000 divided by 234 = 205128 cycles to recover. With 1000 wrap-around cycles happening per second, this predicts 205 seconds for counter value to complete its value cycle. I think this is close enough to the 197 seconds actual observed to be believable.

What I'm now wondering is... "Could this be an easy method for any Teensy user to measure their own specific 16 MHz crystal frequency precisely?" - just by timing the time in seconds it takes for a flextimer to complete a full "value cycle"? I have the benefit of a Ruby standard, but would this method work without it? Sounds too good to be true :) !!
 
Final Update...

The attached picture shows the performance of the "software phase detector" (using Flextimer 0) once it has settled. As before, Trace 1 (Yellow) is the positive going edge of the 100 KHz sq wave derived from the 10 MHz OCXO. Trace 2 (Light Blue) is the positive going edge of a 1 PPS signal from the Rubidium Frequency Standard (RFS = FE5680B). Trace 3 (Purple) is the 10 MHz OCXO sine wave. Trace 1 is locked to Trace 3 (through the 74HC390 divider) Trace 2 is locked to Trace 1 through the "software phase detector". Hence the 10 MHz OCXO of Trace 3 is locked to the RFS 1PPS (Trace 2), so is an exact multiple.

SoftwarePhaseDetector.jpg

The drift of Trace 1 with respect to Trace 2 is never more than +/- 3 nanoSecs once the "detector" has settled, and it takes about 10 minutes to reach a stable state such as shown in the picture. Thanks to colleagues for their contributions.
 
Status
Not open for further replies.
Back
Top