locked Measure my own DT time #Timesync


Don DeGregori
 

In WSJT-x, can I measure my own DT in mode FT8. I see other incoming DT's looking at the interface.
I do have Windows 10 date/time correction, and Dimension 4. Of course I use one or the other.
Rig is QRPLabs QDX. There is a method to measure your own transmit frequency, but not time error.

Thanks


William Smith
 

https://time.is

73, Willie N1JBJ

On Sep 5, 2022, at 4:00 PM, Don DeGregori <ddegreg1@...> wrote:

In WSJT-x, can I measure my own DT in mode FT8. I see other incoming DT's looking at the interface.
I do have Windows 10 date/time correction, and Dimension 4. Of course I use one or the other.
Rig is QRPLabs QDX. There is a method to measure your own transmit frequency, but not time error.

Thanks


Michael Black
 

You can sign up for https://hamspots.net and see how others report your  DT.
Mike W9MDB

On Monday, September 5, 2022 at 03:00:23 PM CDT, Don DeGregori <ddegreg1@...> wrote:

In WSJT-x, can I measure my own DT in mode FT8. I see other incoming DT's looking at the interface.
I do have Windows 10 date/time correction, and Dimension 4. Of course I use one or the other.
Rig is QRPLabs QDX. There is a method to measure your own transmit frequency, but not time error.

Thanks


Jim Brown
 

On 9/5/2022 1:00 PM, Don DeGregori wrote:
In WSJT-x, can I measure my own DT in mode FT8. I see other incoming DT's looking at the interface.
If you see a lot of decodes on a busy band and their DT values are +/- 0.1-0.2 sec, your clock is close enough.

73, Jim K9YC


Brian Stucker
 

Hi Jim,

Thank you for your contributions to ham radio over the years. I was just
looking at your materials on stubs last night.

I just wanted to add a few things to the answer to Don.

1. no, you can’t directly measure your own DT in WSJT, since you would be
using your local clock as a reference (so it is always 0).

2. You can use the time.is website to see how far off your clock is. This
is effectively your local DT.

3. You may never see all of the other stations within 0.1-0.2 +/- because
their clocks will be slightly off as well. A very common range for DT is
+/- 1 second with a well calibrated local clock. If you start to see lots
of DTs over a second, adjust your clock. If you get no decodes despite
hearing tones, adjust your clock.

If you’re going to be somewhere with no ability to get a good quality time
fix, put a program like RunAsDate on your machine. You can easily nudge the
clock that WSJT sees in software that way and dial things in by averaging
the observed DTs from other stations until you get them in a workable range.

73,
Brian - KB2S

On Tue, Sep 6, 2022 at 12:22 AM Jim Brown <k9yc@...>
wrote:

On 9/5/2022 1:00 PM, Don DeGregori wrote:
In WSJT-x, can I measure my own DT in mode FT8. I see other incoming
DT's looking at the interface.

If you see a lot of decodes on a busy band and their DT values are +/-
0.1-0.2 sec, your clock is close enough.

73, Jim K9YC






SteveO
 

I use a local GPS and from that i can see the difference between my system clock and the gps.   
I can automatically update the system clock on a timed basis or ad hoc.
When out in the field with no internet or cell service this technique is one of a couple that can keep your local time accurate enough for WSJT-x.
73 de KC5NK, Steve
On Tue, Sep 6, 2022 at 4:19 AM, Brian Stucker<me@...> wrote: Hi Jim,

Thank you for your contributions to ham radio over the years. I was just
looking at your materials on stubs last night.

I just wanted to add a few things to the answer to Don.

1. no, you can’t directly measure your own DT in WSJT, since you would be
using your local clock as a reference (so it is always 0).

2. You can use the time.is website to see how far off your clock is. This
is effectively your local DT.

3. You may never see all of the other stations within 0.1-0.2 +/- because
their clocks will be slightly off as well. A very common range for DT is
+/- 1 second with a well calibrated local clock. If you start to see lots
of DTs over a second, adjust your clock. If you get no decodes despite
hearing tones, adjust your clock.

If you’re going to be somewhere with no ability to get a good quality time
fix, put a program like RunAsDate on your machine. You can easily nudge the
clock that WSJT sees in software that way and dial things in by averaging
the observed DTs from other stations until you get them in a workable range.

