Q65-15 - A usable mode for EME?
Q65 is the latest mode for EME and currently (2022) the mode of choice on for EME, though JT65 still has a following on the lower bands. It's a mode designed for EME with more flexibility and sensitivity than either JT65 or QRA64 (in fact it replaced QRA64 as an option in current versions of WSJTX).
Q65 has 5 different Tx/Rx period lengths, 15s, 30s, 60s, 120s and 300s. It's described in more detail here - Q65 Basics and there's also an official Quick Start Guide. In the very early days of Q65 development only the 60, 120 and 300S modes were enabled for EME. All modes could be transmitted just fine, but the 15s and 30s modes could not be decoded because the decoder could not take into account the 2.4-2.8s delay on a signal bounced off the moon. After some encouraging simulation studies, the Q65-30 mode was modified to allow EME signal reception and decoding with the EME delay option enables. I believe that all public releases of WSJTX from v2.4.0-rc1 onwards can both send and decode Q65-30 EME signals. Only early development versions lacked the ability to decode Q65-30 EME signals. In the first weekend of the last EME contest I made around 50 QSOs using Q65-30B. It's quite sensitive, with reliable decodes down to around -24 or even -25 with AP assistance (Q3 decodes). 95% of the stations I hear (with a 3.1m dish) are stronger than that.
While I have actually seen stations announce they are calling CQ using Q65-15A, they never get a reply because currently (October 2022) the Q65-15 mode can be transmitted perfectly well, but the decoder is not designed to operate with the EME delay, so Q65-15 echoes cannot be decoded. This is not explicitly stated in the quick start guide and you can click the checkbox for "Decode after EME delay", but it does nothing. Q65-15A will only be decoded if the DT is in the range -1s to +1s (i.e. terrestrial signals). There are reasons why Q65-15 has problems with EME and therefore not enabled for it. The period is short (15s) and the data transmit time is 12.8 seconds (85 symbols, each 0.15s long). Together with an initial 0.5s delay on Tx, that means the end of the signal is at around 13.3 seconds after the Tx starts. If you add a 2.8 second delay to that for the EME round trip, you can see that the the end of the message would arrive back at the receiver 16.1 seconds later (13.3 + 2.8 = 16.1). So if you started decoding at the end of the incoming data, you would lose at least 1.1s or the message, or about 8 symbols out of the 85 symbols which make up the message.
Signal is received. Upper with DT=0, lower with DT=2.7. Decoding at 15s cuts off some data from EME echo. Decoding at 13s cuts off even more from EME echo
In addition, you have to decode the received message and figure out what the correct response should be before the Tx data stream starts 500ms later. So strictly speaking, the 15s mode is not designed for EME use. But could it be used, even if it's not ideal, and if it is used, how much penalty is there for not having copied all 85 symbols in the message?
The short answer to the question is yes, it can be used, and the penalty for missing symbols is quite small. Probably of the order of 1dB in terms of decode sensitivity for single period decodes. Decode sensitively for single period Q3 decodes is of the order of -21/-22dB. More on that later.
To test the EME capability of Q65-15 I modified the WSJTX source code to allow for fast decoding after an EME delay of up to 3.5 seconds. This should be enough for well synchronized stations, including those with SDR receivers having up to 0.5s of additional audio latency, to decode Q65-15 messages. The decode is restricted to an initial "fast pass" through the decoder, which sacrifices a small amount of sensitivity but ensures signals decode before starting to send a reply. The decoder also only works in "single decode" mode, where it's just looking at one signal within the Ftol limits. This ensures a fast decode (or no decode!) every time on the Q65-15 signal. Sensitivity is still very good as described below. The submode of choice here is A. 15A has the same bandwidth as 30B, 60C and 120D and is a good choice under typical Doppler spreading conditions on 1296.
Testing
On-air Q65-15A QSO. Good copy both ways. 1.9m dish (~ 100W) to 3m dish (~ 240W)
The modified program can be tested using simulated Q65-15 files and it passes those tests quite well. However "on-air" EME decoding is the real test, so for the initial tests I sent time-limited copies of a modified WSJTX program to Bill,KB2SA, and Charlie, DL3WDG (G3WDG). Bill is running a 1.9m dish with power up to 550W or so. Charlie is currently Rx only on 1296, and is using a 1.2m (4ft) dish. I'm running a 3.1m dish with around 240W. So no station involved is a "big gun". A full QSO with Bill was easy using Q65-15A. Even when he turned power down by around 6dB (~ 100W), there was no problem making a QSO. Charlie copied me just fine on his 1.2m dish, and that's about the smallest dish anyone would ever consider using for 1296 EME! So you can see that Q65-15A is not a mode that requires high power or a large antenna.
Results of a test of simulated Q65-15A EME decoding. DT=2.7, Spreading = 20Hz
The above screen grab is from a run of simulated files. At the bottom of the single period decode list on the left the SNR should have been around -22dB. At the bottom of the list on the right (single and averaged decodes), the SNR at the bottom of the list should have been around -25dB.
On-air test and simulation studies indicate that single period Q3 decodes can be made consistently at signal levels of -22/-23dB. If you permit average decodes, you can make 2 period average decodes pretty consistently at around -25/-26dB. Sensitivity decreases for Q0 decodes (no AP assistance), but even there single period decodes at around -19dB are expected and for 2 period averaging this drops to around -21/-22. There numbers are only about 1 to 2dB worse than those expected for terrestrial Q65-15 decodes with no signal loss (DT=0) and extended deep decoding.
The high sensitivity of the Q65-15A EME decoding is a tribute to the robustness of the Q65 encoding scheme, with it's forward error correction and data redundancy. You can loose a significant number of message symbols with only a small effect on decode probability.
With one way tests to Charlie, DL3WDG, we compared decoding of Q65-15A signals with FT8 signals. Both have a 15s Tx/Rx period. Charlie was unable to decode any of the FT8 transmissions, but had no trouble with the Q65-15A transmission, further evidence of the robustness of the Q65 encoding.
Recent testing (10/22) with KB2SA showed that single period AP decodes could be obtained at the expected -22/-23dB level with TX power of 25W at each station. KB2SA was using a 1.9m dish, KA1GT was using a 3.1m dish. This test was done with the moon near apogee, Dgrd=-2.1dB and DT = 2.7. This suggests that Q65-15A QSOs should be possible with the following systems (assuming well optimized systems). The numbers for very small (1.2m) dishes may be slightly optimistic due to decreased dish efficiency for a dish that's only about 5 wavelengths in diameter)
- 1.9m dish to 3.1m dish, 25W at each end
- 3.0m dish to 3.0m dish, 10W at each end
- 2.4m dish to 2.4m dish, 25W at each end
- 1.9m dish to 1.9m dish, 65W at each end
- 1.2m dish to 3.0m dish, 65W at each end
- 1.5m dish to 1.5m dish, 165W at each end
- 1.2m dish to 1.2m dish, 260W at each end
As you can see, with a well optimized system, large antennas and high power levels are not required.
Why?
Why would you want a 15s mode? Why would you want 60s QSOs? Well, first there's just the intrinsic interest in showing what can be done. 15s periods may not be used all the time, but neither are 300s periods. They are modes that are there for special use. I would note in passing that though the Q65 Quick Start Guide has Q65-60C as a recomended mode for 1296 EME, this does not mean it's always the best choice. Some stations seem to use 60C all the time, whatever the conditions. I don't know why. Q65 has a wide range of periods and submodes to chose from and 60C isn't always the best choice. Shorter period modes are faster, longer period modes are more sensitive, Sometimes submodes A or B might give higher sensitivity than C when Doppler spreading is low. There are 22 possible period/submode options. 60C isn't always the best choice (though it will usually work on 1296 for reasonable signals if you don't mind 5 minute QSOs).
A Dxpedition with a very narrow time window might want to make as many QSOs as they can in the shortest time possible. A 15s mode with -20dB or better sensitivity is certainly usable for this purpose. Making a lot of fast contacts to clear a Dxpedition induced pile-up can leave more time for the use of longer modes to work weaker stations. If Q65 has the ability to make 15s period QSOs, why not take advantage of it?
A full QSO takes just 60 seconds if you keep it short. This is all that is required. Callsigns, unknown information, and acknowledgments. Grids are not required (or needed when using CFOM Doppler mode).
- AA1AAA BB2BBB CD12
- BB2BBB AA1AAA -10
- AA1AAA BB2BBB R-15
- BB2BBB AA1AAA RR73
On HF, FT8, another 15s mode, is by far the most used digital mode. While the average HF signal may be stronget than the average 1296 EME signal, many times they are of the same order, plus the HF signals have to work through QRM, noise and other conditions which makes them more difficult to decode than an isolated, relatively stable, EME signal. If 15s modes work well on HF, why would they not be useful on EME, at least for stations with average capability. On 1296s, signals need only be around -22dB for decoding in a single period. On higher bands with wider spreading, signals would need to be a little stronger.
Conclusion
To me, Q65-15A looks like a viable mode for EME, at least on 1296. Even with the simple code changes I made, it is capable of single period decodes down to -22dB and decoding is fast enough that there are no problems with the reply message. The only restriction is that this modification does not allow multiple decodes or extended (lengthy) decode searches on really weak signals. However, if adopted, this would be a fast mode, not a super weak signal mode. Longer period modes are obviously better for extremely weak signals - and thats what they are designed for. I don't know if it will ever become part of an official WSJTX release. That's a decision to be made by the official WSJTX development team if they think the mode might be useful.