Otherwise, the bit should be set low.
Only, DTs with trustworthy bit set high are used to do any clock correction.
Otherwise, you run the risk of temporal drifting like frequency drifting of free running vcos.
BCNU DE N2LO~>
-----Original Message-----
From: wsjt-devel@lists.sourceforge.net
To: wsjt-devel@lists.sourceforge.net
Cc: g4...@yahoo.com
Sent: 2021-03-04 11:56:52 AM
Subject: Re: [wsjt-devel] clock offset / fudge adjustment, automatic/manual
I find this interesting because a while ago I suggested something similar where the system clock could be adjusted in order to synchronise with and work rare DX stations whose clocks were significantly erroneous. I started experimenting but lost interest when the particular problem I was having with an African station just went away.
There is nothing wrong with adjusting the system clock if it is wrong. Many of us use the Thinking Man software Dimension 4 which indeed does adjust the system clock. There is similar software for other operating systems.
"Simply put, Dimension 4 is the fastest and easiest way to synchronize your computer's clock if you're running a Windows-based operating system. Once Dimension 4 is installed, you'll most likely forget that it's even running. It's that automatic."
The only scenario where I see that a utility to adjust the system clock is required is where you are unable to connect to the internet or other time standard.
I would not wish to burden the developers with the task of incorporating this into WSJT-x. Instead I believe it should be a small stand alone application.
It does not need fancy algorithms. By inspection of the DT column in the Band Activity window and ignoring outliers, if the balance between positive and negative delta times is off then you would press a button to nudge the system clock by (say) 1/10th of a second until the balance is restored.
Anybody ?
73 de G4SWY Del +++
On Thursday, 4 March 2021, 15:53:04 GMT, David Smith <dsm...@mypchelp.com> wrote:
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
_124
Description: Binary data
_125
Description: Binary data
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
