[ntp:questions] Making ntpd tweak a TCXO

Mark Haun mark at hau.nz
Fri Jan 29 16:59:03 UTC 2016

Hal Murray [hmurray at megapathdsl.net] wrote:
> > > I'm assuming your TCXO is driving your A/D.
> >
> > Yes.  It spits out samples at a rate f_osc / 240000 = 60 Hz.  My ultimate
> > task is to timestamp these samples in such a way that there are compressions
> > and dilations in the time scale, but no discontinuities. 
> 60 Hz is pretty slow.  The PPS logic will work at that speed.
> Can you feed the A/D trigger signal into something that the kernel PPS 
> supports?  You don't actually need the A/D trigger signal, just something 
> that is derived from your TCXO.

The A/D is a sigma-delta type where you set the output sample rate and it
runs autonomously (locked to the input clock of course).  "Sample ready" is
indicated by a falling edge on the SPI MISO line, and I am bitbanging the
serial interface from the PRU (Programmable Realtime Unit, a fully
deterministic uC core which communicates with the main processor and OS via
shared memory and interrupts).  So it may be possible to timestamp those
falling edges by connecting the MISO line to one of the supported PPS input
pins, and arming/disarming the timestamping on every sample (because the
line will also have lots of transitions in the course of transferring each
24-bit sample).

Another option, since I wait on that falling-edge ready signal in my PRU
code, is to timestamp there, programmatically, by reading a timer.  This
would get me within a single PRU cycle (5 ns), completely deterministic.

What I am unclear on is how to take that timer snapshot/timestamp, and
convert it into wall-clock time.  The latter is only available from inside
the OS (Linux).  I do not understand, practically speaking, how these single
instants in time are carried across the boundary from the realtime world
into the nondeterministic world of the OS.  Presumably this is what the
Linux PPS code does?


More information about the questions mailing list