|
Latest News
April 24. 2004:
Thanks for your interesting comments a couple of weeks ago about the
abilities of skilled operators to copy very weak signals. I'm sorry it has taken
me so long to answer; I have been extremely busy recently.
Peter, SM2CEW, wrote "If I can see a trace [on Spectran] I can copy the signal."
I think I have pretty good CW ears, too -- perhaps not as good as yours, but not
so very many dB behind. I *know* that I can see signals on a waterfall display
that I cannot copy.
An example is shown in the screen dump at
http://pulsar.princeton.edu/~joe/K1JT/cwjt65a2.jpg. This Spectran plot was
made from a wave file that I generated, so I know exactly what is in it. There
is a CW signal at 700 Hz, with signal strength -21.0 dB relative to the noise
power. There is also a JT65 signal, and it has signal strength -24.0 dB relative
to the same noise. The JT65 sync tone is at 1270 Hz. Both signals can be clearly
seen on the Spectran display, although the CW signal is of course 3 dB stronger.
The two signals are far enough apart in frequency that they do not interfere
with each other. I have put the test file on the WSJT web site. You can download
it from
http://pulsar.princeton.edu/~joe/K1JT/CWJT65A.WAV, and play with it
yourself.
I would be astonished if you can copy the CW signal. I certainly cannot; I have
tried playing it (and other ones like it, with slightly stronger CW signals)
back through Linrad, and I need about another 4 or 5 dB before I can copy the
code. Perhaps with some effort playing with the DSP filters I could do one or
two dB better than that -- but I'm sure I have an ultimate limit no better than
-16 to -18 dB, at the very best. This is hardly surprising; -17 dB in my
reference 2500 Hz bandwidth is 0 dB in 50 Hz, and I do not believe anyone can do
much better than that.
The CW signal in the test file runs for about 53 s. It is a standard short EME
message sent repeatedly up to the end of the file.
The JT65 signal, which is exactly 3 dB weaker, lasts for a slightly shorter
time, 46.8 s. It can be decoded immediately by reading it into WSJT. As you
probably know, at SNR = -24 dB WSJT gives nearly 100% perfect copy. By averaging
over a few transmissions, JT65 works well down to -28 dB or so. To set the
record straight: there is no way that CW can be copied by human ears at such
levels.
If anyone would like to make test files of their own for such comparisons, or
for testing and calibrating their own CW copying ability or the sensitivity of
the JT65 decoder, I have made a user-friendly version of the simulator program
that I used to develop the WSJT modes. In order to further this discussion, I
added an ability to generate CW signals as well as JT65 signals.
The program is called "SimJT", and can be downloaded from
http://pulsar.princeton.edu/~joe/K1JT/SimJT050.EXE
To install it just execute the distribution file and tell the installer to put
it in your main WSJT directory. (You must already have WSJT installed to use
SimJT.)
With the program configured as delivered, if you press "Start" and then "Stop" a
few seconds later, the program will write a file called A00001.WAV into your
WSJT directory. This file is like the test file mentioned above: it has a CW
message at SNR = -15 dB centered at 700 Hz, and a JT65 message at -22 dB with
the sync tone at 1270 Hz. In this instance the CW at -15 dB is strong enough to
copy by ear. The JT65 signal is fairly strong by JT65 standards.
SimJT allows you to set signal levels, CW sending rate, center frequencies, JT65
mode, etc., as you wish. Signal to noise ratios are controlled very accurately.
The noise is generated so as to have a flat spectrum between 200 and 2700 Hz,
falling off steeply outside that region. Aside from the additive nearly white
gaussian noise, the signals are steady in amplitude and frequency. This version
of the program does not simulate libration fading or other QSB.
Files produced by SimJT can be played directly to the speaker and can be saved
for later playback into Spectran, WSJT, Linrad, etc., although I have written
versions that will do that as well.
We are, indeed, all different. I love working CW, weak signal or otherwise; and
my emotional feelings about WSJT modes are necessarily suspect and irrelevant
because of an obvious prejudice that is hard for me to eliminate.
However, I cannot let stand without comment your claims that seem to be saying
that with good enough operators, CW can work effectively at the same signal
levels as JT65. It simply is not so.
-- 73, Joe, K1JT
Latest News
March 28. 2004:
Version 4.6.1
1. Improved automatic frequency control in JT65 modes. If you have lost
JT65 QSOs because of unstable oscillators, this is for you.
2. The acceptable range for DT in JT65 mode is now -1 to +5 s. This range is a
better fit for EME communication than the former -2 to +4 s. It will allow for
somewhat greater clock errors before inter-station synchronization fails on an
EME path.
Note to experienced users: this means that the plotting scale for the "blue
curve" now runs from -1 to +5 s. EME signals should normally produce a blue
peak near the center of the plot area.
3. When the blue window displaying moon coordinates has been toggled to display
coordinates for the DX station as well as the home station, it now displays
MaxNR in place of SD. MaxNR is the maximum path non-reciprocity in dB. This
effect arises from the combination of spatial polarization shift plus Faraday
rotation; it is what causes "one way propagation" between stations that use
fixed linear polarization.
4. A facility for generating the file ID.WAV for station identification is now
built into WSJT.
5. The "Save Decoded" menu item now saves files with decoded shorthand messages
as well as normal messages.
6. JT65 has a new shorthand message "ATT" (for "Attention!"). It is intended as
an aid to help two stations find each other by determining the correct DF.
7. Visual aids for evaluating JT65 shorthand messages "by eye" are provided if
you click on the sync-tone frequency in the Big Spectrum display.
8. For DXpeditions: a country prefix preceded by "/" may be substituted for the
grid locator in a type 1 JT65 message.
9. Alternatively, a signal report of the form "-NN" or "R-NN" may be substituted
for the grid locator in a type 1 JT65 message. For example, -24 might indicate
that signals were being received at -24 dB. The minus sign is required, and NN
must lie between 01 and 30.
10. The receiver noise level reported by Measure mode (the level of the "green
line") has been increased by 2 dB to be consistent with levels reported by the
other operating modes.
Release 4.6.0 of WSJT is now available for
free download.
The principal change from version 4.2.1 is to offer three JT65 submodes.
New and more sensitive decoder for the JT65 modes. If you arr doing EME with
WSJT, you need this upgrade! The submodes differ in tone spacing and total bandwidth as follows:
Mode Spacing Total BW
-------------------------
JT65A 2.7 Hz 177.6 Hz
JT65B 5.4 355.3
JT65C 10.8 710.6
Note that JT65A is identical to the original JT65. If you want to work people
who have not yet upgraded to v4.3.3, be sure to select mode JT65A. Otherwise,
be sure to use the same mode that your QSO partner is using. Cross-mode
contacts will not work.
JT65B should be nearly as sensitive as JT65A, and it will be twice as forgiving
of frequency instabilities. On balance, with existing "stock" radios, JT65B
will probably be better than JT65A. JT65C is less sensitive by a small amount,
perhaps 1 dB, but will be even more lenient on stability issues. By all means
experiment with the different submodes, and be sure to let me know your
conclusions about them!
I am presently inclined to recommend that JT65B should become the
"standard" JT65 mode. If this tentative conclusion holds up, future versions of
the program may no longer support the A and C modes.
Other changes from version 4.2.1 include the following:
1. Further improvements have been made to the JT65 decoding algorithm. These
improvements apply to all three submodes. Some wave files that would not decode
with v4.2.1 now decode properly, especially in averages over several minutes.
2. The frequency width W of the sync tone (the "red spike") is now measured and
displayed in Hz after DF in the main text box. In any of the three JT65 modes, W
should be no more than 2-4 Hz under good conditions. Uncorrected frequency
drifts, excessive oscillator phase noise, and certain propagation effects can
make the width larger. Anything over about about 4 Hz will impair copy in
JT65A. Similarly, widths greater than about 7 and 15 Hz will begin to impair
copy in JT65B and C, respectively.
3. The utility program CWID.EXE now accepts lower case letters on the command
line. It also permits you to specify the audio frequency of the tone in the
wave file. You may wish to place the tone at 600 Hz or lower so that it lies
well below the tones generated by any of the WSJT operating modes.
4. The "Clip" function has been improved in several ways. The yellow and
magenta curves in the Big Spectrum display no longer disappear when Clip > 0.
Setting Clip = 3 does hard clipping, as before, but it also blanks out any data
regions with average power well above the "baseline" of the green curve.
Experimenting with different values of Clip may help you to recover good copy
from noisy data.
5. I believe that the text window displays in Monitor mode, and when you are
using the Include/Exclude buttons, nor function correctly.
6. Minor bug fixes: the program no longer crashes in EME Echo mode if you select
"EME Calc | Load | Cancel". The correct "S" value is listed on the status bar
in JT6M mode.
7. The program's "Fit and finish" is improved in several not very
important ways.
As usual, I will appreciate receiving email with comments, suggestions, etc.,
about this new release of WSJT.
-- 73, Joe, K1JT
JT65 Instructions and Frequently Asked Questions
------------------------------------------------
Joe Taylor, K1JT
1 Introduction
WSJT Beta Release Version 4.2.1 is now available. The JT65 mode is very
significantly improved in this release. Changes from the previous version
include the following:
1.1 Message averaging now works correctly
1.2 Many small improvements to the decoding algorithm
1.3 Decoding speed improved by 50%
1.4 Monitor mode has been properly implemented
1.5 TX message can be changed up to t=59 s of RX period
1.6 Switch to a shorthand TX message at any time
1.7 Freeze works properly for shorthand messages
1.8 Decodes with failed FEC (forward error correction) are optionally
displayable
1.9 "Garbage filter" provided so that questionable decodes appear only if they
contain some recognizable text
1.10 Automatic station ID, as in FSK441 and JT6M modes
1.11 A companion program to generate a CW ID.WAV file is now available
1.12 The birdie zapper now works in JT65 mode
1.13 "Clip" function has been reactivated
1.14 F5 help screen updated to reflect JT65 practices
1.15 "OOO" message handled more transparently
1.16 Optional display of Moon Az/El at DX station, replacing Sun Az/El
1.17 Right/Left audio out now works properly
1.18 DT displayed as blank rather than 0.0 for shorthand messages
1.19 No program crash if ToRadio or Grid left empty
1.20 No program crash if attempting to decode 60 s file in JT6M
1.21 All other reported problems causing crash have been fixed
The initial releases of JT65 use tone spacings of only 2.7 Hz, four times
smaller than those used in JT44. It is not yet clear to me whether the potential
advantages of this choice -- including higher sensitivity and much smaller
occupied bandwidth -- will be compromised too much by the stability requirements
they impose on electronics and propagation paths. If you have gain experience
that would help me to make a final choice in this matter, please let me know
about it.
Careful measurements on single transmissions with JT65 show that its messages
are decoded reliably yielding 100% copy at the following approximate levels:
1. Call1 + Call2 + Grid -22 dB
2. OOO added to above -28
3. Plain text -20
4. Shorthand messages -28
In contrast, JT44 requires approximately -19 dB to give 100% copy in a single
transmission.
Please continue to send me reports of your experiences with this new version of
WSJT, and especially with the new JT65 mode. The program's evolution benefits
greatly from the collected wisdom of those who use it.
2 Installation
2.1 Upgrade path
The default WSJT upgrade path is from v3.8.1 or v4.1.1 to v4.2.0. If you start
with an earlier version such as 3.0, it may be necessary for you to also
download the file MSCOMCT2.OCX. This file can be found at
here. Please report to me any installation problems you may have. WSJT
should run on all versions of Windows since Win95.
2.2 Location of files
Most installations place the main program files WSJT4.EXE and WSJT4.DLL in your
principal WSJT directory. By default that directory is C:\Program Files\WSJT,
but you may have chosen another location. The remaining files go into a system
folder, which (depending on the Windows version) may be C:\Windows\System,
C:\Windows\System32, or C:\WINNT.
In a few instances WSJT v4.1.1 has reported on startup that it "cannot find the
required WSJT4.DLL", or some such message. Copying the DLL file to the system
folder seems to solve the problem.
2.3 INI file
A few people have reported problems on program startup that were traced to a
corrupted initialization file WSJT4.INI. If you think this may have happened you
should delete the INI file and restart the program, remembering to reset your
station parameters on the Setup | Options page. You may also need to click the
onscreen "Default" button in order to get reasonable starting parameters for the
decoders.
3 Operation
3.1 Clip
The "Clip" function should now behave in JT65 as it did in JT44. An improved
algorithm for removing the effect of pings is still in the works.
3.2 Filter
The JT65 mode will now optionally display message text whenever sync has been
achieved, even though the decoder may not be confident that the text is correct.
To avoid displaying too much gibberish, a text "Filter" function has been
provided. This function compares whatever text the decoded can provide against
an "expected message" that you can enter by clicking on the "Filter" button. A
slider controls how many characters must match before any text is displayed. I
do not
recommend setting the slider to numbers lower than 4 or 5, unless you like
looking at a lot of gibberish on your screen. Some experimentation with this
function will help you to get a feel for how it works.
3.3 Fast CPU and Switching TX Messages
The state of the checkbox labeled "Fast CPU" on the Setup | Options page is now
saved and restored when you restart the program. If you tick this box the
program will start decoding a received data file as soon as it becomes available,
at approximately t = 52 s of the RX minute. With a reasonably fast computer,
this will enable you to receive a decoded message and then quickly switch to a
new TX message, if desired, before your next transmission begins. You can switch
the
TX message up to t = 59 s of the RX minute.
In addition, it is now possible to initiate a JT65 shorthand message at any time
-- even while a different transmission is already underway. For maximum chance
of getting the new message through, you should do this as early as possible in
the transmission period.
3.4 Message formats
The six TX text boxes are all equivalent. If your message starts with "RO ", "RRR",
or "73 ", a shorthand message will be sent. If it consists of two legal
callsigns, or two legal callsigns and a legal grid locator, optionally followed
by " OOO", then the normal (optimally compressed) message is sent. CQ or QRZ can
be substituted for the first callsign, and other special tokens may be defined
later.
With any other entry, 13 characters of plain text will be sent. The system will
exhibit slightly higher sensitivity with the compressed standard messages than
with plain-text messages.
3.5 Decoded Text, the "OOO" flag, and Shorthand Messages
The numbers for Sync, dB, DT, and DF mean essentially the same thing that they
did in JT44. The symbols * and # mean that the program thinks it has detected a
valid sync signal. Shorthand messages, regular message text, and the "OOO" flag
follow these parameters on the lines of output.
Like JT44, JT65 uses a special pseudo-random sequence to define the tone
intervals devoted to data and sync tones. Unlike JT44, however, JT65 messages
use two different pseudo-random sequences. The first one is used for normal
messages, and the second for messages ending in "OOO", the standard EME signal
report. The distinction between * and # following DF in the decoded text line is
that # indicates the second sync pattern has been detected. If the sync is valid,
this means that
your QSO partner is sending the "OOO" message.
Question marks indicate "OOO" and shorthand messages about which there may be
some doubt. These occur when the "OOO" sync is found but the message text is not
successfully decoded, or when a probable shorthand message is detected but you
have not yet set "Freeze" on the sync tone of the other station and reduced "Tol"
to a value or 100 Hz or lower.
Shorthand messages are a powerful feature of JT65. They can be very reliable if
properly used. You should understand what they are, and how they work. You
should NOT accept a single decoding of a shorthand message unless its DF matches
one you have already established for the transmitting station.
Because shorthand messages are not closely synchronized in time, no value is
given for them in the DT column.
For those who like to decode by ear (or by eye using Spectran or an equivalent
program), it may help to know that the tone spacings for shorthand messages are
as follows:
RO 53.8 Hz
RRR 80.8 Hz
73 107.7 Hz
3.5 Computer speed
The decoding process takes longer in JT65 than in other WSJT modes. I worked
hard on optimizing the code, and version 4.2 is considerably faster than v4.1.1
in some areas. Measured decoding times on several different computers for
version 4.2 are as follows:
CPU Clock Mem O/S FSK441 JT6M JT65
---------------------------------------------------------------
Pentium II 233 MHz 64 MB Win95 2.4 3.3 7.1
Pentium III 800 MLz Laptop 128 MB Win98 1.2 2.0 3.5
Pentium IV 1.5 GHz 256 MB Win2k/Pro 0.8 0.9 1.7
4 Known bugs
As far as I have been able to determine, all of the bugs reported in beta
release 4.1.1 have been fixed. I am not so silly as to thing that version 4.2 is
bug free, however.
5 And finally ...
Please, please: if you have had problems with something about the way JT65 works,
or have good ideas that would help others, send them to me so that I can include
them here.
If you find evidence suggesting that the tone spacing in JT65 is too small for
good performance with the stability of existing rigs, please let me know. The
"red spike" that indicates synchronization of a JT65 signal should be single and
narrow. Double peaks or broad peaks can be caused by frequency instability and
by certain propagation effects. If the tolerances required by JT65 are too tight
in practice, I want to know about it.
Of course, please report any bugs that you find.
-- 73, Joe, K1JT
k1jt at arrl dot net
Features and Technical Specifications of JT65
---------------------------------------------
Joe Taylor, K1JT
1 User Features
1.1 Transmit/Receive period: 60 s
1.2 User messages of three types:
1. Call_1 + Call_2 + Grid
2. Shorthand messages for RO, RRR, and 73
3. Arbitrary text up to 13 characters
1.3 Message averaging: continues without penalty when "OOO" is
added to message type 1
1.4 Forward error correction (FEC) included in message types 1 and 3
1.5 Automatic Frequency Control: corrects drifts up to 10 Hz/min
1.6 Sensitivity: exceeds JT44 by at least 3 dB (see below)
2 Message Coding and Transmission
2.1 User message source encoded to 72 bits
2.2 FEC with RS(63,12,52) block code and 6-bit symbols
2.3 9 x 7 interleaving of encoded symbols
2.4 Convert to 6-bit Gray code
2.5 64-ary continuous-phase FSK modulation
2.6 Sync tone at 65th frequency in pseudo-random sequence
3 JT65: Reception and Decoding
3.1 Time and frequency lock using sync tone and pseudo-random
sequence
3.2 Automatic frequency control follows frequency drifts up to
10 Hz/min.
3.3 Noncoherent detection using 64-bin spectra
3.4 Ratio threshold test marks symbol erasures
3.5 Remove Gray code
3.6 Remove interleaving
3.7 Reed-Solomon decoding with Berlekamp-Massey errors-and-erasures
algorithm
3.8 AFC is aided by advance knowledge of "expected message"
4 Technical Specifications
4.1 Duration of transmission, key down: 46.8 s
4.2 User information, per transmission: 72 bits
4.3 Total bits sent per transmission: 378 bits
4.4 Modulation: 64-ary orthogonal FSK, continuous phase
4.5 Demodulation: noncoherent power spectra
4.6 Symbol size: 6 bits
4.7 Symbol duration: 4096/11025 = 0.372 s
4.8 Keying rate: 11025/4096 = 2.69 baud
4.9 Channel bandwidth: 2.69 Hz
4.10 Total occupied bandwidth: (64+3)*11025/4096 = 180 Hz
4.11 Synchronizing: uses 65th tone (orthogonal to all others)
4.12 Synchronizing vector: 63 symbols, pseudorandom pattern
4.13 Total symbols per transmission: 126
4.14 Data symbols per transmission: 63
4.15 Sync symbols per transmission: 63
4.16 Primary FEC code: Reed Solomon, RS(63,12,52)
4.17 FEC code rate: 12/63 = 0.19
4.18 Additional encoding: 7 x 9 interleaving and Gray code
4.19 Decoding: Berlekamp-Massey algorithm, with erasures
4.20 Source encoding of callsigns and grid locators: basic idea from
Clark and Karn's EME-2000 paper
4.21 Shorthand messages:
1. Two tones in alternating sequence
2. Tone duration: 16384/11025 = 1.49 s
3. Tone separation: N*26.92 Hz, N=2,3,4
5 JT65: Sensitivity comparison with JT44, single transmission
5.1 NB: Positive dB numbers mean that JT65 is better by stated amount
5.2 Figures do not include source coding gain. Depending on message
length, this can be up to 2.6 dB in favor of JT65
5.3 AWGN channel BER=0.01: +3.6 dB
5.4 AWGN channel BER=0.001: +4.5 dB
5.5 Rayleigh channel BER=0.01: +9.7 dB
5.6 Rayleigh channel BER=0.001: +11.0 dB
5.7 Shorthand messages: +5 to +7 dB, approximately
|