73,
Brian - KB2S

On Tue, Sep 6, 2022 at 12:22 AM Jim Brown <k9yc@...>
wrote:

On 9/5/2022 1:00 PM, Don DeGregori wrote:
In WSJT-x, can I measure my own DT in mode FT8. I see other incoming
DT's looking at the interface.

If you see a lot of decodes on a busy band and their DT values are +/-
0.1-0.2 sec, your clock is close enough.

73, Jim K9YC






Dave Garber
 

I would think that, if every decode is near or zero for the dt, your clock
is good, if everyone is +1.0 or higher, than sync your time software
Dave Garber
VE3WEJ / VE3IE


On Tue, Sep 6, 2022 at 3:28 PM SteveO via groups.io <sollmann22=
yahoo.com@groups.io> wrote:

I use a local GPS and from that i can see the difference between my system
clock and the gps.
I can automatically update the system clock on a timed basis or ad hoc.
When out in the field with no internet or cell service this technique is
one of a couple that can keep your local time accurate enough for WSJT-x.
73 de KC5NK, Steve
On Tue, Sep 6, 2022 at 4:19 AM, Brian Stucker<me@...> wrote: Hi
Jim,

Thank you for your contributions to ham radio over the years. I was just
looking at your materials on stubs last night.

I just wanted to add a few things to the answer to Don.

1. no, you can’t directly measure your own DT in WSJT, since you would be
using your local clock as a reference (so it is always 0).

2. You can use the time.is website to see how far off your clock is. This
is effectively your local DT.

3. You may never see all of the other stations within 0.1-0.2 +/- because
their clocks will be slightly off as well. A very common range for DT is
+/- 1 second with a well calibrated local clock. If you start to see lots
of DTs over a second, adjust your clock. If you get no decodes despite
hearing tones, adjust your clock.

If you’re going to be somewhere with no ability to get a good quality time
fix, put a program like RunAsDate on your machine. You can easily nudge the
clock that WSJT sees in software that way and dial things in by averaging
the observed DTs from other stations until you get them in a workable
range.

73,
Brian - KB2S

On Tue, Sep 6, 2022 at 12:22 AM Jim Brown <k9yc@...>
wrote:

On 9/5/2022 1:00 PM, Don DeGregori wrote:
In WSJT-x, can I measure my own DT in mode FT8. I see other incoming
DT's looking at the interface.

If you see a lot of decodes on a busy band and their DT values are +/-
0.1-0.2 sec, your clock is close enough.

73, Jim K9YC
















 

