dT out of sync (FT8)
Hi all
Been using KiwiSDR for sometime now, The SDR I use is GPSlocked however we are seeing sync +/- 1 or more seconds out of sync
How/What is causing this and can it be resolved in some way?
Kindest Regards.
VK1TTY
Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Categories
- 2.5K All Categories
- 1.2K KiwiSDR Discussion
- 134 Software release information
- 27 Feature requests
- 312 Configuration and Operation
- 82 Installation, Antennas and Interference
- 63 WSPR, wsprdaemon, kiwirecorder
- 7 BeagleBone AI-64
- 8 BeagleBone AI
- 11 TDoA topics
- 64 Signals Received
- 95 Problems and Issues
- 219 Problems Now Fixed
- 90 General Chat
Comments
For a Kiwi that you own/administer you can go to the admin page, extensions tab, FT8 section and "tune" the value of the
dT correctionfield. Same for theSNR correction.This was done because we didn't write the ft8_lib code and have no idea how the dT values are computed. So the best we can do is add a calibration factor. Or we could remove display of the value entirely I suppose.
Hi John,
I'd suggest not removing the dt value, as it would be difficult to adjust the KiWi dt offset without being able to observe it, and out io of spec timings simply wouldn't decode.
Regards,
Martin
Personally I'm not for removing it (unless it keeps too many people from complaining). But the dT calibration only effects what is displayed by the extension. It doesn't effect anything about how ft8_lib decides the timing of decoding (which I don't understand either).
Ah, I thought it did affect the decode timing too ?
I'm pretty sure when I deliberately offset my transmitter timing to test the dT range, and I then varied the KiWi dT calibration, it changed the time window for valid decodes too.
But maybe I just imagined it, as it was the behaviour I expected to see.
Regards,
Martin
I just looked at the code again, and the dT calibration change should only be effecting the value displayed. Same with the SNR.
OK, good to know.
Clocks need to be sync'd with JT-modes - both on RX as well as the TX-side - otherwise decoding can be degraded. SDRs - with their inherent latency - require something to be done to address this. The DTs VK1TTY reported are roughly grouped around the offset I need to apply to chrony on my Ubuntu machines chewing on KiwiSDR RXs. Any additional offset due to transmitter clock offset can result in a portion of the transmission extending into the next interval.
Applying an offset to S-on-N to match WSJT-X can be problematic, see:
WSJT-X: https://sourceforge.net/p/wsjt/mailman/message/36012128/
JTDX: https://jtdx.freeforums.net/thread/269/comparing-snr-reports-jtdx-wsjt
73, VR2BG.
We're not talking about the same things here.
The ft8_lib code has time syncing to the local Debian clock. And that works fine. And it in turn is synced by ntpd or gps if the later has been setup.
What were talking about is how the code computes the beginning of each signal so that the delta (dT) from the 15 or 6 second "slot" time can be displayed. The original dT values output by the code were obviously wrong. So I added the correction factor in the admin interface.
But that's it. These are displayed vanity values. They don't have any meaning beyond that.
I believe we are talking about the same thing here. This stuff requires accurate time synchronisation of both the RX & TX sides (see last para https://wsjt.sourceforge.io/wsjtx-doc/wsjtx-main-2.6.1.html#PROTOCOL_OVERVIEW ). But unlike conventional radios, SDRs have significant latency - it's necessary to compensate for that by offsetting time-as-the-decoder-thinks-it-to-be so as to replicate things as they would be with the assumed conventional radio being used... that's why each of my SDRs is on a different computer with a different offset from real time.
What VK1TTY reported is already at the limit for what is a specified requirement for WSJT-X (see last bullet point https://wsjt.sourceforge.io/wsjtx-doc/wsjtx-main-2.6.1.html#SYSREQ - something that IMHO should be defined for what is now effectively a standard rather than a protocol - or something that implements that standard/protocol - but I couldn't find anything in the time I could spare). I rather doubt, from YL3JG's description, that ft8_lib is even more tolerant of timing given its optimisation for running on lightweight hardware. In practice, DTs that large are an indication of no synchronisation. Add a healthy dose of TX-side lack-of-sync to that & you're into kiwiclientd-gone-walkabout territory where decoding completely stops.
One of the biggest problems with the JT-modes is time sync - the resumption of DXpeditions now that the the latest CCP plague is (hopefully) over has made that glaringly obvious. With GPS and/or NTP, IMHO DTs from a KiwiSDR should be spot on (+/- a few RCHs) rather than tarted up to look good.
73, VR2BG.
The actual KiWi DT was discussed in a previous thread, and in my tests seemed to be correct, but maybe someone else could try something similar to confirm my results.
Regards,
Martin
Although it would require assuming that the decoder is correct, I would imagine the easiest way to judge DTs would be to compare against the same signal as received on a conventional receiver, as decoded by WSJT-X/JTDX.
Looking at the output of that receiver with a 'scope could firm up confidence in the "reference" decoders' reported DTs.
I would expect that the Kiwi's decoders on the same signals would then be reporting DTs offset equal to the Kiwi's latency as compared to the conventional receiver/"reference" decoders' DTs.
Since the Kiwi's latency would also apply to the Kiwi's WSPR decoder, surely this has been dealt with previously. These time-synchronised modes have to take into account that latency, otherwise the decoder isn't chewing on audio that's in sync like it's meant to be.
73, VR2BG.
As the wspr and ft decoder both run on the BB, I would thinki that the over the network latency would not apply.
WA2ZKD: The latency is the Kiwi's latency, not what the network might add on to it, nor that of the computer running the decoder (though they all do contribute - but not in the case where decoding is done by the Kiwi).
I just pinged my Kiwi from the Ubuntu 20.04 i5-4690 @ 3.50GHz 8 GB RAM w/o GPU machine running 11 JTDX instances (4 full 3 kc FT8 instances throttled with candidate list thinning of 80% & 3 decode passes, the rest 2 kc JT9+65 [no hint]/FT4 [deep decoding]) & see 0.4 min/0.55 avg/1.37 msec max.
chrony on that machine is offset from real time by 1 sec.
I then QSYed another rig (admittedly a SDR, but one where the host computer's (laptop running W7P SP1, i7-2620M CPU @ 2.7 GHz 8 GB RAM, also w/o GPU) clock is not offset from real time & my impression from the DTs largely grouping around 0.0-0.1 is that the rig doesn't have appreciable latency (the manufacturer doesn't spec latency & queries about this to the user community have gone unanswered) to the same frequency as one of the JTDX instances on the Ubuntu machine mentioned above & from a quick eyeballing of two decodes that could be matched as everything went scrolling by were 0.0/0.1 & -0.0/-0.0 (Ubuntu machine/W7P machine). The W7P machine was running only one JTDX FT8 instance, with no candidate list thinning & 3 decode passes - plus Firefox 113.01.1 with KiwiSDR admin & two other tabs that weren't doing anything at the time.
The Kiwi's latency seems to be ~1 sec.
Most of the decodes VK1TTY had were 1 sec, or just shy of that.
I believe the Kiwi's WSPR/FT* decoders need to think that time is offset by somewhere around that amount, just like I have to offset time on each of my machines to match the latency of the SDRs/SDR software presenting audio to them.
Hopefully all that makes sense - I just got back from a day at the beach to avoid a household COVID nightmare due to someone who refused to get vaccinated/isolate/wear-a-mask/take-well-intentioned-advice that's starting to kick off again... [most colourful HK-flavour Cantonese expletives deleted!].
73, VR2BG.