JT9 - nowy tryb cyfrowy
Czy wyprze QRSS?
Joe K1JT spełnił kolejną prośbę użytkowników i opublikował wreszcie changelog czyli szczegółową historię zmian w WSJT-X

Poniżej tekst w oryginale. Nie mam planów tłumaczenia tego na polski, zainteresowani dadzą sobie radę

Pozdrawiam
Jurek
SP1JPQ & SO1D

WSJT-X Changelog

November 30, 2012: v0.5, r2788

Changes from r2786 include the following:

1. A bug was introduced when support for positive signal reports was
added. It could cause a program crash when certain free-text messages
were composed for transmission. The bug has been fixed.

2. In the slower JT9 sub-modes, the UTC listed on decoded text lines
has been changed to the start time of the Rx sequence, rather than the
time of the final minute.

3. The waterfall's "Auto Zero" button had no function, and has been
removed.



November 29, 2012: v0.5, r2786

Changes from yesterday's r2783 are minor, but may be important to you.

1. In r2783, the companion program jt9.exe (started automatically when
you start WSJT-X) was a CPU hog for no good reason. This was an
oversight on my part, and the bug has been corrected.

2. The program should now run correctly if installed in a directory
whose name contains embedded spaces. (Under Vista and Win7, however,
it's still not a good idea to install WSJT-X into C:\Program Files,
because of restricted write permissions there.)

3. In r2783 and earlier, stopping a transmission by toggling to "Auto
OFF" would terminate Tx audio and release PTT almost simultaneously,
possibly hot-switching your T/R relay(s). This has been corrected so
that proper sequencing takes place.


November 28, 2012: v0.5, r2783

This revision has an unusually large number of changes relative to the
previous release, v0.4 r2746. These changes include:

1. PTT control via COM ports COM10 and higher is enabled.

2. Improved decoder performance: higher speed as well as better
chances of success. Moderate amounts of frequency drift are detected
and compensated. Computed S/N values are more reliable. Time offsets
from -2.5 to +5 s are now supported, which makes JT9 usable for EME.
(EME tests on 144 MHz have been successful, and performance on that
propagation mode appears to be good.)

3. Tx Frequency now tracks the selected QSO Frequency (unless you hold
down the CTRL key when setting QSO Frequency via mouse-clicks or the
F11/F12 keys).

4. Decoded text containing "CQ " is highlighted with green background;
text including "MyCall" is highlighted in red.

5. In previous versions, signal reports were required to be in the
range -30 to -01 dB. In v0.5 r2782 the range has been extended to -50
to +49 dB. There is backward compatibility for the range -30 to -01,
but reports in the range -50 to -31 and 0 to +49 will NOT be decoded
correctly by previous program versions. It is important to upgrade!

6. Items "Save Synced" and "Save Decoded" are now implemented.

7. UTC Date, JT9 submode, and a parameter related to the decoding
procedure are now included in file wsjtx_rx.log.

8. Editing of Tx messages (in any of the six Tx message boxes) is
complete when you hit "Tab" or "Return". The message is then parsed
and converted to the form in which it will be displayed if decoding is
successful. Free-text messages are trimmed to 13 characters and
highlighted with a pink background.

9. The most recent transmitted message is displayed in the right-most
label on the status bar. This can be useful if you have lost track of
where you were in a QSO.

10. By default, the program now starts with Monitor ON. An option on
the Setup menu allows you to select "Monitor OFF at startup".

11. Better scaling is provided for the red "JT9 Sync" curve. Note
that JT9 signals in the active sub-mode should appear in this plot as
a bump of width equal to the total signal bandwidth, with a narrow and
slightly higher bump at the left edge. The narrow bump is the
frequency of the Sync tone, which is defined as the nominal frequency
of the JT9 signal.

12. Basic QSO information is now written to file wsjt.log when you
click the "Log QSO" button.

13. The WSJT-X User's Guide has been updated.

14. Other known bugs have been fixed. There will probably be new
ones! When you find one, or if you know of any old ones that have NOT
been fixed, please send me email.

