mirror of
https://github.com/saitohirga/WSJT-X.git
synced 2024-11-21 19:55:20 -05:00
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:
parent
ec0c0786a9
commit
1deffffe7f
249
NEWS
249
NEWS
@ -10,6 +10,255 @@
|
||||
\$$ \$$ \$$$$$$ \$$$$$$ \$$ \$$ \$$
|
||||
|
||||
|
||||
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
|
||||
------------------------------------------------------------------
|
||||
|
Loading…
Reference in New Issue
Block a user