Clock Sync #Timesync


Dave NT9E
 

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)?


Bill Somerville
 

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.

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@classdesign.com> 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.




 

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


Larry Banks
 

Hi Dave,
 
It’s far better to use Meinberg NTP (as the instructions suggest) and not have to worry about it.

73 -- Larry -- W1DYJ

 

From: Dave NT9E
Sent: Monday, June 28, 2021 14:13
Subject: [WSJTX] 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)?






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*)

73, Willie N1JBJ

On Jun 29, 2021, at 8:36 AM, Philip Rose via groups.io <gm3zza@...> 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 




Robert Lorenzini
 

Phil using BTKtimesync to sync from GPS you have the ability
to "fudge" whatever correction you need for your computer.

Bob - wd6dod

On 6/29/2021 5:36 AM, Philip Rose via groups.io 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




Karl Beckman WA8NVW - AFA5VB
 

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:

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



Robert Lorenzini
 

The problem with that is "CALL first". Think about it.

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.
--
Karl  WA8NVW  OH
WA8NVW@...
in WSJTX@groups.io




Jim Shorney
 

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@compusmiths.com> 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.

Speaking from decades of software and UX design, if you give people a path of less resistance, they'll take it in droves, which means many stations will end up with a wide variety of clock references as it is easier to punch a button than do the correct calibration.

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.

73,
Steve VE3SMA



Dave NT9E
 

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:
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 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.

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,
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.
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:
  1. Should you show a warning when a subset of stations have a high dT. How does the software judge which is correct? The timing that you need is the timing that will allow you to decode the stations that you're interested in, so what does it pick for a time standard? What's the tie breaker? Is one station being far out of whack enough? It might be if that's the station you're interested in. It might not be if you want to decode other stations with a different dT.
  2. Let's say you're working a small number of stations (VHF, 60M, etc) and a station is a little behind the curve enabling TX for a cycle. Happens all the time. Does that establish a new time standard?
  3. QSB. If you have fading, that could impact all, or a majority of stations you're receiving. Again, does this indicate a problem?
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.  

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



Jon Ermels <n0igu@...>
 

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
 

Jim:

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:

VK-162 G-Mouse