On 23/07/2017 12:53, David Tiller wrote:
Perhaps for the very tightly time-constrained modes a simple
computation comparing the received delta-T's of all received signals
could be made. If everyone else's clocks seem consistently wrong,
maybe it's you!
An indication of that made by turning the time readout red, perhaps,
or by having an option to allow that derived time offset to be used to
correct the clock time.
A bit more convoluted solution would be to have a new 'time set' mode
that DSPs one of the WWV signals. We're dsp and radio nerds, right? :-)
A simple C/C++ ntp client could also be included either as an
ancillary program that could be exec'd or built in to the GUI. There
are some that are quite simple - less than 100 lines of code. They're
crude, yes, but we're not looking for sub-mS precision here.
Hi David,
there are many such set up issues that could be detected but we have to
set the boundaries of where one application manages. I certainly think
time accuracy is in the operating system domain or maybe a third-party
utility and not the responsibility of WSJT-X. Another out of domain
example might be seeing all signals are weak and suggesting that an
aerial may not be connected or maybe even to go and purchase a bigger
one! Time sync is part of building a station these days and as important
as transmitting a clean signal or many of the other things operators are
responsible for when undertaking this hobby.
73
Bill
G4WJS.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
