Second build sold out. Message will appear here when store is ready for third build ordering.

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

  • edited March 2023

    I just noticed in the original post

         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 
    

    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

Sign In or Register to comment.