I was basically planning on feeding the OCXO and the PPS from a GPS module
into a simple microcontroller.
If you feed the PPS from a GPS into a microconroller, you can work out the
clock speed on the microcontroller.
If you feed the serial signal from the GPS into the microcontroller, you can
learn the time of each PPS and also know if the GPS is working or not.
If you feed the OCXO into a timer/counter block, you can work out the
frequency of the OCXO.
If you do that in a microcontroller next to the Pi, you are basically making a
GPSDO.
You will need another counter/timer block to make a PPS, copying the one from
the GPS when the GPS is working and tracking the OCXO when the GPS is not
happy.
You will also need a serial output to tell ntpd the time of each PPS.
You could also use the Pi for the microcontroller. There is an API to the
Kernel timekeeping routines. Try man ntp_adjtime. There are 2 knobs. One is
to adjust the speed of the clock, aka correct for the drift. The other is to
adjust the offset by adjusting the speed to be a bit fast or slow for the
right amount of time.
If you get that working, you can run ntpd using the localclock driver.
That all sounds like fun without much soldering.
The other approach is to use the OCXO to drive the CPU clock on the Pi,
perhaps using a PLL chip to get the right frequency. That will simplify the
software.
Joe Bennett said:
There is a crappy discussion in there about using an OCXO where the Pi is
using a crystal.
If you look at the data sheet for the ARM chip on the board you will find that
there are 2 pins for the crystal. It's setup so you can feed an external
clock into one of them. The data sheet will tell you which one and what
voltage level it expects.
--
These are my opinions. I hate spam.
> I was basically planning on feeding the OCXO and the PPS from a GPS module
> into a simple microcontroller.
If you feed the PPS from a GPS into a microconroller, you can work out the
clock speed on the microcontroller.
If you feed the serial signal from the GPS into the microcontroller, you can
learn the time of each PPS and also know if the GPS is working or not.
If you feed the OCXO into a timer/counter block, you can work out the
frequency of the OCXO.
----------
If you do that in a microcontroller next to the Pi, you are basically making a
GPSDO.
You will need another counter/timer block to make a PPS, copying the one from
the GPS when the GPS is working and tracking the OCXO when the GPS is not
happy.
You will also need a serial output to tell ntpd the time of each PPS.
-----------
You could also use the Pi for the microcontroller. There is an API to the
Kernel timekeeping routines. Try man ntp_adjtime. There are 2 knobs. One is
to adjust the speed of the clock, aka correct for the drift. The other is to
adjust the offset by adjusting the speed to be a bit fast or slow for the
right amount of time.
If you get that working, you can run ntpd using the localclock driver.
That all sounds like fun without much soldering.
--------
The other approach is to use the OCXO to drive the CPU clock on the Pi,
perhaps using a PLL chip to get the right frequency. That will simplify the
software.
Joe Bennett said:
> https://raspberrypi.stackexchange.com/questions/74482/switch-out-the-x1-oscill
> ator-on-a-rpi-2-3
There is a crappy discussion in there about using an OCXO where the Pi is
using a crystal.
If you look at the data sheet for the ARM chip on the board you will find that
there are 2 pins for the crystal. It's setup so you can feed an external
clock into one of them. The data sheet will tell you which one and what
voltage level it expects.
--
These are my opinions. I hate spam.
