Move unversioned release notice texts into NEWS file

Merged from the wsjtx-1.5 branch.




git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@5329 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
This commit is contained in:
Bill Somerville 2015-05-01 19:05:31 +00:00
parent ec0c0786a9
commit 1deffffe7f
1 changed files with 249 additions and 0 deletions

249
NEWS
View File

@ -10,7 +10,256 @@
\$$ \$$ \$$$$$$ \$$$$$$ \$$ \$$ \$$
Copyright 2001 - 2015 by Joe Taylor, K1JT.
WSJT-X v1.5.0 Release Notice
============================
Decoder Performance Improvements
--------------------------------
The most notable change in v1.5.0 is improved speed and quality of the
JT9 and JT65 decoders. Algorithms have been fine-tuned, and advantage
is taken of the multiple CPUs found on most modern computers. Overall
speedup factors of three or more have been attained since the v1.4.0
release and more signals are being successfully decoded as well.
For those interested, here's a summary of speed tests of three
benchmark versions of WSJT-X, based on reading and decoding an
identical set of 10,682 *.wav files. The files were recorded on
various bands from 160 m to 10 m; the number of decodable JT65 signals
is typically about 5 times the number of JT9 signals. For each test
the program was set to "JT9+JT65" mode with "Deepest" selected on the
*Decode* menu. Other setup parameters were identical in all cases.
The test computer runs Windows 7 and has an Intel i5-2500 processor
with 4 CPUs.
Columns labeled "JT9" and "JT65" in the following table give the
number of decoded signals in each mode. Numbers in the "Time" column
are total processing time in seconds, and columns labaled "Factor"
give ratios of the corresponding numbers, relative to WSJT-X v1.3.
Program Version JT9 Factor JT65 Factor Time Factor
-------------------------------------------------------
v1.3 r3673 7691 1.000 40831 1.000 14061 1.00
v1.4.0 7693 1.000 41796 1.024 13320 1.06
v1.5.0-rc1 8024 1.043 43946 1.076 4224 3.32
On the benchmark computer the decoder in v1.5.0-rc1 is more than 3
times faster than the ones in program releases v1.3 r3673 and v1.4.0.
At the same time, the number of decoded signals has increased by as
much as 7.6%.
Users will notice another consequence of taking advantage of multiple
CPUs. JT65 and JT9 decodes in dual "JT9+JT65" mode are now done in
parallel, so decodes are delivered to the Rx activity window as they
are decoded rather than finishing the current mode before starting the
other mode. Decoding at the QSO frequency is still given priority,
but it may not be the first decode displayed because the first decodes
of the other mode may be produced more quickly. Dual mode decodes are
now interleaved in the Rx activity window.
UDP Broadcast
-------------
WSJT-X v1.5.0 introduces a new facility that broadcasts status, decode
and logged QSO information via the network. Although this facility
gives no obvious change to the application other than a few new
settings options, it should allow cooperating applications to interact
with WSJT-X far more smoothly than the current file based mechanism
which is prone to contention. The file access contention can be
detrimental to both WSJT-X and the cooperating application whereas the
new broadcast mechanism will not.
Currently the only only cooperating application we know of is JTAlertX
by Laurie VK3AMA and that currently uses the file based mechanism. We
hope that Laurie will try the new mechanism but we will continue to
provide the file based mechanism as well. We also know of at least one
other application in development for the Apple Mac platform to provide
similar features to JTAlertX. A contribution for Linux would also be
most welcome.
Rig Control
-----------
This continues to be an area of development. There are still many
untested combinations of equipment since we have to wait until a user
tries WSJT-X for the first time with each combination before we can be
sure that any defects have been removed. Hundreds of hours of testing
have been done and we thank those who have reported issues and offered
their time to test fixes where necessary.
FlexRadio & HPSDR Users
-----------------------
Currently the Hamlib library that we use for direct CAT control of
your rigs does not provide a fully functioning driver for these
radios. Instead the TS-2000 emulation mode of these SDRs must be used
as the Hamlib driver for this has tweaks added to cooperate correctly
with SDRs. Version v1.4 of WSJT-X did not work with these radios in
TS-2000 emulation mode and at the time we were not informed of that,
it appears to have become common knowledge that using the TS-480
emulation mode was the correct procedure, this is incorrect although
it did work at the time. The TS-480 emulation may cease to work in a
future version because it is due to a defect in Hamlib that it works
at all. The TS-2000 emulation mode is the correct selection and should
be used with these radios.
Generated Messages for Type 1 and Type 2 Compound Callsigns
-----------------------------------------------------------
This is a complex area because it requires special action by both
parties in a QSO since the automatically generated standard messages
are not always suitable. We have tried to improve the standard message
generation and recognition along with better recognition of own call
messages. As before it is imperative that operators take note of their
QSO partners responses and be prepared to manually edit replies when
communicating with compound callsign stations.
WSJT-X v1.4.0 Release Notice
============================
Migration of User Files
-----------------------
This release includes a new install mechanism that separates user
files from installation and program files. This means that going
forward upgrades will be seamless with user files preserved and
automatically carried forward without user intervention. For this
release only it is necessary to move your user files manually if you
wish to preserve them. The locations of user files have changed and
now vary depending on the installation platform. The following notes
are intended to guide you in moving your user files, this is a one
time action.
On Microsoft Windows:
The new location for user files is %LOCALAPPDATA% which is an
environment variable defined automatically by Windows, you may use the
environment variable any place where a file path would normally be
used e.g. in the location entry bar in Windows File Explorer or in
arguments to command line programs from a Command Prompt window.
On Linux and other Unix systems:
The new location for user files ~/.local/share
On Mac:
The new location for user files is ~/Library/Application\ Support
In all cases the files are stored in a subdirectory which by default
is WSJT-X
In the case of users who run multiple instances of WSJT-X on a single
computer there are different user file locations for each
instance. The non-default locations are in sibling subdirectories each
suffixed by the rig name argument passed to WSJT-X at startup (See
Running Multiple Instances below).
The user files that you may wish to migrate from older versions of
WSJT-X are:
ALL.TXT
CALL3.TXT
wsjtx.log
wsjtx_log.adi
The format of each of these files is unchanged in WSJT-X v1.4 so all
that is needed is to copy them to the new location.
For example on Microsoft Windows assuming a WSJT-X v1.3 installation
in C:\WSJT\wsjtx-1.3, using a command prompt window:
copy C:\WSJT\wsjtx-1.3\ALL.TXT %LOCALAPPDATA%\WSJT-X\
copy C:\WSJT\wsjtx-1.3\CALL3.TXT %LOCALAPPDATA%\WSJT-X\
copy C:\WSJT\wsjtx-1.3\wsjtx.log %LOCALAPPDATA%\WSJT-X\
copy C:\WSJT\wsjtx-1.3\wsjtx_log.adi %LOCALAPPDATA%\WSJT-X\
On Linux:
cp ~/wsjtx-1.3/ALL.TXT ~/.local/share/WSJT-X/
cp ~/wsjtx-1.3/CALL3.TXT ~/.local/share/WSJT-X/
cp ~/wsjtx-1.3/wsjtx.log ~/.local/share/WSJT-X/
cp ~/wsjtx-1.3/wsjtx_log.adi ~/.local/share/WSJT-X/
On Mac:
cp ~/wsjtx-1.3/ALL.TXT ~/Library/Application\ Support/WSJT-X/
cp ~/wsjtx-1.3/CALL3.TXT ~/Library/Application\ Support/WSJT-X/
cp ~/wsjtx-1.3/wsjtx.log ~/Library/Application\ Support/WSJT-X/
cp ~/wsjtx-1.3/wsjtx_log.adi ~/Library/Application\ Support/WSJT-X/
If you have a customized cty.dat file installed, then that too should
be copied to the new directory.
Settings
--------
WSJT-X v1.4 introduces a new settings regime. There is no facility to
migrate settings from prior versions and copying the wsjtx.ini
settings file to the new user files location will not carry over any
useful information. The new settings dialog is very different from
prior versions but it is intuitive and will not take long to configure
for you equipment and preferences.
Running Multiple Instances
--------------------------
For users with multiple radios or multi-receiver SDRs WSJT-X offers
multiple instance support. Prior to WSJT-X v1.4 this involved
installing the application multiple times in separate locations, this
is no longer necessary and multiple instances MUST be run from a
single installation. This is possible as user and other writable data
files are stored in a unique location for each instance.
WSJT-X has a new command line option that coordinates multiple
instances called --rig-name (-r for short) which allow you to specify
a unique key for each instance. If no --rig-name option is supplied a
default location is used for writable files as specified in the
Migrating of User Files section above. If a key is provided then the
same key must be used every time that instance is started so as to
associate it with the correct data files.
If the unique key were ft-857 then you must start WSJT-X using that
key e.g.
wsjtx --rig-name=ft-857
and the data files will be stored in a directory "WSJT-X - ft-857" for
example on Windows:
"%LOCALAPPDATA%\WSJT-X - ft-857\"
Multiple instance support may also be used if more than one operator
uses the same computer with their own call signs, or a single operator
who operates in multiple locations with different call signs or
wishing to maintain separate log files for each location.
Known Issues
------------
Editing station details in the frequencies tab of the settings window
may not save the changes to the settings file. Updates will show in
the settings tables until application exit but may not be used by the
application. A workaround is available, delete the whole row and
re-enter the details rather than editing individual fields. This
defect is resolved in the next release (v1.5).
WSJT-X ChangeLog
------------------------------------------------------------------
October 7, 2013: Version 1.2.1, r3590