Sort of related... I found a minor problem using Dimension 4. Out of the box, it has a list of time servers all over the world. The response times from the ones in Australia (I'm on the US east coast) for example would exceed D4's response time limit and therefore be ignored, however ones on the US west coast (for example) would meet the D4 criteria, and my clock would end up being off by 0.2 or 0.3 seconds according to Time.is.

You can tell D4 to only use a single server, but that isn't a great idea because if that server is down, you're on your own.

I fixed the problem by eliminating all the servers that were more than about 500 miles from my QTH. I did this about 6 weeks ago and the time has been exact ever since.

--
John P.
WA2FZW


Reino Talarmo
 

Sort of related... I found a minor problem using Dimension 4. Out of the box, it has a list of time servers all over the world. The response times from the ones in Australia (I'm on the US east coast) for example would exceed D4's response time limit and therefore be ignored, however ones on the US west coast (for example) would meet the D4 criteria, and my clock would end up being off by 0.2 or 0.3 seconds according to Time.is.
Well, it may be time to remind that the use of D4 is no more recommended. It corrects time in jumps and that may disturb decoding. Currently Meinberg is recommended and https://www.satsignal.eu/ntp/setup.html provides a good setting information, see User Guide 3.1. Windows fourth bullet. It is a good practice to have at least time servers or pools selected and you should never be on you own as long as your net connection is working.

73, Reino OH3mA


Gilbert Baron
 

The furthest server assuming short path would be off by only about .067 seconds or .134 on a long path. Why is anyone so worried about that when requirements for decodes are not even close to that strict? Hard to understand?

Outlook LT Gil W0MN
Hierro Candente Batir de Repente
44.08226 N 92.51265 W EN34rb

-----Original Message-----
From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of John P
Sent: Tuesday, September 6, 2022 9:53 PM
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Measure my own DT time #Timesync

Sort of related... I found a minor problem using Dimension 4. Out of the box, it has a list of time servers all over the world. The response times from the ones in Australia (I'm on the US east coast) for example would exceed D4's response time limit and therefore be ignored, however ones on the US west coast (for example) would meet the D4 criteria, and my clock would end up being off by 0.2 or 0.3 seconds according to Time.is.

You can tell D4 to only use a single server, but that isn't a great idea because if that server is down, you're on your own.

I fixed the problem by eliminating all the servers that were more than about 500 miles from my QTH. I did this about 6 weeks ago and the time has been exact ever since.

--
John P.
WA2FZW








--
W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop


K9RX - Gary
 

I run both WSJT and JTDX simultaneously ... JT is my primary (control/TX). I tried the recommended programs: Dimension4 and Mein-whatever ... both seemed clunky to me. Dimenson4 constantly needed to be forced to do a sync as the time would go awry. A friend recommended this one: https://www.qsl.net/dl4yhf/rsNTP/rsNTP.htm and so I installed it - WOW. ridiculously simple is a proper descriptor - and it works fantastic. It maintains constant offset without messing with it. And I can, if needed and on a one-off basis, tailor the time offset to stations that are way off - allowing me to work them (they decode me). Also an offset is allowed - which I use to tailor for best TX/RX Dt value. See below.

While using this I've noticed that there is an inverted relationship between RX Dt and TX Dt. If I set up the synch offset such that Dt's are 0 average (JT nicely provides an average Dt value) my TX Dt gets out to 0.6! If I set the RX to be 0.6 then TX is 0! So I've ended up with the average RX Dt around 0.4 which makes my average TX Dt around 0.3 - 0.4.

Further, I've noticed that people spend FAR too much time obsessing over Dt. As this thread would indicate. As long as you are in the <0.8 seconds or so - maybe even as noted a second - there appears to be no impact on decodes. HOWEVER keep in mind that relationship that I noted above --- the more your receive Dt is - the higher it is - the lower the TX one is, possibly getting to be negative.

I WISH that the manual would give more information on the relationship of Dt to A) decodes and B) RX vs TX and most importantly C) if I set my computer time to be dead-nuts on to NIST ... what should I expect for Dt on RX? TX? I suspect it is NOT 0! But there's no mention of this at all in the manual. So we're fighting blind here to an extent. (and keep in mind there is a setting for TX offset as well - an internal one that delays the transmit. I suspect it does not impact the TX DT since the data has to be sync'd to the window time frame... but it's there as well).

Odd that something that gets so much attention hasn't been explained in fine enough detail to allow people to set up (more) properly ... and worry about it less. I've had stations decode with Dt's in the mid 2 second range! Now - because I've seen them does that mean if I am properly set up - i.e. my transmit is say 0.4, that I have less likelihood of working them? WHERE/HOW is the tradeoff made? With rsNTP its a moot point since I can now just copy their sequence - paste it in the program and voila now I match their Dt.

Gary
K9RX


William Smith
 

Ah, but when is it too much time obsessing and when is it another hobby? I built a Raspberry Pi NTP server with a GPS HAT, added all kinds of monitoring and display functions, built another one for my other QTH, added comparison graphs between the two, and find it's a lot of fun.

Yes, FTn and JS8 can decode about 2.5 seconds out (combined between QSO partners, so you both probably want to be within around a second of 'real' time), but I enjoy having my local NTP server be under <lessee> 25 ms from realtime, so time.is shows me under 50ms on my client computers.

73, Willie N1JBJ

On Sep 7, 2022, at 9:22 AM, K9RX - Gary <amateurK9RX@...> wrote:
I've noticed that people spend FAR too much time obsessing over [time]


Jerry (KB2GCG)
 

I have Meinberg running and after the computer wakes from sleep the time is off. How long does it take Meinberg to catch up ? is there a way to force a sync ?

Jerry
KB2GCG


- "Defeat lasts one day, giving up lasts a lifetime."

