The Teensy 3.1 (http://www.pjrc.com/store/teensy31.html ~$20) has a Flex Timer Module that appears to allow a single counter to be captured into independent registers from independent inputs. Not sure, but PJRC tends to run the clock fast (96MHz) so relative timing resolution should be much better than 0.1 microseconds.

Bob LaJeunesse

Hi Can,

For a simple analog solution, you might try a 74HC4046 phase detector
followed by a diode and RC network as used in Lars Walenius' GPSDO,
described here in the archives:

https://www.febo.com/pipermail/time-nuts/2014-February/082820.html

The phase detector produces a pulse whose width equals the time difference
between the two pulses. The RC network converts this to a voltage
proportional to the time difference, which you then measure with the MCU's
A/D converter. Using the rising edge of the signal at pin 14 as the
interrupt source triggers the A/D converter at the end of the pulse, which
corresponds to the peak of the analog signal.. The 1 meg resistor
discharges the capacitor between pulses.

Lars' code also includes a filtering algorithm which does a nice job of
controlling one of the oscillators to match the 1-PPS generated by the GPS.
I have enhanced this if you are interested.

On Mon, Sep 21, 2015 at 1:45 PM, Can Altineller altineller@gmail.com
wrote:

--

--Jim Harman

On 9/21/15 12:13 PM, Robert LaJeunesse wrote:

I have, literally, a box full of teensy 3.1s at work.
If there's a quick test that would help answer any questions, I'm
willing to set them up.
I have, in the lab with the Teensys, a SRS Rb and a Wenzel OCXO (not a
superduper, just the streamline).

Is there a Flex Timer Module in the teensyduino library?

On 9/21/15 12:13 PM, Robert LaJeunesse wrote:

I was looking at the discussion of the Flex Timer on the teensy forum..
One might want to be careful about the quality of the clock fed to those
timers.  It's the regular old CPU clock, but it runs through a DPLL.
(e.g. the crystal is a 48 MHz crystal, and converted to either 72 or 96
MHz as you select..)

I run my teensys at 48MHz, so I could hook up a 1pps to a pin and log
some data pretty easily.  I suspect that the ADEV will be dominated by
the CPU crystal, so I can use any convenient 1pps.

On 9/21/15 12:13 PM, Robert LaJeunesse wrote:

A bit of googling:  FreqMeasure library for the Teensy can time stamp
zero crossings on pin 3
Apparently, the code is there to use up to 4 pins, but it's not really
set up for multiple pins.
It uses the hardware to capture, and then an ISR to unload the register
and buffer them up.

It also works on Arduinos.

https://www.pjrc.com/teensy/td_libs_FreqMeasure.html

the diagram in the K20 manual shows a two stage D flip-flop synchronizer
driven off the system clock, and then a simple rising/falling edge (or,
really, a 0->1 or 1->0 transition detector, which then latches the counter.
(Figure 37-175 in the manual)

Is this "time-nuts" precision capable. I've not tried to drive an
Arduino or teensy with an external clock, which I think might be a
starting point.

Jim,

I had the intent to try this, but never got around doing it. Thanks for
reminding me. Please share any enhancements.

I did exchange some emails with Lars, but as that project never got off
the ground, it faded out.

Cheers,
Magnus

On 09/21/2015 10:02 PM, Jim Harman wrote:

Group,

Seems to me that what's needed here is a current source for linear volts
vs. time and the cmos switching to control the duration of the capacitor
charge while the phase flip-flop is on. When it turns off, it interrupts
the processor and isolates the capacitor so it acts as a sample-and-hold
device. The processor can take its own sweet time reading the capacitor
voltage (although this sets minimum limits on the pulse duration). When
the reading has been captured, the micro toggles a FF that shorts the
capacitor with a cmos switch. The short is removed when the phase FF
toggles on.

This is a lot of analog circuitry, but it will operate as fast as the
parts are capable of switching and not at the whim of whatever the micro
is doing.

Hope that's useful. Probably already been done.

Bill Hawkins

-----Original Message-----
From: Magnus Danielson
Sent: Tuesday, September 22, 2015 3:32 PM

Jim,

I had the intent to try this, but never got around doing it. Thanks for
reminding me. Please share any enhancements.

I did exchange some emails with Lars, but as that project never got off
the ground, it faded out.

Cheers,
Magnus

On 09/21/2015 10:02 PM, Jim Harman wrote:

the GPS.

Hello All,

Another night heroically wasted, and I have achieved a PID lock within 50 /
80 000 000 th of a second between two clocks. 50 is there because it is the
minimum clock ticks for the irq handler to execute.

To summarize:

1. I am using a TI launchpad running at 80mhz. I was using micros() to
   measure time, but then I realized I could use SysClockTicks, which is
   80,000,000 per second. In Energia, I had to use: time_micros =
   HWREG(DWT_BASE + DWT_O_CYCCNT) to get the sysTicks. I am not sure if PID
   algorithm is the right one for tuning clocks, but thats what I only knew.

2. The diffuculty arises from the fact that I am using 1pps signal to tune
   a DS3231, which also gives out a 1pps signal, (it can be configured to give
   faster pulses, but then when I modify the ppms, they wont be reflected in
   the pulse output) So in order to observe the reaction after setting aging
   register, I have to compare 1pps signal.
   If I had a RTC with a tunable 10mhz clock, I could feed that into a PLL /
   counter, not the case. Eitherway, I am in the process of ordering a VCTCXO,
   and probably will build my own RTC.

3. I have investigated and experimented different interrupt schemes, like
   taking measurements on both rising and falling edge, and XOR'ing the clock
   signals. Using a 74hc74 and a XOR gate, I have made a mini-circuit so that
   if one clock is lagging behind, it will send pulses from one pin, and if
   reverse, it will pulse from other pin. However this scheme failed because
   same difficulty with interrupts arise again. The pulse is too fast in order
   to trigger interrupts on the falling and rising edge, and measure time.

4. I think an analog solution like Bill Hawkins described, would be best
   suited for this task. But I have not understood it enough to build it.

Best Regards,
C.A.

On Wed, Sep 23, 2015 at 7:25 AM, Bill Hawkins bill@iaxs.net wrote: