time-nuts@lists.febo.com

Discussion of precise time and frequency measurement

View all threads

NTP linked PC clock is slightly ahead of Lady Heather GPS time

MS
Mark Sims
Wed, Oct 11, 2017 3:21 PM

Lady Heather's screen clock ticks when the time message comes in (which can be offset from the actual time in the message).  Heather applies a receiver type dependent adjustment to the time in the message and then displays the time.  If you enable the digital millisecond clock you will see that the clock does not necessarily tick at hh:mm:ss.000

The next release of Heather has an audible tick clock mode where it ticks at hh:mm:ss.000  This can be used to set your watch more accurately, etc.

Lady Heather's screen clock ticks when the time message comes in (which can be offset from the actual time in the message). Heather applies a receiver type dependent adjustment to the time in the message and then displays the time. If you enable the digital millisecond clock you will see that the clock does not necessarily tick at hh:mm:ss.000 The next release of Heather has an audible tick clock mode where it ticks at hh:mm:ss.000 This can be used to set your watch more accurately, etc.
PK
Poul-Henning Kamp
Thu, Oct 12, 2017 9:11 AM

The next release of Heather has an audible tick clock mode where
it ticks at hh:mm:ss.000  This can be used to set your watch more
accurately, etc.

Consider the potential for people to attach wires to the PC-speaker
as a means to get an electrical signal also.

These days the speaker is almost the last usable interface for this.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

-------- In message <SN1PR11MB102409EF442D98A98BFEC447CE4A0@SN1PR11MB1024.namprd11.prod.outlook.com>, Mark Sims writes: >The next release of Heather has an audible tick clock mode where >it ticks at hh:mm:ss.000 This can be used to set your watch more >accurately, etc. Consider the potential for people to attach wires to the PC-speaker as a means to get an electrical signal also. These days the speaker is almost the last usable interface for this. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
CW
Chris Wilson
Thu, Oct 12, 2017 11:38 AM

Hello time-nuts folk,

Thanks  for  all  the replies, I see now that it is nothing to concern
myself  with, and my curiosity is satisfied, much appreciated, you are
true  time  experts!  :)  Good  to  see  Lady  Heather continues to be
updated, thanks Mark.

on 12/10/2017 12:36  you wrote:

Lady Heather's screen clock ticks when the time message comes in
(which can be offset from the actual time in the message).  Heather
applies a receiver type dependent adjustment to the time in the
message and then displays the time.  If you enable the digital
millisecond clock you will see that the clock does not necessarily tick at hh:mm:ss.000

The next release of Heather has an audible tick clock mode where it
ticks at hh:mm:ss.000  This can be used to set your watch more accurately, etc.


time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

--
Best Regards,
Chris Wilson.

Hello time-nuts folk, Thanks for all the replies, I see now that it is nothing to concern myself with, and my curiosity is satisfied, much appreciated, you are true time experts! :) Good to see Lady Heather continues to be updated, thanks Mark. on 12/10/2017 12:36 you wrote: > Lady Heather's screen clock ticks when the time message comes in > (which can be offset from the actual time in the message). Heather > applies a receiver type dependent adjustment to the time in the > message and then displays the time. If you enable the digital > millisecond clock you will see that the clock does not necessarily tick at hh:mm:ss.000 > The next release of Heather has an audible tick clock mode where it > ticks at hh:mm:ss.000 This can be used to set your watch more accurately, etc. > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. -- Best Regards, Chris Wilson.
BK
Bob kb8tq
Thu, Oct 12, 2017 12:14 PM

Hi

On Oct 12, 2017, at 5:11 AM, Poul-Henning Kamp phk@phk.freebsd.dk wrote:


In message SN1PR11MB102409EF442D98A98BFEC447CE4A0@SN1PR11MB1024.namprd11.prod.outlook.com, Mark Sims
writes:

The next release of Heather has an audible tick clock mode where
it ticks at hh:mm:ss.000  This can be used to set your watch more
accurately, etc.

Consider the potential for people to attach wires to the PC-speaker
as a means to get an electrical signal also.

These days the speaker is almost the last usable interface for this.

….. and the mic input is one of the few inputs left to feed “events” into.

Bob

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Hi > On Oct 12, 2017, at 5:11 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > > -------- > In message <SN1PR11MB102409EF442D98A98BFEC447CE4A0@SN1PR11MB1024.namprd11.prod.outlook.com>, Mark Sims > writes: > >> The next release of Heather has an audible tick clock mode where >> it ticks at hh:mm:ss.000 This can be used to set your watch more >> accurately, etc. > > Consider the potential for people to attach wires to the PC-speaker > as a means to get an electrical signal also. > > These days the speaker is almost the last usable interface for this. ….. and the mic input is one of the few inputs left to feed “events” into. Bob > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.
TV
Tom Van Baak
Thu, Oct 12, 2017 4:04 PM

These days the speaker is almost the last usable interface for this.

….. and the mic input is one of the few inputs left to feed “events” into.

Yes, and by connecting the speaker to the mic and issuing a pulse through the speaker you can estimate the latency of the OS. It should act like an echo chamber and the number of echoes per second is your inverse latency.

The other trick is to use a TIC to compare the output pulse(s) against your house GPS/1PPS. You then compare the timestamp that the OS thought it was with the real UTC+TIC timestamp. Similarly, put a GPS/1PPS into the mic and compare the time the OS thinks it saw the pulse.

The results of these should give a nice pair of UTC offset and jitter plots. If at the same time you also measure the XO directly you can then subtract and pinpoint how much of the error is due to the XO and how much is due to OS design. For extra credit put NTP into the mix and see how badly NTP s/w performs compared to what a h/w solution could so.

/tvb

>> These days the speaker is almost the last usable interface for this. > > ….. and the mic input is one of the few inputs left to feed “events” into. Yes, and by connecting the speaker to the mic and issuing a pulse through the speaker you can estimate the latency of the OS. It should act like an echo chamber and the number of echoes per second is your inverse latency. The other trick is to use a TIC to compare the output pulse(s) against your house GPS/1PPS. You then compare the timestamp that the OS thought it was with the real UTC+TIC timestamp. Similarly, put a GPS/1PPS into the mic and compare the time the OS thinks it saw the pulse. The results of these should give a nice pair of UTC offset and jitter plots. If at the same time you also measure the XO directly you can then subtract and pinpoint how much of the error is due to the XO and how much is due to OS design. For extra credit put NTP into the mix and see how badly NTP s/w performs compared to what a h/w solution could so. /tvb