This may seem like obvious advice,
but it is surprising how many operators continue
to use earlier versions, which often lack features now regarded as
essential.
Actually I still keep a copy of version 4.9.8 installed because of its EME
Echo mode, which has not yet found its way back into later versions,
but there is no excuse for not using the latest version for actually
operating EME with JT65B.
Download the latest version from http://physics.princeton.edu/pulsar/K1JT/
You know the old saying – “When all else fails, read the manual”. In the case of all the WSJT modes, this is far too late!
A large number of EME operators, including many high-profile stations, learned this the hard way not so very long ago. In April 2007 there was a DX expedition to Gibraltar ZB2, which is quite a rare DXCC prefix on EME. The stations were using the callsigns ZB2/DF2ZC and ZB2/DH7FB. These callsigns are too long for the normal JT65 messages unless the grid locator is omitted. The WSJT program has a number of built-in prefixes which invoke this changed format automatically, but ZB2 is not one of them. The result was that many stations were transmitting callsigns which were truncated, and also defaulting to the less efficient plain text format (red messages instead of yellow). The manual clearly states that a prefix not automatically included in the program can be used correctly by entering it in the Options menu, but you have to read the manual to discover this. And yes, I too missed a whole ZB2 window before discovering this. I never succeeded in working them anyway!
It is important to understand the basic processes by which the coded JT65 messages are decoded when received. Two different levels of decoder are provided. The first is a Reed Solomon decoder using an algorithm by Koetter and Vardy. This is often referred to as the KV decoder. The KV decoder is not always successful in decoding very weak messages. In that case a second level of decoding may be invoked, usually called the Deep Search decoder, using a callsign file CALL3.TXT. Ideally the program would test every possible message to determine which message provides the highest probability of a match to the message actually received. Such a comprehensive search is not remotely practicable in the time available, so the search is limited to the callsigns listed in the CALL3.TXT file. This file comes with the WSJT program, and it is simple to add new entries from within the program.
There has been considerable controversy about the legitimacy of the Deep Search decoder. In reality it merely automates what all operators already do in practice, using either a paper list or their own memory to decide the most likely callsign when copy is difficult. Two digits are attached at the end of the decoded line which clearly indicate which decoder was used and what confidence is associated with the decoding process. It is up to the operator to decide how to interpret the information presented.
Depending on how you set up the program, you will very occasionally see decodes which can be rejected immediately as obvious garbage. A little more difficult is the case when the decode looks superficially plausible, but the other station has no visible moon at the time, such as an American callsign in our European window. Such decodes invariably have a very low confidence number attached to them. You can configure the settings so that such “decodes” are never presented, or you can choose to display them and use your own judgement. Some operators choose never to use the Deep Search decoder, but most (including me) choose to display all decodes and to apply some such rule as to require at least 2 independent and consistent decodes if the Deep Search is used. Of course a single decode in the Average Box is also acceptable.
You will configure the software to suit your own preferences, but here are a few comments.
“View –
Astronomical Data” gives very useful information about the moon position for
both stations and its declination, the Doppler shifts, sky temperature,
relative polarization and so on.
This window is well worth having open all the time.
In the “Save” menu it is a good idea to save the WAV files for at least the Decoded messages, provided disk space is not a problem, so that you can look back later.
In the ”Decode – JT65” menu you must make choices as I discussed above. See the Manual for the implications of these choices. For example if you choose to limit the Deep Search to EME calls, then you will miss out on stations that have only recently taken up EME. I like to see all the decodes, so I tick the “Aggressive DS” box. But make sure that you understand the meaning of the question mark and the 2 digits at the end of the decoded line, so that you can exercise proper judgement about the reliability of each decode.
It is important to set the computer time with reasonable accuracy for the
WSJT decoder to work properly.
An accuracy of +/- 1 second is probably good enough, though most serious
operators aim for about +/- 0.2s.
It is possible to set the computer time manually from WWVH or some other on-air
reference, but there are easier and more effective ways of controlling the
computer time.
If you have an internet connection to the computer which runs WSJT, then
Dimension 4 (D4) is the most widely used software for this purpose.
It is free, and can be set up to access any convenient time server of your
choice, and to update the time at selectable intervals - I do this every 30
minutes.
If you have no internet connection, then GPS time is probably the most
convenient source.
TAC32 is an excellent piece of software (not free) for
this purpose, and there are doubtless many others..
However a word of caution about GPS time.
If you have ever compared the time from a hand-held GPS receiver with a
known accurate time source, then you may have noticed that the GPS receiver
seems to be exactly 2 or even 3 seconds slow.
Part of the reason is that most GPS receivers set a higher priority on
getting the position right, at the expense of the time.
Also there are 2 different ways of extracting information from the GPS
receiver board, by NMEA ascii string, or by binary code (Motorola binary).
The NMEA string is much slower and in my limited experience it is essential
to use a unit in which the time can be read via Motorola binary code. In
fact I have 2 independent GPS receivers in my shack - one uses a Jupiter
engine and NMEA strings, the other is an older Motorola "GT+ Oncore" unit.
I use the
Jupiter unit to lock my 10MHz frequency reference, and the Motorola unit for
setting the time. It is quite instructive to view the displayed times from the 2
units!
It is also interesting to watch the time on my 2 computers, one locked
with Dimension 4, the other with the Motorola GPS.
They usually differ by about 0.2s, not enough to cause much worry, but
enough to make me curious as to which (if either) is actually correct.
Of course there are commercial GPS units available for a price to do the job if you just want something off the shelf.
As well
as watching the dB level of the other station, keep a close eye on his DT
and DF. DT should be around 2.5s if both stations have their timing right.
You should not need to use Dsec to offset the timing in later versions of
WSJT, unless the other station is wildly out as occasionally happens with DX
expeditions.
DF is important for verifying who is sending a shorthand message when
several stations are visible at the same time.
Learn to interpret the shorthand messages directly from the Waterfall display, without waiting for the formal decode. This is especially important when signals overlap, in which case the printed decode may fail.
As soon as you have decoded a station, lock onto his frequency with the freeze function. I generally use 50Hz, which allows some drift to occur, but 25Hz or even 10Hz if two signals are very close together.
Set the Sync to zero. Although some operators have recommended setting Sync to -2, Joe K1JT has explicitly stated that a negative setting has no meaning, and has exactly the same effect as setting the sync to zero.
In cases of bad interference, such as power line noise, it can be helpful to set the Clip level quite high, even to 99.
The Zap
function for birdies should not normally be necessary. I believe that Joe
Taylor has said that the program already attempts to ignore birdies without
invoking Zap.
Personally I have not found Zap to be very helpful.
If you
click one of the open circles to the right of the Message windows, that
message will be selected for the next new TX period.
If you click one of the Tx buttons to the right of the open circles, that
message will immediately be selected. Use this feature to override the
current message being sent if you inadvertently start sending the wrong
message, or if a decode completes only after the transmit period has
started.
It
sometimes happens that a second station is spaced above the wanted station
by a frequency corresponding almost exactly with one of the shorthand
messages.
It is very frustrating to see the program report RO (or RRR or 73) when you
know that a real message with callsigns is being sent to you.
Use the very useful keyboard shortcut Shift-Ctl-D to force a proper decode
of the message.
Peter OZ1LPR
has made a number of specific suggestions for setting up
JT65B, which I fully endorse:
CALL3.txt file
Enter the callsign of the station you want to work in the "To Radio" box. If
the locator comes up in the Locator field then the callsign is in the
Call3.txt file already.
If not, just fill in the right locator and add it. This enables the deep
search routine and gives you 3dB more on RX.
AFC settings
The AFC is good if your QSO-partner has a drift on his frequency. If the
drift is more than 5Hz per TX cycle, then check the AFC box.
If a signal fails to decode when you thought that it should have decoded, it
is worth experimenting with checking/unchecking the AFC box and forcing a
new decode.
However decodes may fail for other reasons, including distortion of the
signal in the ionosphere.
But do not leave the AFC box checked unnecessarily, because you then lose RX
sensitivity.
Drift
Be sure your frequency is stable. About 5Hz drift per minute gives -4dB on
RX and TX.
If nearly all received signals seem to drift, then the problem is probably
in your own receiver! Small rigs often heat up in the TX period, and then
cool during RX, giving a cyclic drift pattern.
4dB is a serious amount of sensitivity to lose. Imagine how much bigger your
antenna would need to be in order to make that up!
AF response
Be sure you TX the same level in all tones. If you run 400W in one tone and
maybe 380W in the other tones, there is no problem. But if you have around
-3dB in some tones you need to find the ripple problem.
Also on RX the response needs to be relatively flat. You can check it using
the FSK441A mode in the program and it should be relatively flat from 400Hz
to 2400Hz.