On 03/05/2019 22:20, Bill Frantz wrote:
On 5/3/19 at 1:58 PM, [email protected] (Bill Somerville) wrote:
your conclusions are all correct. We are currently fine tuning the
FT4 transmission start time so that the decoder gets a reasonably
even chance of decoding signals across the allowable DT tolerance of
± 0.5 S without losing sensitivity. We can't quite make it perfect
across that range whilst still allowing the user reasonable thinking
time before the next transmission period. FT4 has a shorter
transmission time, shorter dead time between periods, and shorter
periods than FT8 so it should not be surprising that clock accuracy
requirements are stricter as well. This really only matters for MS
Windows users who have not bothered to install a third-party NTP
service, have no suitable Internet connection, or GPS signal. For
those that rely on manual time setting or think Windows can do the
job well enough, now is the time to think again.
This issue may be important on other operating systems as well as
Windows.
When I'm in New Hampshire, I run FT8 using my cell phone for internet
connectivity and NTP access. I find that if I have left the house for
several hours and return, unless I reconnect to the cell
phone/Internet, my Macintosh's clock is off by enough to impact
decoding. I have trained myself to look at the delta time column when
I am getting decodes to make sure that my clock is at least reasonably
(< 0.5 seconds) synched with the others on the band. When I get no
decodes, but have signals on the waterfall, the clock is the first
place I look to solve the problem.
73 Bill AE6JV
Hi Bill,
that's why I stated "suitable Internet connection", ones that turn off
spontaneously or use asymmetric upload and download paths like some
satellite links are not necessarily suitable.
73
Bill
G4WJS.
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
