[time-nuts] GPSDO for my rubber duckie
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:
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.
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.
> 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