Summary of Present Status
----------------------------------------------------------------------
I believe that WSJT-X is now a stable and very usable program. Many
thousands of QSOs have been made with JT9-1, mostly at HF -- I have
made nearly 100, myself. Also a number of QSOs have also been
completed at MF, and successful tests have been made on 2m EME, etc.
A number of QSOs have also been made with JT9-2.

As far as I know the slower modes (JT9-5, JT9-10, and JT9-30) also
work correctly. (Certainly they do in my laboratory test setup.)
Most people will find these modes too slow for "everyday" use, and
they require high frequency stability. It remains to be seen whether
they will be widely used.

An alternative approach to obtaining improved sensitivity would be to
give the decoder an ability to average over several successive
transmissions. For example, the average of five JT9-1 transmissions
could reach a decoding threshold around -32 dB, only 2 dB worse than a
single JT9-5 transmission. Because of QSB, the shorter transmissions
may actually succeed in less total time. Stability requirements would
be those of JT9-1, much less stringent than those of JT9-5.

Program development is not finished, by any means. I will be grateful
for your feedback on performance issues, as well as your "wish-list"
of features to be added. As always, example recordings of files that
you think should have decoded, but did not, will be much appreciated.

November 16, 2012: v0.4, r2746

Changes from v0.4 r2731 include the following:

1. Valid signal reports are now generated by double-clicking on a
callsign in the decoded text window.

2. Consecutive spaces in a Tx message are now collapsed into a single
space.

3. Decoding speed is much improved, especially when strong (possibly
non-JT9) signals are present and "Tol" is set to a relatively large
value.

4. Scaling of the "JT9 Sync" plot (red curve) is more reasonable.

5. Layout of widgets on the main window has been improved.

6. Several minor bug fixes.

November 14, 2012: v0.4, r2731

A number of known bugs have been fixed, and the JT9 decoder is
significantly improved. Among other improvements, the program is now
much less fussy about timing issues.

November 6, 2012: v0.3, r2717

Changes from r2713 include the following:

1. A bug in the decoder that led to erratic behavior (failed decodes)
under certain conditions has been corrected. Decoding is now much
more reliable.

2. A valid algorithm is now used to calculate S/N values for received
JT9 signals.

3. The header format of recorded *.wav files has been corrected.
These files will now play correctly in Windows programs that expect
the standard header.

November 6, 2012: v0.2, r2713

Changes from r2711 include the following:

1. Updates to the Quick-Start User's Guide,
http://www.physics.princeton.edu/pulsar/K1JT/WSJT-X_Users_Guide.pdf

2. Double-click on waterfall now sets Tol to a reduced
(mode-dependent) value.

3. Tol is saved and restored on program restart.

4. A "digital gain" slider was added next to the green-bar audio level
indicator. With the slider at mid-range, the scale reads correctly in
dB above the least significant bit of 16-bit audio data.

5. There is now a test that rejects at least one type of data that is
sufficiently corrupt to cause Eddie's best friend, the message
"15P6715P67WCV".

6. Several minor tweaks to improve decoder performance.

7. The program now starts with Monitor OFF. You must click Monitor to
start accepting audio. For some types of testing, this may be an
advantage. This startup condition may be changed again, in the
future.

October 31, 2012: v0.2, r2711

Three significant changes since r2706:

1. Three options are now provided on the "Decode" menu, controlling
the "depth" of the decoding process. For most purposes I suggest you
should use "Normal", but feel free to experiment with the others.

2. Decoding of multiple signals in one Rx interval has been improved.

3. Handling of strong signals has been improved.

October 309, 2012: v0.2, r2706

Changes since r2702 include the following:

1. The problem with "ghost" signals is fixed.

2. A problem causing very long decode times under certain
circumstances has been fixed. Please note: decode times on any recent
PC should no more than a few seconds!

3. I have re-directed the program's fatal error messages so they will
be sent to the command-prompt window from which you started the
program. Please send me full reports on any such messages you observe,
preferably with details on how to reproduce the problem.

#########################################################################

Some additional information ...