On Sep 7, 2022, at 9:23 AM, K9RX - Gary <amateurK9RX@...> wrote:

I run both WSJT and JTDX simultaneously ... JT is my primary (control/TX). I tried the recommended programs: Dimension4 and Mein-whatever ... both seemed clunky to me. Dimenson4 constantly needed to be forced to do a sync as the time would go awry. A friend recommended this one: https://www.qsl.net/dl4yhf/rsNTP/rsNTP.htm and so I installed it - WOW. ridiculously simple is a proper descriptor - and it works fantastic. It maintains constant offset without messing with it. And I can, if needed and on a one-off basis, tailor the time offset to stations that are way off - allowing me to work them (they decode me). Also an offset is allowed - which I use to tailor for best TX/RX Dt value. See below.

While using this I've noticed that there is an inverted relationship between RX Dt and TX Dt. If I set up the synch offset such that Dt's are 0 average (JT nicely provides an average Dt value) my TX Dt gets out to 0.6! If I set the RX to be 0.6 then TX is 0! So I've ended up with the average RX Dt around 0.4 which makes my average TX Dt around 0.3 - 0.4.

Further, I've noticed that people spend FAR too much time obsessing over Dt. As this thread would indicate. As long as you are in the <0.8 seconds or so - maybe even as noted a second - there appears to be no impact on decodes. HOWEVER keep in mind that relationship that I noted above --- the more your receive Dt is - the higher it is - the lower the TX one is, possibly getting to be negative.

I WISH that the manual would give more information on the relationship of Dt to A) decodes and B) RX vs TX and most importantly C) if I set my computer time to be dead-nuts on to NIST ... what should I expect for Dt on RX? TX? I suspect it is NOT 0! But there's no mention of this at all in the manual. So we're fighting blind here to an extent. (and keep in mind there is a setting for TX offset as well - an internal one that delays the transmit. I suspect it does not impact the TX DT since the data has to be sync'd to the window time frame... but it's there as well).

Odd that something that gets so much attention hasn't been explained in fine enough detail to allow people to set up (more) properly ... and worry about it less. I've had stations decode with Dt's in the mid 2 second range! Now - because I've seen them does that mean if I am properly set up - i.e. my transmit is say 0.4, that I have less likelihood of working them? WHERE/HOW is the tradeoff made? With rsNTP its a moot point since I can now just copy their sequence - paste it in the program and voila now I match their Dt.

Gary
K9RX





Bob McGraw - K4TAX <rmcgraw@...>
 

In other words, are you saying "if it ain't broke, don't try to fix
it?".   Seems so.

My dT is always 0.2 seconds or less.

73

Bob, K4TAX


On 9/7/2022 6:09 AM, Gilbert Baron wrote:
The furthest server assuming short path would be off by only about .067 seconds or .134 on a long path. Why is anyone so worried about that when requirements for decodes are not even close to that strict? Hard to understand?

Outlook LT Gil W0MN
Hierro Candente Batir de Repente
44.08226 N 92.51265 W EN34rb


-----Original Message-----
From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of John P
Sent: Tuesday, September 6, 2022 9:53 PM
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Measure my own DT time #Timesync

