[time-nuts] GPSDO for my rubber duckie

Chris Albertson albertson.chris at gmail.com
Mon Aug 1 19:58:23 UTC 2011


You left out the most important requirements.

1) How acurate does this all need to be?  Is 1/10 of a second good
enough or is this all to run at the "handful of nano seconds" level?

2) How is the time to be output or displayed?  Are we driving an
analog clock with sweep second hand or a time code generator?

If All you need is a digital clock display on an LCD that is accurate
enough to be perceived by eye as "perfect"  then this whole thing is
nearly trivial to build because your eyes are not so good (remember
that a 24 frame per second movie completely fools your eyes into
thinking it's continuous motion.  So an update 30 times per second is
better then you need for a visual clock display.

In engineering something like this it is very impotent NOT to mix up
"primary requirements", "derived requirements", "implementation
details".

"primary requirements" describe the thing you want, NOT how it works.
Derived ones are the logical fallout from the first ones.

It takes great discipline to NOT jump into implementation.  So I don't
blame you for talking about GPS and 10Mhz oscillators and what kind of
CPU will be inside.   But leave all of that for later.


All that said.  If the goal is a visual display you can do this with
off the shelf hardware and software pus a bit of custom software

I don't 100% understand your time keeping system.  You say it's based
on Earth rotation.  Is it like this
http://en.wikipedia.org/wiki/Sidereal_time




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.
>



-- 

Chris Albertson
Redondo Beach, California



More information about the time-nuts mailing list