As someone who has met this very issue in practice it's not quite as simple
or black and white as implied.
Yes my GPS dongle works, but as I said when operating portable with access
on foot, probably a long way up a hill, it's a different matter, every last
ounce or gram carried can feel like it counts, a lot!
Furthermore, it's something else to be plugged together maybe with either
gloved fingers or cold fingers, with consequent increased risk of breaking
something.
With my dongle I also get an intermittent issue with W10 seemingly
forgetting the USB enumeration, and having to reset the GPS software to
find the dongle again. I still haven't got to the bottom of that one, as
it of course never happens when I try to troubleshoot...
Given adequate preparation before a portable trip no system clock will be
minutes, hours or days out, so in my view that's irrelevant.
Whether a nudge button would be useful or work for me I don't know, because
from experience my clock drift is quite dynamic and unpredictable, but
great to see new constructive ideas being presented.
Alan G0TLK, sent from my mobile device
On 4 March 2021 16:46:19 Jim Pennino via wsjt-devel
<wsjt-devel@lists.sourceforge.net> wrote:
From: David Smith <dsm...@mypchelp.com>
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] clock offset / fudge adjustment,
automatic/manual
Message-ID:
<CAMKtzE_5636S4=0jdzwsbbrl8aomshbtzzj142nbmgpr8jo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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.
WSJT depends on YOUR system clock being correctly set, not the clock
settings of other stations.
Setting YOUR system clock to the correct time is trivial.
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.
If YOUR clock is correctly set, there is no need to do anything else.
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.
Computer systems already have "other devices or software" to set the system
clock
correctly and they have absolutely nothing to do with WSJT or how
complicated it is
to operate WSJT. In fact, if the system clock is correctly set, that is one
less thing
that needs "fiddles" to use WSJT. There are many things in a computer that
depend
on the date and time setting to some degree of accuracy besides WSJT.
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.
A USB GPS receiver draws at most a few tens of milliamps, hardly a power
burden for
portable operation. It will also keep the system clock correctly set when
not operating
portable. The power required to run the software is so small it is not
measurable.
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.
And your QSO records would also be off by minutes, hours, days; not a good
idea.
You seem have some kind of fixation on avoiding setting your system clock
to the
correct time which I totally fail to understand.
The software to keep system clocks correctly set has been around for over
35 years
and cheap GPS receivers have been available for many years now; this is NOT
bleeding
edge technology.
As the problem of setting a computer system clock to the correct time was
solved
decades ago, you are beating a dead horse.
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
