[time-nuts] GPSDO for my rubber duckie

Henry Hallam henry at pericynthion.org
Tue Aug 2 02:26:13 UTC 2011


The parameters you'll want for conversion between MCAT and mean solar
time are given daily in the IERS bulletins:
http://hpiers.obspm.fr/eop-pc/products/bulletins/bulletins.html

By making use of these you should be able to do much better than the
slightly inelegant leap second rubberization-over-10-seconds method
you had proposed.  Your rubber seconds should be smooth and
continuous, to the limit of the IERS measurement accuracy.

Good luck,
Henry

On Mon, Aug 1, 2011 at 12:23 PM, Michael Sokolov
<msokolov at ivan.harhan.org> wrote:
> 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
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>




More information about the Time-nuts_lists.febo.com mailing list