How WSJT-X Synchronizes FT8 Transmissions

FT8 being used on the 40m band. (2023, October 19). In Wikipedia. https://en.wikipedia.org/wiki/FT8

Introduction to Article-Series

Throughout the next several articles, I'm going to do a deep dive article series to better understand the FT8 protocol.  Just a warning -- there's going to be some math.

Getting Started with FT8 in Amateur Radio: A Beginners Guide

Exploring FT4 and FT8: Revolutionizing Amateur Radio Communication

How WSJT-X Synchronizes FT8 Transmissions

Demystifying Forward Error Correction: Enhancing Data Reliability in Digital Radio Communication

Understanding Maidenhead Grid Squares in Amateur Radio

Anyone who has ever used WSJT-X for FT-8 transmissions will tell you that it's critical to synchronize your computer's clock so you'll be able to receive and transmit data.  But how precisely does your clock need to agree with everyone else's clock?  Let's find out together!

So if you've ever wondered how FT8 time synchronization works, I've got great news for you.  I wanted to know too!  So I tore the software apart and peeked inside.  I found the answer to our shared question in one of the few comments the authors made in this little bit of code:  

The first 26 lines of wsjtx-2.7.0-rc2\wsjtx-2.7.0\src\wsjtx\wsjtx\lib\ft8\sync8.f90 file.

Now, I don't use Fortran.  But the "Costas 7x7 tone pattern" comment, along with the 3,1,4,0,6,5,2 is all the clue I need to make a wild, but still somewhat educated guess.

FT8 transmits data as octets, coded in audible signal tones spaced ~6 Hz apart.  If you take a look at a waterfall graph of an audio spectrum during FT8 transmission, you'll see those tones visibly illustrated as bright orange/white colors when they are present and clear, and as black background when they're not present.  They'll appear reddish and purplish when the audio signal is mixed with background noise. 

The "3,1,4,0,6,5,2" is a "magic sequence" of tones that the WSJT-X  authors use to synchronize the transmitted signal at the receiver end.  And it's a pretty good bet that the authors of JTSync use that same information to synchronize your computer clock when no network time source is present.  (As an aside, the JTSync software may or may not use grid-square information and propagation time knowledge to further refine the time synchronization, I'm not sure as I haven't studied the software.  But as you'll see later in this article, it isn't really necessary.)

Costas Array

It helps if you know what a Costas array is.  In basic terms, it is a sparse array (most values are zero) of binary values, where each row and each column have a single non-zero value.  I've illustrated an example Costas array below.

This array represents a series of audible tones, each spaced 6.25 Hz apart on the vertical axis, and spaced 12.64 seconds duration on the horizontal axis.  This may be the correct orientation of tones, or it's possible it needs to be flipped across the vertical axis.  I didn't investigate how the authors assigned the matrix positions to tones since it doesn't really change what follows.  --Original artwork by Mark Hughes

Every FT8 transmission has a synchronization tone sequence positioned at the beginning, the middle, and the end of the transmission.  The software WSJT-X listens to the audio spectrum and then attempts to identify these tones to synchronize the audio.  It doesn't have to be a perfect match at each location. Phenomena such as fading, interference, noise, etc. are accounted for by providing three different spots during the message for synchronization.  However, since each tone is 0.16 seconds long, there are seven tones, and the process happens three times, that's 0.16*7*3=3.36 seconds of each 15-second transmission dedicated just to synchronization!  

In the above animation, time is represented on the horizontal axis, and frequency tones are on the vertical axis.  The sample Costas Array (Red) is swept over the audio transmission (Black) until it finds the greatest number of matching points when the animation turns green.  -- Original artwork by Mark Hughes.

In real life, there would be dozens, maybe hundreds of audio spectrums stacked one on top of another and the search sequence would have to happen in the horizontal (time) dimension and the vertical (frequency) dimension.  That's one of the reasons a few seconds at the end of each transmission are dedicated to "decoding."  It takes a bit of computing time to comb through all the data, identify the separate transmissions, and then display the messages on the WSJT-X interface.

2-3 Seconds of Offset

FT8 transmissions occur in 15-second intervals, alternating every 30 seconds. These intervals are aligned with the start of each minute. Stations transmit either at the beginning or midpoint of these 30-second cycles.  When a radio wave leaves your antenna, it takes 0.066 seconds for it to reach the farthest part of the world from your location.  On the off-chance you're doing an Earth-Moon-Earth (EME) transmission, It takes around 2.6 seconds for the radio wave to leave your station, bounce off the moon, and then return to Earth (that number varies ~0.1 s with the moon's position in the sky).  So the authors of WSJT-X provided a generous ±2.5 s timing offset.  Any longer is a waste of computer resources, and any shorter produces practical difficulties in getting both parties synchronized.  

! Maximum sync correlation lag +/- 2.5s relative to 0.5s TX start time.

When taking the 0.5s Tx start offset into consideration, that means your computer clock can be 3 seconds ahead or 2 seconds behind and you should still theoretically be able to decode transmissions and have your transmissions decoded.

In practice, it's not that simple.  The sender and the receiver have to have that 2.5-second safety buffer overlap, or the software won't be able to decode.  If I'm 2 seconds ahead and my FT-8 partner is 1 second behind, we'll be 3 seconds out of sync.  That means neither one of our ±2.5 second search buffers will allow us to hear one another.

Conclusion

In conclusion, FT8's time synchronization is a finely-tuned process crucial for successful digital communication in amateur radio. The Costas array and the specific 'magic sequence' of tones ensure reliable synchronization, even amidst challenges like signal fading and interference. The WSJT-X software's allowance for a 2-3 second offset, and up to 2.5 seconds for EME transmissions, demonstrates the robustness of this system. This synchronization is essential for decoding messages accurately and ensuring that amateur radio enthusiasts can communicate effectively across vast distances.

In practice, I find myself endlessly clicking the "sync-now" button in JSTsync until the offset is "0 ms."  But I could probably get away with staring at the FT8 frequency in the band of interest and just syncing the clock manually when the transmissions come through.

Edit:  It works!  I used the command line interface "time" command to set a badly out-of-sync computer clock based on the GPS clock and a burst of incoming signals and was able to synchronize my computer clock and receive FT8 signals.  

References:

[1]  Taylor, J., Franke, S., & Somma, F. (2019). FT8: New Data Mode for HF and VHF Bands. QEX: The Forum for Communications Experimenters. Retrieved from https://wsjt.sourceforge.io/FT4_FT8_QEX.pdf

[2] WSJT source code: https://wsjt.sourceforge.io/wsjtx.html 

[3] Mathematica Source Notebook (for graphics/animations):  Mathematica Notebook