dT on WSPR vs FT8
When looking at dT values in WSPR and FT8 I see low values i WSPR (low fraction of second) but in FT8 values of 2+ are not uncommon.
Are they not the same type of data?
FT8:
UTC SNR dT Freq km age freq: 7074.00 mode: FT8 17:07:30 -08.5 -1.40 912 940 CQ G3WAG IO82 17:07:30 -10.0 -2.60 1856 4471 10 DL4UY DF7FC (RR73) 17:07:30 FT8 decoded 2, new spots 1, hashtable 26% UTC SNR dT Freq km age freq: 7074.00 mode: FT8 17:07:45 -08.0 -2.52 1162 R2DPZ IQ1ZS -16 17:07:45 -10.0 -2.60 722 2486 27 CQ RN4A LN28 17:07:45 FT8 decoded 2, hashtable 26% UTC SNR dT Freq km age freq: 7074.00 mode: FT8 17:08:30 -04.5 -1.00 1184 R108M RR73 17:08:30 -04.5 -1.00 2162 2518 13 2E0FNM UG4P LO55 17:08:30 -04.5 -1.00 931 ON3RF F5RD 73 17:08:30 -05.0 -0.20 1856 628 11 DL1CC DF7FC JO40 17:08:30 -05.0 -0.76 2044 UB4HOO RO7L R+00 17
WSPR:
UTC dB dT Freq dF Call Grid km dBm 1706 -7 0.1 7.040056 0 G0KRB JO02 715 37 (5.0 W) 1706 -9 0.3 7.040156 0 SM6YPEJO67 234 23 (200 mW) 1706 -9 0.5 7.040014 0 SG7SUN/B 27 (501 mW) 1706 -12 0.1 7.040103 0 EW1LN KO33 1117 30 (1.0 W) 1706 -16 0.3 7.040142 0 DL2JA JN58 848 33 (2.0 W) 1706 -16 -0.1 7.040183 0 DL4DACJO31LL 555 23 (200 mW) 1706 -21 0.5 7.040148 0 DL8DXJN47EP 949 23 (200 mW) 1706 -21 0.1 7.040022 0 DG1GHRJN48 849 37 (5.0 W) 1706 -21 0.3 7.040114 0 DK1MI JN49 739 23 (200 mW) 1706 -24 0.3 7.040040 0 DH5IS JN49 739 23 (200 mW) 1706 -25 0.5 7.040090 0 GM1BANIO88 831 23 (200 mW) 1708 21 0.0 7.040101 0 QQ0RF JO65 192 13 (20 mW) 1708 -1 0.4 7.040040 0 DK2DB JN48 849 37 (5.0 W)
Status page:
Config: v1.588, 8 SDR channels, 12 GPS channels | Uptime: 4 days 23:31:04 | UTC: 17:13 | Local: 18:13 Europe/Copenhagen (CET)
GPS: acquire yes, track 11, good 11, fixes 181.9k, ADC clock 66.665837 (181.7k avgs)
SNR: All 14 dB, HF 15 dB
Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/111.0
Beagle: cpu 48% usr | 19% sys | 26% idle,
1.0 GHz,
FPGA eCPU: 36%
Network (all channels): audio 33 kB/s, waterfall 11 kB/s (20 fps), http 0 kB/s, total 43 kB/s (344 kb/s)
Stats: 0 dropped, 3 underruns, 0 sequence, 25 realtime
Realtime response histograms:
Datapump: 80, 5.4M, 42.0k, 35.9k, 25.1k, 2, 0, 0
SoundInQ: 0, 31.0M, 1.4M, 206.8k, 176.1k, 157.8k, 72.9k, 3.6k, 33, 15, 10, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
RX0
"OZ4JJ" (fe80::1434:d41a:1bda:7062, unknown location) 3573.00 kHz usb z11 FT8 19:13:13
RX1
"OZ4JJ" (fe80::1434:d41a:1bda:7062, unknown location) 5357.00 kHz usb z11 FT8 19:11:45
RX2
"OZ4JJ" (fe80::1434:d41a:1bda:7062, unknown location) 7074.00 kHz usb z0 FT8 19:10:44
RX3
"OZ4JJ" (fe80::1434:d41a:1bda:7062, unknown location) 10136.00 kHz usb z0 FT8 19:09:41
RX4
"OZ4JJ" (fe80::1434:d41a:1bda:7062, unknown location) 14074.00 kHz usb z0 FT8 19:05:51
RX5
"OZ4JJ" (fe80::1434:d41a:1bda:7062, unknown location) 7040.10 kHz usb z0 wspr 19:03:36
RX6
RX7
Side note:
Copy/paste formating above looks a lot nicer for FT8!
/hjj
Comments
I don't know how the
lib_ft8
code computes the value for "dT". We either need a calibration adjustment like was done for the SNR value or it needs to be removed entirely.V1.588
I just tried sending some FT8 to myself and varied the reference time offset of the transmitter using Bkt TimeSync
https://www.maniaradio.it/en/bkttimesync.html
I know that there is a some delay present in the transmitter chain due to DSP and other processing.
With zero time offset I see a dt of -0.68 which seems to be around the value I'd expect, or at least it's in the right ball park.
I then tried offsetting the TX by up to +/- 3 seconds in 0.5 second intervals. This was in order to see if the reported dt was correct by finding the limits of time advance / delay at which decodes were no longer possible.
I found that decodes were just possible within a +/- 2 second window, either side of my fixed transmitter dt of 0.68 second.
So it all looks OK to me.
I suspect the actual dt's you are seeing are also correct, and it maybe that the fewer WSPR operators generally take more care of their timing standards than the much more abundant FT8 operators.
What you don't see in the results table, are all of the FT8 signals that are either overmodulated, off frequency, drifting or mistimed, that simply don't get decoded, but they are very obvious when you look at the waterfall.
Regards,
Martin
I just noticed in the original post
My experience is that FT8 will not normally decode with dt's of greater than approx +/- 2 seconds.
I'm not sure how you are actually achieving these decodes ?
Maybe this could be a clue ?
Regards,
Martin