To clarify my use case and some reasoning:

1) Since WSJT is highly dependent on clock accuracy, there should be a way
to either manually or automatically sync the clock to received stations.
2) I'm not suggesting at all that WSJT modify the system clock. In fact, my
suggestion is that WSJT leave the system clock alone, and that we add a
feature that allows offset to the system clock.
3) Using other devices or software to do this for you adds complexity that
isn't necessary; ntpd, chrony, GPS, all of these add new dependencies and
fiddles/adjustments that make using WSJT more complicated to use.
4) Really the main problem to solve here is portable operation.  Adding
more software, or more hardware, to solve this problem uses more power and
reduces battery life.
5) potentially, allowing an automatic offset adjustment within the software
itself to average the clocks of received stations has the potential to
completely eliminate the need for "accurate clocks" across the board. Of
course, this is assuming everyone using FT8 (as an example) was using WSJT
or software capable of this automatic adjustment.  If I'm not mistaken
(which is entirely possible) clocks could be off by minutes, hours, days,
etc, as long as the second hand lines up with received stations.

On Thu, Mar 4, 2021 at 4:02 AM <wsjt-devel-requ...@lists.sourceforge.net>
wrote:

>
> Date: Thu, 04 Mar 2021 10:43:36 +0000
> From: Alan <al...@alangroups.plus.com>
> To: WSJT software development <wsjt-devel@lists.sourceforge.net>
> Subject: Re: [wsjt-devel] clock offset / fudge adjustment,
>         automatic/manual
> Message-ID:
>         <
> 177fcd5f3c0.27f6.308160ffa91046202f89ff6226309...@alangroups.plus.com>
>
> Content-Type: text/plain; charset="us-ascii"; Format="flowed"
>
> In my experience portable operation does indeed have a problem with
> drifting clocks due to temperature variations, and particularly wind.
>
> Internet connectivity may well be unavailable, so I've bought a cheap GPS
> dongle that does the job just fine.
>
>
> I'm not sure a fixed clock adjustment will deal with it though, because
> I've found the drift on my laptop to be rather dynamic and it could soon
> get out of step.  I agree changing the system clock would be unwise.
>
>
> Averaging received time differentials to provide a correction is an
> interesting thought though, but in my view providing that was done only
> inside WSJT-X and only for the current session - no changes to the system
> clock itself, or permanent config changes.
>
>
> Alan G0TLK
> On 4 March 2021 07:31:47 Claude Frantz <claude.fra...@bayern-mail.de>
> wrote:
>
> > On 3/4/21 1:53 AM, David Smith wrote:
> >
> >> Proposal:
> >> Add an adjustment that allows you to manually adjust an offset to the
> >> system clock.  Being able to simply enter +/- seconds at the 100ths of a
> >> second would be helpful, ie: "-2.3s" or "+0.9s"
> >
> > Hi David and all,
> >
> > If you use ntpd or chrony, you have the ability to insert this data in
> > the appropriate config of these pieces of software.
> >
> > This has no place in the software using the time services.
> >
> > Best wishes,
> > Claude (DJ0OT)
> >
>
>
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Reply via email to