Sort of related... I found a minor problem using Dimension 4. Out of the box, it has a list of time servers all over the world. The response times from the ones in Australia (I'm on the US east coast) for example would exceed D4's response time limit and therefore be ignored, however ones on the US west coast (for example) would meet the D4 criteria, and my clock would end up being off by 0.2 or 0.3 seconds according to Time.is.

You can tell D4 to only use a single server, but that isn't a great idea because if that server is down, you're on your own.

I fixed the problem by eliminating all the servers that were more than about 500 miles from my QTH. I did this about 6 weeks ago and the time has been exact ever since.
--
In life it is important to know when to stop arguing with people and simply let them be wrong.


Bob McGraw - K4TAX <rmcgraw@...>
 

I gave up on Meinberg due to some complexity, although I found it did a
good job.  I switched to  Dimension 4 V5.31, then deleted all the sites
which were outside the US.   I find that WSJT-X in FT-8 mode shows a dT
of always less than 0.2 seconds for most stations.   It always corrects
the computer clock deviations of 0.02 seconds or less.

73

Bob, K4TAX

On 9/7/2022 11:33 AM, Jerry (KB2GCG) wrote:
I have Meinberg running and after the computer wakes from sleep the time is off. How long does it take Meinberg to catch up ? is there a way to force a sync ?

Jerry
KB2GCG


- "Defeat lasts one day, giving up lasts a lifetime."
d simply let them be wrong.


Gilbert Baron
 

Yup.

Outlook LT Gil W0MN
Hierro Candente Batir de Repente
44.08226 N 92.51265 W EN34rb

-----Original Message-----
From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Bob McGraw - K4TAX
Sent: Wednesday, September 7, 2022 8:54 AM
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Measure my own DT time #Timesync

In other words, are you saying "if it ain't broke, don't try to fix it?". Seems so.

My dT is always 0.2 seconds or less.

73

Bob, K4TAX


On 9/7/2022 6:09 AM, Gilbert Baron wrote:
The furthest server assuming short path would be off by only about .067 seconds or .134 on a long path. Why is anyone so worried about that when requirements for decodes are not even close to that strict? Hard to understand?

Outlook LT Gil W0MN
Hierro Candente Batir de Repente
44.08226 N 92.51265 W EN34rb


-----Original Message-----
From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of John P
Sent: Tuesday, September 6, 2022 9:53 PM
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Measure my own DT time #Timesync

Sort of related... I found a minor problem using Dimension 4. Out of the box, it has a list of time servers all over the world. The response times from the ones in Australia (I'm on the US east coast) for example would exceed D4's response time limit and therefore be ignored, however ones on the US west coast (for example) would meet the D4 criteria, and my clock would end up being off by 0.2 or 0.3 seconds according to Time.is.

You can tell D4 to only use a single server, but that isn't a great idea because if that server is down, you're on your own.

I fixed the problem by eliminating all the servers that were more than about 500 miles from my QTH. I did this about 6 weeks ago and the time has been exact ever since.
--
In life it is important to know when to stop arguing with people and simply let them be wrong.









--
W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop


Jim Brown
 

On 9/7/2022 6:22 AM, K9RX - Gary wrote:
I've noticed that people spend FAR too much time obsessing over Dt. As this thread would indicate.
YES! As I posted earlier, if your received DT values are mostly +/- 0.2 or less on a busy band, with a few outliers, you're time synce is just fine.

I've been using this VERY simple tool for nearly 15 years. http://www.timesynctool.com/

73, Jim K9YC


Frank Donovan
 

Hi Gary,

Why do you (and others?) find it beneficial to also run JTDX?  I’ve heard some complaints about poor JTDX decoding accuracy with very low SNR FT8 signals
 
73 Frank W3LPL

-----Original Message-----

From: K9RX <amateurK9RX@...>
To: main <main@WSJTX.groups.io>
Date: Wednesday, 7 September 2022 6:23 AM PDT
Subject: Re: [WSJTX] Measure my own DT time #Timesync

I run both WSJT and JTDX simultaneously ... JT is my primary (control/TX). I tried the recommended programs: Dimension4 and Mein-whatever ... both seemed clunky to me. Dimenson4 constantly needed to be forced to do a sync as the time would go awry. A friend recommended this one: https://www.qsl.net/dl4yhf/rsNTP/rsNTP.htm and so I installed it - WOW. ridiculously simple is a proper descriptor - and it works fantastic. It maintains constant offset without messing with it. And I can, if needed and on a one-off basis, tailor the time offset to stations that are way off - allowing me to work them (they decode me). Also an offset is allowed - which I use to tailor for best TX/RX Dt value. See below.

While using this I've noticed that there is an inverted relationship between RX Dt and TX Dt. If I set up the synch offset such that Dt's are 0 average (JT nicely provides an average Dt value) my TX Dt gets out to 0.6! If I set the RX to be 0.6 then TX is 0! So I've ended up with the average RX Dt around 0.4 which makes my average TX Dt around 0.3 - 0.4.

Further, I've noticed that people spend FAR too much time obsessing over Dt. As this thread would indicate. As long as you are in the <0.8 seconds or so - maybe even as noted a second - there appears to be no impact on decodes. HOWEVER keep in mind that relationship that I noted above --- the more your receive Dt is - the higher it is - the lower the TX one is, possibly getting to be negative.

I WISH that the manual would give more information on the relationship of Dt to A) decodes and B) RX vs TX and most importantly C) if I set my computer time to be dead-nuts on to NIST ... what should I expect for Dt on RX? TX? I suspect it is NOT 0! But there's no mention of this at all in the manual. So we're fighting blind here to an extent. (and keep in mind there is a setting for TX offset as well - an internal one that delays the transmit. I suspect it does not impact the TX DT since the data has to be sync'd to the window time frame... but it's there as well).

