WSJTX Q65-15A for EME - Bob Atkins

EME with the Q65 15 second modes (15A, 15B and 15C)

A few years ago I played around with the WSJTX source code and came up with a fairly crude method of enabling decoding of Q65-15A messages sent via EME (see https://bobatkins.com/radio/Q65-15_eme.html and https://bobatkins.com/radio/Q65-15_eme_II.html). In "normal" WSJTX decoding after the EME delay is disables, even when "Decode after EME delay is selected", so they never decode. Recently I revisited this, but this time Uwe, DG2YCB, offered his help. Uwe has a much better understanding of the code then I do and came up with a more stable modification to allow the decoding of Q65-15A (or 15B or 15C) messages. My code occasionally crashed, his seems 100% crash proof and is much better than mine was, so thanks should go to Uwe for this modification. The 2.8.0 version of WSJTX-improved, which contains these (and many other) code modifications is scheduled for release on March 14th 2025 and will be available from https://sourceforge.net/projects/wsjt-x-improved/files/WSJT-X_v2.8.0/ after release.

There is a timing issue with the Q65 15 second modes (Q65-15A, Q65-15B and Q65-15C) when they are used for EME contacts. In these modes, each transmitted tone lasts for 0.15 seconds and there are 85 transmitted tones in a message. This means that the length of the message is 12.75s. For terrestrial contacts there is no issue, because the 12.75 received transmission fits easily into the 15 second period length with time to spare for decoding. However for EME operation, reception of the signal is delayed by the time it takes for the signal to travel to the moon and back. This time varies as the distance of the moon changes, but on average is around 2.5 seconds. It can actually vary between about 2.34 and 2.71 seconds at the moons apogee and perigee limits.

Timing Issues

The blue area is the 15s period window. The red bar shows the received signal with DT=0 and DT=2.5

Q65-15 timing is that the transmission starts 0.5 seconds after the start of the 15 second period (to allow all sequencer and Tx/Rx relay changes to occur). Then the transmission last for 12.75 seconds which puts the end of the transmission 13.25 seconds after the start of the 15 second period. At the receiving station, listening starts at the synchronized start of the 15 second period. but nothing is heard for 0.5 seconds plus the time it takes for the signal to travel to the moon and back. Let's call this 2.5 seconds. So no signal is received until 3 seconds after the start of the period. The signal lasts for 12.75 seconds which would mean it would end 15.75 seconds after the start of the 15 second period. But listening stops at 15 seconds, and even if all of the received signal was decoded (which it isn't in terrestrial modes) at least 0.75 seconds of the transmission is lost. When the moon is closest, this can drop to 0.54 seconds of lost message, while at apogee 0.9 seconds of the message is lost. Since each tone is 0.15 seconds, that means that between 4 and 8 tones out of the 85 tones will be lost.

Note that when you see the "decode" light come on in WSJTX it seems to indicate the first attempt at a decode, sometimes before the message has ended. If it gets a decode, as it will on a strong enough signal, you are ahead of the game. If it doesn't then it will look at more of the message. Form decoding simulation tests, the decoder seems to be looking at something like the first 14.8 seconds of the 15s total message.

While losing tones from the message isn't a good thing, it's not catastrophic bad either. The whole message is encoded in such a way, with extensive error correction coding, that it can be decoded if the whole message isn't received. In fact you can lose 50% of the message and still get a 100% correct decode. The result of losing tones isn't a degrease in the accuracy of the decoding, it's a loss of decode sensitivity. Weak signals mean that not all the tones can be detected. In the case of Q65-15A it has previously been shown (using both simulated and real EME signals, see links above), that the loss in sensitivity with a FT of 2.5 is about 0.5dB. The decrease in sensitivity will be least when the moon is a perigee since signals will be strongest and the echo delay will be the shortest.

This makes 15A about 2dB less sensitive than 30B and about 4dB less sensitive than 60C, but -22dB is still pretty good at decoding weak signals. With a 3m dish, probably at least 90% of all decodes are stronger than that. 23cm 15A should work between two 2m dishes running 100W, and that's quite a small EME station for 23cm.

Decoding

The 15s modes also present some decoding timing issues during a QS0. If the whole of the 15s period is used to receive the signal, and the reply starts out 0.5 seconds later, a decode needs to be made in less then 0.5 seconds in order for the autosequencer to chose the correct reply messages. This is normally not a problem if "fast" decoding is selected or if signals are strong. However on very weak signals when "deep" decoding is selected, the decoding process can take up to 3s even of a moderately fast PC. On my fairly old Windows 7 shack PC, "deep" decoding can take as long as 7 seconds. This can be an issue, though it may mot be as bad as it initially sounds. If a decode of the response to the previously sent message hasn't occurred, the previous message is resent. If a decode is achieved after the message has started, the message will change, so the message content is switched during a transmission. If it's done after a certain point, this will lead to message corruption, which in turn will make the message harder to decode.

