Locked #windows11 #Timesync #windows11 #Timesync


Glen Jenkins WB4KTF
 

I have a question about Time Sync.
When I look at the DT column, I see most folks with a DT close to ZERO (0.1s, 0.2s, -0.1, and some 0.3 or -07). I am using the program NetTime that I have set to reset my time every 15 minutes.
Yet I have had 2 close hams in my area tell me that I am 1.5s to 2.0s OFF on their DT displays. Can I be off on receive yet OFF by that much on transmit?
If so, what or where do I adjust this?

--
Glen, WB4KTF
Austin, TX


Pietro Molina
 

What is the rig and you're using split or fake it?

Pietro (mobile)

Il sab 25 mar 2023, 14:25 Glen Jenkins WB4KTF <wb4ktf@...> ha
scritto:

I have a question about Time Sync.
When I look at the DT column, I see most folks with a DT close to ZERO
(0.1s, 0.2s, -0.1, and some 0.3 or -07). I am using the program NetTime
that I have set to reset my time every 15 minutes.
Yet I have had 2 close hams in my area tell me that I am 1.5s to 2.0s OFF
on their DT displays. Can I be off on receive yet OFF by that much on
transmit?
If so, what or where do I adjust this?

--
Glen, WB4KTF
Austin, TX






WB5JJJ - George
 

Glen, your Rx and Tx time offsets will be the same. There is no mechanism to adjust them independently.

If you are seeing <0.5s in your DT column, then all is as it should be, don't worry. Perhaps with your short sync time (15m), you are actually transmitting while the CPU is busy stealing cycles from WSJTx resetting your clock via a web source, thus causing several tenths of a second slowdown. I would suggest you extend your sync time to 60m or more and watch the DT column and if it approaches 1.0s (2.5s is the max error allowed on FT8 and 1.0s on FT4), then set your sync time a bit shorter to compensate. Just don't overdo the syncing. As for your friends seeing something different, I have no clue unless their clocks are the ones that are wrong. I've read where some guys were syncing every MINUTE. Remember the DT column is referencing YOUR clock to THEIRS, not to an Atomic Time Service somewhere. Again, <0.5s is totally acceptable.

I began using BktTimeSync years ago and added a $20 Amazon GPS "puck" receiver to it so very few CPU cycles are required to update my system clock versus a web-based time sync. I find that 60m works great even with my drifty little computer clock. I'm generally well under 0.5s off from the DT average between syncs.

--
73's
George - WB5JJJ
Hams over IP #100105


Michael Ernst
 

Glen (and George),

I have been using Net Time and FT8 since April 2018 and have made thousands of contacts. I have it set at 15 minutes and have had no issues with time sync at all. One thing that might be an issue is if you by chance have any delay anywhere. Some sound card devices (such as the SignaLink USB) have a delay setting. Or if by any chance you have some program running in the background. I have a backup program that runs late at night, but I have had situations where for some reason it ran late (power outage for example) and that caused a delay in my sending.

Good luck troubleshooting.

73,
Mike, AE8U

-----Original Message-----
From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of WB5JJJ - George
Sent: Saturday, March 25, 2023 10:10 AM
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] #windows11 #Timesync

Glen, your Rx and Tx time offsets will be the same. There is no mechanism to adjust them independently.

If you are seeing <0.5s in your DT column, then all is as it should be, don't worry. Perhaps with your short sync time (15m), you are actually transmitting while the CPU is busy stealing cycles from WSJTx resetting your clock via a web source, thus causing several tenths of a second slowdown. I would suggest you extend your sync time to 60m or more and watch the DT column and if it approaches 1.0s (2.5s is the max error allowed on FT8 and 1.0s on FT4), then set your sync time a bit shorter to compensate. Just don't overdo the syncing. As for your friends seeing something different, I have no clue unless their clocks are the ones that are wrong. I've read where some guys were syncing every MINUTE. Remember the DT column is referencing YOUR clock to THEIRS, not to an Atomic Time Service somewhere. Again, <0.5s is totally acceptable.

I began using BktTimeSync years ago and added a $20 Amazon GPS "puck" receiver to it so very few CPU cycles are required to update my system clock versus a web-based time sync. I find that 60m works great even with my drifty little computer clock. I'm generally well under 0.5s off from the DT average between syncs.

--
73's
George - WB5JJJ
Hams over IP #100105


Tim Brannon, WA5MD
 

I heartily agree with George about BktTimeSync and a GPS puck receiver. For $20 you can solve the #Timesync problem for good. And if you operate portable, this will work anywhere on earth. No Internet is needed at all.
Tim WA5MD


Jim AC9ZL
 

What do you see when you go to time.gov or time.is on your computer browser? If you see something like clock is off by -0.136 s, then your NetTime software is doing it's job.

Is it possible that the 2 close hams in your area are having an issue with Time Sync on their computer? If they go to time.gov or time.is on their computer browser, and see something like clock is off by -1.7 s, then the issue is at their end.

73,
Jim, AC9ZL


Glen Jenkins WB4KTF
 

Hello,
I have this fixed now with the enormous help from Mike, W9MDB.
Mike said that he would writeup the details later. I'll present a short version here.
Mike found that a Microsoft SERVICES called WAVES AUDIO SERVICES was the culprit. It apparently was turned on by a Windows update (?).
It caused the delay that made my DT on transmit run around 1.5 to 2 seconds late by the receiving stations, while my RX DT as seen in the DT column of WSJT-X was always fine. He DISABLED this service and that fixed my Transmit DT issue as detected on hamspots.net as reported by you all.
--
Glen, WB4KTF
Austin, TX


Mike Black
 

Glen's problem ended up being the WAVES Audio Service in the Services list -- we disabled it and his transmit timing was fixed.
Apparently WAVES Audio Service has an internal delay along with messing with audio levels.
It's apparently on most all Dell machines now and needs to be disabled permanently for WSJTX.

Mike W9MDB