[time-nuts] Clock project request from IEEE

[Magnus Danielson]

Hi,

On 2019-02-22 19:31, Tom Van Baak wrote:
> I received the following email and permission to post it on time-nuts:
>
>> Hello,
>>
>> I am the executive editor of the IEEE's flagship magazine, IEEE Spectrum.
>> I recently acquired a TAPR "Pulse Puppy" and I am intrigued by the idea of
>> using it to build a very precise clock that I would share with Spectrum's readers.
>>
>> I would like to partner with an engineer with experience in digital clocks, who
>> would be credited as co-author on this project.
>>
>> Can you suggest someone who might be interested in this project? I would be
>> much obliged if you had some suggestions.
>>
>> Kind regards,
>> -Glenn
> Glenn's contact info is:
>
>> Glenn Zorpette
>> g.zorpette at ieee.org
> You can just imagine all the many ways the project could head. Send Glenn a note if you want to help. Or post here if you have suggestions.

I think we should contribute with our wealth of knowledge.

There is several aspects that would form a digital clock. Many of the 
pieces is readily available, but we rarely put them together in a system.

The TAPR Pulse Puppy is a nice little thing. I don't have one myself, 
but I can see how it could be useful, so thanks for making it aware of it.

The Pulse Puppy obviously solves two things, one having a crystal 
oscillator and output a divided down signal.

To build a clock system we should consider from where we get the time, 
and how we maintain it. These days the answer will be a GPS module which 
output it's time in serial form, such as the NMEA output format. That 
will give us the date and time of day that the PPS output represents, in 
UTC, and then the PPS pulse would give us the phase. The upside of this 
is that we get the date and time, but we don't get it adjusted to our 
local time-zone, we also depends strictly on the presence of the GPS 
signal. Also, the PPS pulse varies due to GPS properties as well as the 
clock-pulse assignment causing the sawtooth error.

As widely known in the group, sawtooth error corrections is available 
over the serial interface from several receivers. Further, to make a 
more quiet source you want to filter out some of the GPS noise. This is 
where the Pulse Puppy can come at handy, as you can steer the oscillator 
with the GPS PPS pulse and sawtooth corrections, measure the 
time-difference and then create a servo-loop to steer the oscillators 
frequency and phase to an average of that from the GPS. The produced PPS 
pulse can be made more quiet for the short term stability while 
following the GPS long-term. In that regard we can filter and get a more 
stable clock.

Another drawback may be that we loose GPS signal. There are many 
possible sources for that, but regardless which source, one needs to 
cover up the loss. This you do with hold-over, which is the secondary 
function of an oscillator. During hold-over the steering of the 
oscillator should be such that it minimize the time-error of a properly 
operating time and that of the clock in the oscillator. This is in it's 
most trivial form achieved by ensuring that the frequency steering of 
the oscillator is maintained as if it was locked to the GPS. The 
hold-over properties to a high degree depends on how well the oscillator 
is steered, and how stable the oscillator is to start with, but it ends 
being a material sport in that you go from TCXO, small OCXO, bigger 
OCXO, double-oven OCXO, rubidium clock, cesium clock etc. The GPS module 
has a small TCXO, but for these purposes you probably want to have 
something better.

The digital clock part would at first look very trivial, it has a simple 
clock counter that counts 24 hours, 60 minutes and 60 seconds. OK, so we 
need to set this clock. Oh, we might have time-zones. Oh, we might have 
shifts to and from daylight savings. Oh, we might have leap-seconds. 
Already there we have a little bit of added complexity. Nothing that 
can't be handled thought.

Also, we want to set the time from the GPS module, so that would require 
us to have a serial link just to get the NMEA data or similar at least. 
We probably want to get additional data to be warned about leap-seconds, 
get the UTC-GPS offset, GPS week number etc. A separate serial link 
would probably be useful to set time-zone data or set the time from 
another source, such as a computer timed with NTP.

It may also be interesting to encode time to be sent out. Serial 
interface, IRIG-B or similar.

Now, as we look at this, we cover quite a bit, and you can go into 
depths to do this better, as needed in professional needs. However, I 
also see a potential to teach several different concepts that comes 
together in a DIY project, which also may be very handy.

If done with a little bit of care, we can teach proper terms to be 
scientific and educational in one end, while also being very hands on 
and useful in the other.

At the same time we can "crash" into some of the challenges that the 
professional world sees, and also lots of people needs to be educated in 
too. Being hands on and simplified just makes it more concrete, rather 
than abstracts concepts. Could be very useful and educational for a wide 
audience.

Once bitten by the time-nuts bug, there is many things to improve.

Cheers,
Magnus - both hobbyist and professional