[time-nuts] GPSDO for my rubber duckie

[Michael Sokolov]

Hello time-nuts,

I've been on this list for several years now and I've made a few little
comments on occasion, but this will be my first real technical post.

I desire to build a timekeeping apparatus which I have nicknamed the
rubber duckie, or a Rubber Time Generator.  As I've voiced very
vigorously on the leapsecs list, I wish to live my personal life on a
timescale that is anchored to Earth rotation via elastic (rubber) seconds
rather than leap seconds or PHK/ITU-style total decoupling.  I do not
wish to go into the reasons for that in this thread - the leapsecs list
would be better for that - but here I am soliciting technical advice
with the actual implementation.

In technical terms I envision a device (a physical piece of hardware)
that takes MCAT (Muggle Consensus Atomic Time) as input and produces
UTR (UT Rubber) as output.  MCAT is my term that encompasses all of UTC,
TAI, GPS time, other GNSS time etc, basically all the various timescales
which produce their 1 PPS at exactly the same time but label their
seconds differently.  As a matter of practical implementation my choice
of specific MCAT realization for Version 1 of my rubber duckie will
probably be GPS.

Thus what I am soliciting on this list is advice with choosing a good
GPS receiver / GPSDO for my application, which is feeding MCAT input to
my rubber duckie.  My requirements are:

* I want to be able to disable the leap second correction in the GPS
  receiver, i.e., have it output time such that I can add a constant 19
  to it and get TAI.  (Or TAPF = Temps Atomique Pedant-Free, which is
  defined to be identical with TAI in every respect except that it is
  free from the edict of "though shalt not use TAI".)

* I'm striving to move away from the Gregorian calendar wherever I can.
  Therefore, if the GPS receiver is trying to be "user-friendly" and
  convert the date part of GPS time into Gregorian format, I want to be
  able to disable that function.  I want MJD numbers instead of Gregorian
  dates, or GPS week numbers / day-of-week / time-of-day.

* I think I need a GPSDO rather than just a GPS receiver.  The hardware
  design I have in mind for my rubber duckie is a custom PowerPC board
  on which I will run a specially modified and heavily stripped-down
  version of 4.3BSD-Quasijarus, an embedded PowerPC port thereof.

In order to run a version of 4.3BSD-Quasijarus on my custom PowerPC
board and make it do what I want (generate UTR from MCAT), I would like
to implement a circuit on my board that generates an interrupt per
millisecond.  These millisecond interrupts need to be aligned with 1 PPS
such that every 1000th millisecond interrupt also serves as an on-time
mark for MCAT (TAI/UTC/GPS/etc) seconds.

Someone please correct me if I'm missing some other simpler way, but it
seems to me that in order to generate these 1 ms interrupts with the
properties I require, I will need a 10 MHz input in addition to 1 PPS,
hence the need for a GPSDO rather than just a GPS receiver.  I envision
my clock interrupt generation logic working as follows:

* Starting at power-up boot, divide 10 MHz input by 10000 and produce an
  interrupt every 1 ms.  At this point these interrupts aren't aligned
  with anything, but they are good enough for the OS to boot.

* The FPGA in which this circuit resides gets an "acquire lock" command
  from the software.  It hunts for an external 1 PPS pulse, generates
  its own 1 ms interrupt at the same time (modulo a few cycles of 10 MHz
  for logic and synchronizer delays), and resets its divide-by-10000
  logic from there, such that all subsequent 1 ms interrupts will follow
  in proper sequence.

* In the preceding description the external 1 PPS pulse is acted upon
  only once, and all subsequent 1 ms and 1 s timing is derived from
  10 MHz.  However, there will also be a sanity check circuit that will
  look for the external 1 PPS "in the vicinity" (+/- 1 ms maybe?) of the
  internally-derived 1000th 1 ms interrupt.  If the internal and
  external 1 PPS signals disagree, signal an error indication to the
  software.  The software will then declare the UTR output as possibly
  invalid and resync itself; the resync sequence will include telling
  the FPGA to resync itself to the external 1 PPS.

In order for my clock interrupt generation circuit to work as I envision,
the 10 MHz and 1 PPS signals going from the GPSDO to my rubber duckie
will need to meet certain requirements:

1. The 10 MHz and 1 PPS signals will need to match each other in the
   sense that the 10 MHz does exactly 10 million cycles between two
   successive 1 PPS pulses.

2. Simultaneous with requirement 1, the 1 PPS signal also needs to
   indicate the "true" UTC/TAI/GPS second boundaries decoded from the
   GPS signal.  To satisfy this simultaneously with #1, the 10 MHz
   freq reference will also need to be locked to the "true" 1 PPS from
   GPS - is that what a GPSDO does?

3. I've heard something about sawtooth correction, and I'm guessing I'll
   need it in order for the 1 PPS to occur exactly every 10 million
   cycles of 10 MHz, or very close to that.  Are there any commonly
   available GPSDO types that do this sawtooth correction on their
   1 PPS output?

4. GPSDO holdover performance: I'm hoping that the GPSDO can discipline
   its 10 MHz well enough so that if GPS reception goes out "briefly"
   for some definition of "briefly", the internal PPS marks within my
   rubber duckie (every 1000th 1 ms interrupt from the FPGA) will still
   be close enough to the real 1 PPS from GPS when the latter comes back,
   such that no full resync will be required.

So, are there any commonly available (eBay etc) GPSDOs that will do
what I have in mind?  What kind of GPSDO would the more experienced
time nuts recommend for my application?

Oh, and before someone asks if I've already looked into the Soekris
net4501 - yes, I have.  I really do want to build my own PowerPC-based
board for my rubber duckie rather than use net4501.  The reason is
because my rubber duckie will be quite different from a standard NTP
server, and I really do want to run a variant of 4.3BSD-Quasijarus on
it, my very own OS.  Standard 4.3BSD runs only on VAX; ports exist to
other old-school architectures like m68k and SPARC.  There is no PowerPC
port yet, but I have been thinking of doing one for a very long time now,
so I'm ready for that adventure.  However, I absolutely do NOT want to
do an x86 port - the x86 architecture is on my no-no list.

MS