FT8 on 1296 EME - Bob Atkins

FT8 for 1296 EME

FT8 is a "fast" mode in WSJT-X. Each over is 15s and all signals on the waterfall are decodes. These attributes, plus the small, 50Hz, bandwidth make it very popular on HF. The recent (5/20) update of WSJT-X (v2.2.0/2.2.1) has incorporated a number of changes to the FT8 mode.These are described in the WSJT-X Release Notes (K1JT) as follows:

FT8: "Decoding is now spread over three intervals. The first starts at t = 11.8 s into an Rx sequence and typically yields around 85% of the possible decodes for the sequence. You therefore see most decodes much earlier than before. A second processing step starts at 13.5 s, and the final one at 14.7 s. Overall decoding yield on crowded bands is improved by 10% or more. (Systems with receive latency greater than 0.2 s will see smaller improvements, but will still see many decodes earlier than before.)"

This is information is mainly aimed at HF operation. However, in addition, checking the "Decode after EME delay" (on the WSJT-X Setup screen) is now effective for the decoding of FT8 EME signals.

Lost Data

There are several issues of concern when using FT8 on EME, the primary one being a consequence of the EME delay time. A signal bounced off the moon arrives back on earth between 2.4 and 2.8 seconds later (depending on the distance to the moon at the time). FT8 is a "fast" mode with 15s periods. The message length is around 12.65 seconds and it's preceded by a 0.5s delay. So the end of the message occurs 13.15s after the start time (0, 15, 30 or 45 seconds after the minute). If you add in, say, 2.5s for the echo delay, that means the end of the message arrives back on earth at 15.65 seconds (13.15 + 2.5) after the start (0,15,30 or 45s after the minute). But the maximum Rx period is only 15s long (actually slightly less than that because the message has to be read and decoded before the next Tx period).

The result of this DT increase is that the tail of the message is lost. For FT8 the last 7 symbols are a Costas synchronization array [1,2] and take up about 1.11s, so you lose that synchronization data. If it was the only sync data, this would be a disaster because without sync there can be no decode. But it's not that bad. FT8 sends 3 sync arrays, one at the start of the message, one in the middle and one at the end. So if you lose the final sync array you can still get sync from one of the other two, assuming the signal is not so weak that the first two sync signals are lost. As Joe (K1JT) notes in the Release notes, decoding in FT8 is first attempted 11.8s into the message and is around 85% successful, so clearly the tail of the message is not required for a good decode (and long as the signal is reasonably strong). FT8 uses FED (Forward Error Correction) and so has the capability of reconstruction a limited number of lost bits, whether due to noise or because they are lost by a truncated transmission, so overall loss of a few data bits (for whatever reason) may not prevent a decode.

The consequence of the loss of data at the end or transmission is that decode probability drops significantly when signals are down at the sensitivity limit for FT8. Experimentally, for FT8 on 1296 this is somewhere in the -19dB to -20dB range (with AP enabled).

The chopping off of the tail of the transmission also means that good time synchronization between the transmitting and receiving stations is important. You don't want to lose more data bits than you have to. Local PC sync should be done using something that keeps your time within 0.1s of UTC. This isn't difficult if you use something like Dimension 4 or Meinberg NTP.

Libration Spreading

A second concern when using FT8 on 1296 is the tone spacing of FT8 is only 6.25Hz. Libration spreading [3,4] on 1296 can be up to about 30Hz, so you might think that such a narrow tone spacing would not work. If the 1296 echo was uniformly spread out over the whole 30Hz, then indeed FT8 would not work, but fortunately it isn't. I made some measurements of a constant frequency carrier (from ON0EME) at a time when WSJT-X predicted around 13Hz of libration spreading. Doppler tracking was done in 0.3Hz steps. Here's a plot of signal power (in linear units, not dB) vs. frequency for the echo.

You can see here that although the echo does indeed spread out over about 13Hz, as predicted, most of the power is contained within about 3Hz, well inside of the 6.25Hz tone spacing of FT8. I have not yet made measurements when libration spreading is at a maximum (about twice that of the above plot), but I have made contacts at mutual spreading values around 23Hz and I have not seen any significant reduction in decode sensitivity.

Experimental Results

So just how much does the data loss cost you? Well, there are two ways to do that - on-air testing and simulation. On air testing was done with the assistance of Charlie, G3WDG. These were just one-way contacts. I transmitted FT8 signals using a 3m dish and 250W, while G3WDG received my signals using a 1.2m dish. The received signal was right around the decode threshold for FT8. By adjusting his PC clock, G3WDG was able to compensate for the EME delay and present as much of the signal as possible to the FT8 decoder. It was clear that around the decode limit (in the -18 to -20dB range), there was a higher probability of decoding the signal when compensation was made for the EME delay and the whole of FT8 data was presented to the decoder.

A second way to measure the effect of truncated data is to make a recording of FT8 signals and sample 15s segments of the audio with starting at either 0.5s before the FT8 data starts (corresponding to no delay) or starting 3s before the data starts (corresponding to a DT of 2.5s). These samples can then be played back and decoded using WSJT-X, simulating signals with no delay and signals with a 2.5 (or 2.4 - 2.8s) seconds of delay as would be received via the moon.