Odd that something that gets so much attention hasn't been explained in fine enough detail to allow people to set up (more) properly ... and worry about it less. I've had stations decode with Dt's in the mid 2 second range! Now - because I've seen them does that mean if I am properly set up - i.e. my transmit is say 0.4, that I have less likelihood of working them? WHERE/HOW is the tradeoff made? With rsNTP its a moot point since I can now just copy their sequence - paste it in the program and voila now I match their Dt.

Gary
K9RX


Tim Dawson
 

This is an argument for using the baseline NTP code (Meinberg on Win, source on more advanced platforms) in that it considers and corrects for network delay . . .

On September 7, 2022 6:09:27 AM CDT, Gilbert Baron <w0mn00@...> wrote:
The furthest server assuming short path would be off by only about .067 seconds or .134 on a long path. Why is anyone so worried about that when requirements for decodes are not even close to that strict? Hard to understand?

Outlook LT Gil W0MN
Hierro Candente Batir de Repente
44.08226 N 92.51265 W EN34rb


-----Original Message-----
From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of John P
Sent: Tuesday, September 6, 2022 9:53 PM
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Measure my own DT time #Timesync

Sort of related... I found a minor problem using Dimension 4. Out of the box, it has a list of time servers all over the world. The response times from the ones in Australia (I'm on the US east coast) for example would exceed D4's response time limit and therefore be ignored, however ones on the US west coast (for example) would meet the D4 criteria, and my clock would end up being off by 0.2 or 0.3 seconds according to Time.is.

You can tell D4 to only use a single server, but that isn't a great idea because if that server is down, you're on your own.

I fixed the problem by eliminating all the servers that were more than about 500 miles from my QTH. I did this about 6 weeks ago and the time has been exact ever since.

--
John P.
WA2FZW








--
W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop




--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


Gilbert Baron
 

All of the time sync arguments are just that. ANY of the apps and even Windows itself properly set are FAR more accurate than needed. Better to spend time with other parts of your setup.

Outlook LT Gil W0MN
Hierro Candente Batir de Repente
44.08226 N 92.51265 W EN34rb

-----Original Message-----
From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Tim Dawson
Sent: Wednesday, September 7, 2022 4:02 PM
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Measure my own DT time #Timesync

This is an argument for using the baseline NTP code (Meinberg on Win, source on more advanced platforms) in that it considers and corrects for network delay . . .

On September 7, 2022 6:09:27 AM CDT, Gilbert Baron <w0mn00@...> wrote:
The furthest server assuming short path would be off by only about .067 seconds or .134 on a long path. Why is anyone so worried about that when requirements for decodes are not even close to that strict? Hard to understand?

Outlook LT Gil W0MN
Hierro Candente Batir de Repente
44.08226 N 92.51265 W EN34rb


-----Original Message-----
From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of John P
Sent: Tuesday, September 6, 2022 9:53 PM
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Measure my own DT time #Timesync

Sort of related... I found a minor problem using Dimension 4. Out of the box, it has a list of time servers all over the world. The response times from the ones in Australia (I'm on the US east coast) for example would exceed D4's response time limit and therefore be ignored, however ones on the US west coast (for example) would meet the D4 criteria, and my clock would end up being off by 0.2 or 0.3 seconds according to Time.is.

You can tell D4 to only use a single server, but that isn't a great idea because if that server is down, you're on your own.

I fixed the problem by eliminating all the servers that were more than about 500 miles from my QTH. I did this about 6 weeks ago and the time has been exact ever since.

--
John P.
WA2FZW








--
W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop




--
Sent from my Android device with K-9 Mail. Please excuse my brevity.








--
W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop