[time-nuts] Clock project request from IEEE

Sun Feb 24 16:09:30 UTC 2019

Hi,

Yes, that would be a cool feature, but would come with complexity that 
would be best outside of such a core system. With enough interface, you 
could let an off-system configuration tool do that and then setup the 
time-zone rules. Conversion from position to time-zone and then look up 
the time-zone data is conceptually no hard, but clearly not a handful of 
lines of code in small MCUs. The benefit of keeping that as separate 
system is that the core functionality can be tested and well understood, 
and such add-ons does not need to be run very often or be part of the 
real-time, so then they should be run separate. The important thing is 
that the core system is built such that it allows this add-on later. So, 
the off-line system should be able to get the time and positiion and 
then be able to set the time-zone offsets and cut-over rules. The later 
may actually at first be forced to be just cut-over time for new offset, 
but maybe it is simple enough to express the full rules with a handful 
of parameters.

As always, the devil is in the details, and the system architect needs 
to make the core system as simple as possible while flexible enough, 
although fairly stupid. More intelligent adaptation can then be added. 
Keeping things robust and testable has challenges.

This is also the challenge of doing designs, the creeping featurism. 
It's somewhat of an art form to balance simple enough and providing ways 
to support cool features later.

Anyway, there would be many pieces of a beast like this that I would 
priority first. Once a core functionality works, only then features can 
be added. One of the keys to succses is clear monitoring of error 
conditions, which helps already in the early integration to figure out 
issues quickly.

Cheers,
Magnus

On 2019-02-24 12:51, John Reid wrote:
> I would love something that gave a list of options set from the location in the NMEA string.
>
> Such as this time zone or different, with nearby zones first; DST on/off. Could get to be a significant effort very quickly, but maybe there are xml files out there that would make it easy?
>
>
> John
>
>
> On 24/2/19 4:00 am, time-nuts-request at lists.febo.com<mailto:time-nuts-request at lists.febo.com> wrote:
>
> Message: 4
> Date: Sat, 23 Feb 2019 15:47:11 +0100
> From: Magnus Danielson <magnus at rubidium.se><mailto:magnus at rubidium.se>
> To: time-nuts at lists.febo.com<mailto:time-nuts at lists.febo.com>, Glenn Zorpette <g.zorpette at ieee.org><mailto:g.zorpette at ieee.org>
> Subject: Re: [time-nuts] Clock project request from IEEE
> Message-ID: <4d54789a-e3eb-46f6-0d0d-523954c419fb at rubidium.se><mailto:4d54789a-e3eb-46f6-0d0d-523954c419fb at rubidium.se>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> 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<mailto: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
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.