Here's data which compare the same signal with zero delay (i.e. a terrestrial signal), with a signal delayed by about 2.8 seconds (the maximum EME delay). This was a real signal with noise added (by WSJT-X) each time to lower the SNR down to the 19/-20dB level. The original signal decoded at -10.

This shows the decode results from 100 attempts at decoding a signal with DT=2.8 (and "decode after EME delay" turned on), followed by 100 attempts at decoding a signal with no delay (and "decode after EME delay turned off). You can see that in the first case, the signal with a 2.8s EME delay decoded 5 times out of 100 attempts. In the second case, the same signal, but this time with no data "chopped off" by the EME delay, decoded 18 times (though 6 of those decodes were "questionable" and marked ?). Results with a 2.4 second EME delay were similar.

Conclusions

A number of conclusion can be drawn form this data:

FT8 is a usable mode for 1296 EME operation. With reasonable signals (around -16/-17dB or stronger) a QSO can be completed in 1 minute (4x faster then JT65C)
There is some sensitivity loss on the EME path with very weak signals (within a dB or so of the decode limit) which is probably due to data truncation and the loss of the final Costas array data for sync. However, FT8 is not intended to be a weak signal mode. For signals below about -18dB (in the standard WSJT 2500Hz bandwidth), FT8 would not be a good mode to choice, though decodes at -19 and even -20 are possible with AP enabled. JT65C would have no problem at all with such signals and would not even need assistance from AP or deep search.
FT8 not a truly "weak signal" mode (nor was it ever intended to be), but for most people it will copy a weaker signal than is possible with CW, and for most people it will enable a faster weak signal QSO than is possible on CW. While it's possible that some "golden eared" CW experts might be able work an EME QSO in 60s at a signal level of -17dB, I certainly could not. QSOs faster then 60s are certainly possible between good CW operators when signals are strong (maybe -12 and stronger?), but I'm not even in that group.
An accurate PC clock, controlled by an NTP server, and within 0.1s of UTC may certainly help and that's not difficult to do. Being a second of two off will certainly hurt.
The amount of libration spreading normally found on 1296 EME does not seem to significantly degrade FT8 performance. The same may not (and almost certainly does not) hold true for the higher frequency EME bands which have larger values of libration spreading and different overall echo shapes.

What do you need to work FT8 on 1296

For reasonable decode probability you probably want a signal level of -18dB or higher. That means something like a two 2.4m (8ft) dishes running around 150W should be able to work each other on FT8. Obviously, if one end of the link has a larger dish and/or more power, the other end can be smaller and/or run lower power. Testing with G3WDG has shown at a 3m dish with 250W (me, KA1GT) can be just about be heard and decoded with a 1.2m (4ft) dish. So fairly average 1296 stations should be able to work each other without too much of a problem. Stations using Yagis, very small dishes and/or low power are going to need to look for the "big guns" for an FT8 contact.

Why Bother?

The final question is "why use FT8 for 1296 EME?". FT8 is used on HF for a number of reasons. The bandwidth is small (~50Hz), so you can put a lot of signals in a small frequency band. This isn't an issue on 1296. There's lots of bandwidth available and not many stations to fill it. FT8 also can decode all the signals present on the waterfall. Again on HF this is pretty useful. On 1296 EME there's rarely more than one signal on the waterfall, so that ability is of limited use.

However, apart from just scientific curiosity, there are probably a couple of situations in which the fast QSO speed of FT8 (1 minute QSO vs. 4 minutes for JT65C) might be useful. The first is at the beginning of EME contests. Typically there are lots of stations around, many of them quite strong, and working up to 60 stations/hr with FT8 vs. 15 stations/hr with JT65C might be useful. The second situation in which FT8 might be a good choice of mode is for a Dxpedition with reasonable transmit power. There can be "pile-ups" even on 1296 EME under such conditions. If the strong stations can be quickly worked on FT8, it gives more time to dig deeper and work the weaker stations using JT65C.

Acknowledgments

Special thanks to Charlie, G3WDG, for extensive discussions, tests and assistance in undertaking libration spreading(!), and to Steve, K5DOG, for providing on air FT8 test signals.

References

Final note: For those who want to try FT8 on EME, note that you MUST be running WSJT-X version 2.2.0 or later. See https://physics.princeton.edu/pulsar/K1JT/wsjtx.html

Addendum

Here's a screen shot recorded by Charlie, G3WDG, who was monitoring a QSO between me and UA3PTW, using his 4ft dish. In this case he had my call sign entered as the Dx stations and UA3PTW entered as the Home station, with the QSO state set to Tx1 in order to assist the AP decoder. As you can see, a complete recording of the QSO (following UA3PTW's CQ call) was made with my signal at the -20dB level with an A3 AP coding assist (though my final 73 has a "?" which indicated the decode was subject to some uncertainty).

Screen shot from G3WDG

Note that despite some Doppler drift on both signals (in addition to any Doppler spreading), and a rather long DT of 3.2s, decodes down to -20dB (AP A3 assisted) were still possible. This suggests that FT8 decoding is pretty resilient and can get both sync and data under non-ideal conditions on pretty weak signals.