I would like to +1 this use case for a different reason.
I run a few time synced Raspberry pi/sdr/gqrx/wsjtx wspr monitors continuously. The slow receive chain routinely reports >2 second DT errors on all stations. Al WB1BQE Sent from BlueMail On Mar 4, 2021, 11:56, at 11:56, Derek Turner via wsjt-devel <wsjt-devel@lists.sourceforge.net> wrote: >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 > > > >------------------------------------------------------------------------ > >NIL > >------------------------------------------------------------------------ > >_______________________________________________ >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
