locked Clock Sync #Timesync
|
In upcoming version can you put in an indicator that let the user know if their PC clock is in sync (Green) or not (Red)?
|
|
|
|
On 28/06/2021 19:13, Dave NT9E wrote:
In upcoming version can you put in an indicator that let the user know if their PC clock is in sync (Green) or not (Red)?Dave, how do you propose that be accomplished? Note that any PC already connected to the Internet, or any other source of accurate time information like a GPS receiver, should be running a utility to keep the PC clock synchronized to UTC, so such an indication is not required. 73 Bill G4WJS.
|
|
|
|
William Smith
That was my initial response: How could you tell? And if you could tell, you should already be fixing it.
toggle quoted messageShow quoted text
However, there's at least one other potential answer: Look at the dT of everyone else you can receive, and if the (statistically significant) mean is far enough off, set up an indicator in the UI saying "Everyone else appears to be off by 1200 ms, do you think it's you?" with an option to "Sync to Mean". I think JS8Call does something like this. No, it's not ideal, and if enough people do it then you'll be chasing the majority opinion and be worse off for folks with proper time, but it would certainly make a valuable option. I've got a piece of Python code that tells me some statistics (Audio frequencies used, signal strength received, observed dT), and the dT during Field Day was _way_ more variable than on a 'normal' day, and I don't know how many were more than 2.5 seconds off and didn't even show up! The above would have been a great aid to communications for FD and other emergency communications operations. 73, Willie N1JBJ
On Jun 29, 2021, at 4:58 AM, Bill Somerville <g4wjs@...> wrote:
|
|
|
|
I was also thinking along the lines of displaying the average dT. To some extent I do that in my head and I have Meinberg installed. You just need to glance at the decode windows – if you have considerably more positive or negative than the other, you are probably off. I did notice I was considerably off once, and it looked like something had disabled Meinberg – probably a W10 update.
I do have a GPS puck but I am not sure how accurate that would be as the data packets from it are serial over USB. And the average time only sent every second.
73 Phil GM3ZZA
Sent from Mail for Windows 10
From: William Smith
Sent: 29 June 2021 11:33 To: main@wsjtx.groups.io Subject: Re: [WSJTX] Clock Sync #Timesync
That was my initial response: How could you tell? And if you could tell, you should already be fixing it.
However, there's at least one other potential answer: Look at the dT of everyone else you can receive, and if the (statistically significant) mean is far enough off, set up an indicator in the UI saying "Everyone else appears to be off by 1200 ms, do you think it's you?" with an option to "Sync to Mean".
I think JS8Call does something like this. No, it's not ideal, and if enough people do it then you'll be chasing the majority opinion and be worse off for folks with proper time, but it would certainly make a valuable option.
I've got a piece of Python code that tells me some statistics (Audio frequencies used, signal strength received, observed dT), and the dT during Field Day was _way_ more variable than on a 'normal' day, and I don't know how many were more than 2.5 seconds off and didn't even show up! The above would have been a great aid to communications for FD and other emergency communications operations.
73, Willie N1JBJ
> On Jun 29, 2021, at 4:58 AM, Bill Somerville <g4wjs@...> wrote: > > On 28/06/2021 19:13, Dave NT9E wrote: >> In upcoming version can you put in an indicator that let the user know if their PC clock is in sync (Green) or not (Red)? > > Dave, > > how do you propose that be accomplished? Note that any PC already connected to the Internet, or any other source of accurate time information like a GPS receiver, should be running a utility to keep the PC clock synchronized to UTC, so such an indication is not required. > > 73 > Bill > G4WJS. > > > >
-- 73 Phil GM3ZZA
|
|
|
|
Hi Dave,
It’s far better to use Meinberg NTP (as the instructions suggest) and not
have to worry about it.
73 -- Larry -- W1DYJ
In
upcoming version can you put in an indicator that let the user know if their PC
clock is in sync (Green) or not (Red)?
|
|
|
|
William Smith
Some GPS pucks have a PPS output, and some play software games to say “if he started sending the serial data stream on exactly the second, then it probably took X ms, so it’s really “this” time. Not sure how well those work, which is why I built up some Raspberry Pi GPS NTP servers. Which adds additional complexity in other places. 8*)
toggle quoted messageShow quoted text
73, Willie N1JBJ
|
|
|
|
Robert Lorenzini
Phil using BTKtimesync to sync from GPS you have the ability
toggle quoted messageShow quoted text
to "fudge" whatever correction you need for your computer. Bob - wd6dod
On 6/29/2021 5:36 AM, Philip Rose via
groups.io wrote:
|
|
|
|
WSJT-x has a tolerance of over 2 seconds differential clock error between sender and recipient. Therefore the solution becomes trivial: If your computer is decoding signals seen on the waterfall, you are close enough. If you aren't connected to the internet, as in "operating Field Day from a remote location without internet service (last weekend)" Meinberg will not help you. However, the 1 pps derived from a GPS hockey puck or patch antenna is close enough to keep you whistling. Second method: Find a cellphone app similar to HamGPS that can echo the cellphone site's 1 pps clock reference to your computer through a USB port, You can be up and running in near zero time.
-- Karl WA8NVW OH WA8NVW@... in WSJTX@groups.io
|
|
|
|
Richard Bertrand Larson
Consider another angle of Time Sync if an internet or gps sync is not available. JTSync is a simple utility that
provides the ability to synchronize your computer clock over a
network with world-wide NTP servers. When the Internet
connection is not available, JTSync allows you to make time
adjustments based on decoded QSOs within the WSJT-X application.
On 6/29/2021 7:36 AM, Philip Rose via
groups.io wrote:
|
|
|
|
Robert Lorenzini
The problem with that is "CALL first". Think about it.
toggle quoted messageShow quoted text
Bob - wd6dod
On 6/29/2021 11:12 AM, Karl Beckman
wrote:
WSJT-x has a tolerance of over 2 seconds differential clock error between sender and recipient. Therefore the solution becomes trivial: If your computer is decoding signals seen on the waterfall, you are close enough. If you aren't connected to the internet, as in "operating Field Day from a remote location without internet service (last weekend)" Meinberg will not help you. However, the 1 pps derived from a GPS hockey puck or patch antenna is close enough to keep you whistling. Second method: Find a cellphone app similar to HamGPS that can echo the cellphone site's 1 pps clock reference to your computer through a USB port, You can be up and running in near zero time.
|
|
|
|
Interesting how people seem to want to complicate a simple task. You could always do it the old fashioned way and manually sync to WWV. Good enough for all practical purposes, especially since FT8 is not an emergency communications mode.
73 -Jim NU0C On Tue, 29 Jun 2021 06:11:09 -0400 "William Smith" <w_smith@...> wrote: The above would have been a great aid to communications for FD and other emergency communications operations.
|
|
|
|
Steve Kavanagh
I have thought that something along the lines of "sync-to-mean" would be nice when operating portable so a GPS or cellphone connection would not be needed, but yes, people would be inclined to be lazy and just use that, which would eventually lead to different parts of the world having different time standards and other weirdness. Maybe its use could be limited to stations with /R or /P in their calls, or something like that.
73, Steve VE3SMA
|
|
|
|
Brian Stucker
If you're somewhere with no time source, but audio on the waterfall, you can set the waterfall to N Avg 3 and count how ticks in the waterfall you're off. It accomplishes the same result as the feature ask for the individual operator with no code. The problem with approximating a clock based on local decodes is that your "mean delta-T" is based on whatever stations you can hear, while my "mean delta-T" is based on whatever stations I can hear. Imagine the clock confusion when a band opens up and whole regions that were isolated from your receiver suddenly "come into view"? If we all start using arbitrary time references that are subject to significant differences due to HF propagation there's a very good chance that, as a population of stations, a significant number of stations will not be copyable at any particular point in time. There are many more stations with less sensitive receivers and antennas than ones with very good receivers and antennas. The stations with the most information to approximate the correct time, and likely correctly synchronized local clocks, will also get swamped out by stations with fewer decodes and fewer synchronized local clocks. Forcing everyone to comply with an external, disciplined, time source to get results means that the greatest number of stations will be copyable for everyone. We have a diverse community of users with varying levels of skill and experience. If you want to guide people towards a better answer, put a link to the FAQ in the settings page of the software that helps them figure out common solutions when they aren't getting decodes. 73, Brian - KB2S
On Tue, Jun 29, 2021 at 5:41 PM Steve Kavanagh via groups.io <sjkavanagh1=yahoo.ca@groups.io> wrote: I have thought that something along the lines of "sync-to-mean" would be nice when operating portable so a GPS or cellphone connection would not be needed, but yes, people would be inclined to be lazy and just use that, which would eventually lead to different parts of the world having different time standards and other weirdness. Maybe its use could be limited to stations with /R or /P in their calls, or something like that.
|
|
|
|
I use NetTime and do not have a problem but I see many station have 2 sec or more difference than what I am seeing DT. Most stations are only diferent from me by .1-.3 sec off which is fine but I see stations in Europe where they are 2-.2.3 sec different than other stations I am seeing in the activity. If your station is off how do you tell? This indicator would let them know.
|
|
|
|
Jim Brown
On 6/29/2021 1:58 AM, Bill Somerville wrote:
If my clock is within about 2 sec, I'll see DT for each station decoded. I find it easy to do a mental average of the DT values, and use TimeFudge (see W9MDB's qrz page) to tweak the clock until they're close to zero.In upcoming version can you put in an indicator that let the user know if their PC clock is in sync (Green) or not (Red)? If the clock is far enough off that there are no decodes, simply use WWV (or a GPS) and set it manually, then tweak as needed with TimeFudge. The latest JTAlert displays the average DT. Dave,Those activating rare grids, islands, or countries often don't have internet. We've run into this on FD, and used the techniques listed above. 73, Jim K9YC
|
|
|
|
Steve Kavanagh
I did experiment with using TimeFudge for Field Day (with my laptop not connected to the internet). It worked fine, but my laptop was never off by more than a second so it was easy to set by looking at the DT values.
Brian's suggestion got me experimenting today with what I could do with the waterfall, and with the clock in WSJT combined with audio from the rig. I turned on TimeFudge, slid its window so I couldn't see the cumulative total offset, then applied offsets randomly until I forgot how far it was off. Then I tried bringing it back within decoding range looking at the waterfall and estimating how far off it was, or listening to the audio while watching the clock. With a bit of practice either was good enough to get within 2 seconds, at which point a final correction with TimeFudge could be easily done based on the DT values. I think my preference was using the waterfall set to N Avg 1 and then estimating how much the offset was, rather than counting ticks at N Avg 3. None of that helps if you are in a remote location trying to to do FT8 on a dead VHF band....but does show the value of having an HF receive capability if you don't have GPS time synchronization. Still, NT9E's suggestion of a warning flag could be a useful one. 73, Steve
|
|
|
|
Jim Pennino
Agree.
I have been evaluating cheap GPS receivers for NTP use and have found that the VK-162 G-Mouse will keep a system within about 2 milliseconds of the correct time with or without internet access and costs about $15 on Amazon. Add the following two lines to ntp.conf: server 127.127.20.n minpoll 4 fudge 127.127.20.n time1 0.030 Where n is the COM port number that Device Manager says is the GPS puck. If more detail is needed, I can post an article I have written on the subject. Jim - WB6DKH
|
|
|
|
Brian Stucker
Thanks for taking a crack at it to experiment. You can get pretty close with it. Since it takes more work to triangulate your timing via the waterfall than properly synchronizing your clock I figured I'd throw that out there as a nugget for heavily compromised station circumstances. I'm obviously not on the development team, so my thoughts aren't any better or worse than anyone else's, but I still think a warning indicator would be problematic for the same reasons as before: you're relying on an entirely arbitrary frame of reference. Without a known-good frame of reference to work against, the software is just guessing with no mechanism to converge on the right answer. A few examples:
That's why I was suggesting a link to the FAQ in the place someone is likely to go to debug their station: in the settings. Only the operator knows what their intent is and what the band conditions are. 73, Brian - KB2S
On Wed, Jun 30, 2021 at 6:21 AM Steve Kavanagh via groups.io <sjkavanagh1=yahoo.ca@groups.io> wrote: I did experiment with using TimeFudge for Field Day (with my laptop not connected to the internet). It worked fine, but my laptop was never off by more than a second so it was easy to set by looking at the DT values.
|
|
|
|
Jon Ermels
That sounds "trivial" until you are 2 sec off one way and the other 50% are 2 sec the other way. 73 de NØIGU
Jon
On Tuesday, June 29, 2021, 01:24:31 PM CDT, Karl Beckman <wa8nvw@...> wrote:
WSJT-x has a tolerance of over 2 seconds differential clock error between sender and recipient. Therefore the solution becomes trivial: If your computer is decoding signals seen on the waterfall, you are close enough. If you aren't connected to the internet, as in "operating Field Day from a remote location without internet service (last weekend)" Meinberg will not help you. However, the 1 pps derived from a GPS hockey puck or patch antenna is close enough to keep you whistling. Second method: Find a cellphone app similar to HamGPS that can echo the cellphone site's 1 pps clock reference to your computer through a USB port, You can be up and running in near zero time. -- Karl WA8NVW OH WA8NVW@... in WSJTX@groups.io
|
|
|
|
Alan <n5pa@...>
Jim:
toggle quoted messageShow quoted text
I would appreciate a link to your article about using the VK-162 G-Mouse to set your PC time from the GPS Satellites. 73, Alan Clark, N5PA Ellisville, MS Email: n5pa@... URL: http://www.n5pa.com
On Jun 30, 2021, at 4:18 PM, Jim Pennino via groups.io <penninojim@...> wrote:
|
|
|