The good news is that all replies during a standard Q65 QSO seem to start out with the sequence "Call1 Call2 ...". While the encoded massages are not a sequential transmissions of the message, character by character, the encoding system does seem to produce an encoded message in which the first few symbols are the same, whether the message is "Call1 Call2 Grid", "Call1 Call2 -16", "Call1 Call2 r-16" "Call1 Call2 RR73" or "Call1 Call2 73". So if the message is changed between these options soon enough after the start of the transmission, there is no corruption and the correct tones for the message is sent. For example for various messages starting "DL3WDG KA1GT ..." the following tones appear at the start of the message:

 0 27 10 28 13 38 11 57  0 61  4  0  0 17  0 41 29 35 62 16
 0 27 10 28 13 38 11 57  0 61  4  0  0 18  0 63 41 51 63 13
 0 27 10 28 13 38 11 57  0 61  4  0  0 20  0 63 41 51 48 30
 0 27 10 28 13 38 11 57  0 61  4  0  0 18  0 63 37 51 57 11
 0 27 10 28 13 38 11 57  0 61  4  0  0 18  0 63 38  3 58 12

As you can see, the first 13 tones are identical. Each tone is 0.15 seconds in duration, so the first 1.95 seconds of each message is the same. That means if the message is changed any time up to around 2.35 seconds after the Tx period starts (0.5 + 13*0.15), there should be no penalty and an uncorrupted message should be received. If the message is changed shortly after 2.35 seconds, then it will be some data corrupted, lowering the chances of a very weak signal decode. However, if it decodes, the decode will be correct for the changed message.

The take-way point here is that unless you have a very fast PC which can reliably generate a deep decode on a very weak signal in a couple of seconds, it's probably better just to use "fast" decode. "Normal" decode may also work, depending on timing. In practice the difference even between "fast" and "deep" decoding in terms of decoding a very weak signal is very small. "Deep" can do very slightly better on some signals, but you often need to do statistical analysis of multiple decodes to see that difference. It can slightly improve the statistical probability of a decode on very weak signals.

The best submode to use would depend on the spreading of the signal, as indeed it does for all Q65 modes and submodes. For 23cm where libration spreading is typically around 25Hz, the 15A submode should give the best results. The tone spacing for 15A (and 30B) is the same as that for 60C. If spreading was much higher, e.g. as it is on 10Ghz, and there was a desire to try a 15s mode, the B or C submodes would be expected to give better results as they have the same tone spacing as 60D and 60E respectively.

Operating in a Q65-15 mode

There are a number of things you can do to maximize the odds of making a QSO. These are mostly no different from any other mode.:

Make sure you (and your QSO partner) are time synchronized to UTC time as closely as possible.
For the best chance of a QSO (as with any mode) operate near lunar perigee to minimize path loss - and for 15s modes this also reduces data loss due to EME echo delay
Run in "fast" decode mode unless you have a fast PC
Select "Single decode"
Use auto-sequencing
Turn averaging on

Messing with synchronization - don't do it

You might at first think that if, relative to perfect perfect synchronization, you transit late, then the DT as seen ty a Dx station will be smaller and hence decoding will be easier. You would be correct. If your time is 2.5 seconds ahead of the DX station's time, then the Dx station will see you message arriving with an apparent DT value of near zero and hence all the symbols will be decoded. This give s bit more sensitivity (but not that much). HOWEVER, when the DX station starts transmitting, you will already have been listening for 2.5 seconds because your clock is fast. That means it will be 5 seconds before you see the Dx signal which will have a DT of 5. You will never get a decode with a DT of 5 because only DTs of up to 4 are permitted, and even at a DT of 4 you are seeing some serious decrease in decode sensitivity. While it might theoretically be possible to enhance the probability of a QSO between two stations running very different power levels and antennas, don't bother trying unless you have nothing better to do!. Messing around with time sync is tricky and the benefit you might gain from this is unlikely to be more than maybe 0.5dB at the station receiving the weaker signal and then only under specific conditions of unequal stations. So the bottom line here is to synchronize as close to UTC as possible and hope your QSP partner does the same. Using something like Meinberg NTP should synchronize your PC clock to within a few mS of UTC time.

Why use 15s modes - and what if they don't work?

Well, first of all it's always interesting to try something different and often also interesting to try something more difficult (like CW, QRP, Slow scan Tv or SSB off the moon).

The 15 second period messages in Q65 are obviously not intended for very weak signal work (where "very weak" means weaker then -23dB - which is actually pretty weak!)). However 15A QSOs are very fast (75s if all 5 messages are exchanged) and can enable a very high "QSOs per hour" rate ( four times faster then 60C, twice as fast as 30B) between most stations on 23cm. For a Dxpedition with a reasonably good system (e.g. 2.4m dish and 150W or better on 23cm), it could be used to rapidly work though a pile-up of stronger stations before switching to a longer period mode to work weaker stations, given the weaker stations more time to make a QSO.

In a general QSO, if you don't get a decode after a couple of transmissions of 15A, it's probably best to switch to Q65-30B (or Q65-60C) for greater decode sensitivity. While you can certainly get averaged decodes of more then two periods (I've seen decodes after 9 or more messages have been averaged), after two periods switching to longer period will usually be more effective and result in a shorter QSO time. Try 30B or 60C and don't forget the 120s and 300s submodes for VERY weak stations! See Average or chose a longer period?