On 03/05/2019 21:24, Reino Talarmo wrote:
Hi,
Thanks for an excellent piece of communication protocol both FT8 and
FT4. It would be interesting to see how big guns start to use FT4
instead of RTTY. For strong signals RTTY is a bit faster than FT8, but
most of the users are not big guns! The bandwidth saving in FT4 is a
really big issue, so there will be many more QSOs/min/kHz.
I checked how much timing difference is allowed for a successful
decode. It seems that in 23000 successful decodes timing difference is
in range -0.5 s to 0.6 s. In FT8 the range is -2.6 s to 2.5 s and 99%
of successful decodes are within +/-2 s compared to my timing. I have
no idea how much signal strength affects to the result, but for sure
in FT4 any practical signal strength increase does not help to extend
the range outside the +/- 0.5 s. There are many signals that fall out
of that range. So we could recommend clock accuracy +/- 0.25 s or
better for FT4.
73, Reino oh3ma
Hi Reino,
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.
73
Bill
G4WJS.
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