1. Yes, the JT9 modes require good stability in all system
oscillators. The present JT9 bdecoder does not attempt to track
frequency drifts. Such capability will be added, however. We have
been using digital modes for EME for nearly ten years now, at 144 MHz
and higher. There are more than 1000 WSJT users on EME, using all
kinds of rige. We have learned how to deal with reasonable rates of
drift. Surely if we can do these things at VHF, we can do them much
more easily at MF and LF.

2. If you're sure that you have seen degraded JT9 performance because
of frequency stability issues, don't just complain on the LF
reflector. Document your case and send me an example file with a
drifting JT9 signal. Making WSJT-X and JT9 better is partly YOUR
responsibility!

3. In other ways as well, test files are needed. I can make many
tests myself, but I can't foresee all the problems others will have.
That's what the "Save All" function is for! In these early tests,
always run with "Save All" checked, just in case you will want to
refer back to something that happened. You may want to send me the
file in question. You can always clean out your "Save" directory by
using "File | Delete all *.wav files in SaveDir". I need good
examples of signals that fail to decode for any unknown reason. Also
some good examples of atmospheric or other impulsive noise, for
testing the noise blanker.

4. I have added a page of "Hints for New Users" to the online WSJT-X
User's Guide,
http://www.physics.princeton.edu/pulsar/K1JT/WSJT-X_Users_Guide.pdf .
Please read it! ... and let me know if you find other operational
details of WSJT-X that need explanation. This will likely be
especially true for those not already familiar with older versions of
WSJT.

5. An operational suggestion: In many ways the different JT9 submodes
are treated as distinct modes. If you receive a JT9-x signal in a
different submode than the one you have selected, you won't decode
it. For this reason, if JT9 is to become popular we'll probably need
to choose one or two of the submodes for general use, and perhaps
assign a narrow slice of the band to each one. Note that "message
averaging" in the Rx software can make two or three JT9-2
transmissions as good as one JT9-5 transmission, with the advantage
that you will copy sooner if signals are better than required for
JT9-5. Message averaging is not yet present in the JT9 decoder... but
in future it can be. Again, we have dealt with such issues very
effectively on EME -- and can do so at MF/LF, for sure.

6. On the topic of CW, Beacons, WSPR, JT9, etc. I really don't
understand what all the fuss is about. Surely there is room for
everybody? Maybe I'm just too new here to understand? (Mal, is this
mostly just a matter of "Mal being Mal"???)

On the HF bands, the WSPR sub-band is just 200 Hz wide. If we did the
same on 630 m, the WSPR sub-band would take up less than 3% of the 7
kHz band. If that's too much, we could cut it in half, or even less,
and still have enough WSPR space. Moreover, a "slow WSPR", if
warranted, would require even less bandwidth. Similar comments apply
to JT9. The bandwidth of JT9 signals is significantly less than that
of CW, for comparable information rates. There should be enough
spectrum for both, even in our narrow MF and LF bands.

7. As for performance comparisons between JT9 and WSPR: WSPR is a
mature program, and its decoder has been optimized and tweaked over a
period approaching five years. You are playing with JT9 in infancy.
With help (as opposed to simple complaints) from users, it will
improve rapidly.

October 29, 2012: v0.2, r2702

Changes since version 0.1, r2696 include the following:

1. Sample rate for audio output has been changed from 12000 to 48000
Hz. Tx audio may now be generated at any frequency from 500 to 20000
Hz.

2. The Decoder now tries to decode all synchronizable signals in the
"green zone", that is, within "Tol" Hz of the selected QSO
frequency. (Before, by default it decoded only the signal producing
the highest "sync" value. Other signals could be decoded by manually
setting the QSO frequency and reducing Tol as needed.)

3. The user's selected QSO Frequency is now saved and restored on
program restart.

4. The problem with re-initialization after changing sub-modes has
been fixed.

5. The problem (for some users) of not releasing PTT after end of a
transmission has been fixed.

6. The program now writes a log of all decodes to a file wsjtx_rx.log
in the wsjtx directory.


October 25, 2012: v0.1, r2695

25 października 2012 data oficjalnej premiery modu JT9 i upublicznienie WSJTX (eksperymantalny WSJT)
Initial version of WSJT-X (experimental WSJT) released for testing.


  PRZEJDŹ NA FORUM