Updated ways to implement a user defined hardware controller which is
executed just after band changes during WSPR band hopping operation.
Allows the user_hardware executable to be located in any directory on
the PATH environment variable. On Windows any file extension listed on
the PATHEXT environment variable may be used, the first match using
PATH and PATHEXT will be executed. On Windows this is achieved by
using CMD.EXE with a '/C' command line flag, i.e. the user's hardware
controller is executed like this:
CMD.EXE /C user_hardware nn
where 'nn' is the new band as an integer in meters.
On non-Windows systems the user's executable will be run if it is
found on the directories specified by the PATH environment variable,
and it is executable, i.e. it is equivalent to something like:
/bin/sh -c user_hardware nn
where 'nn' is the new band as an integer in meters.
In all cases the user_hardware controller should exit with a zero
status, otherwise it have been deemed to have failed. On Windows avoid
an exit status of one as that is utilized by CMD.EXE to indicate the
file was not found, which WSJT-X ignores silently.
This change means the prior need to put the user's hardware controller
into a WSJT-X installation directory like /usr/local/bin or
C:\WSJT\wsjtx\bin is no longer necessary.
When passing the 'Highlight last' parameter as true occasional matches
in prior periods could be incorrectly highlighted. This fix should
also improve performance when there is a large decode history, and
highlight request for a new callsign is received.
Using a Highlight Callsign UDP message with `Highlight last` false and
specifying both f/g and b/g colours as invalid now resets the
highlighting on any matching callsign, as well as removing the decode
highlighting internal record.
These go wrong too easily with l10n, this ensures the right menu
actions are treated specially on macOS and moved to their "normal"
place on the global system menu.
The Highlight Callsign (13) UDP message now operates in a slightly
different way. The "Highlight last" field, when true valued, causes
all instances of the specified callsign to be highlighted in the
decoding period. This allows external applications to highlight DX
callsigns even when multiple stations are calling them. Before this
was unlikely to work since the external application would have to
respond to Decode (2) UDP messages exceedingly quickly to guarantee
successful highlighting before another decode with the same DX call
was printed. There should be no changes required to external
applications acting as servers to the WSJT-X UDP Message Protocol,
although using the version of the Highlight Callsign (13) with
"Highlight last" should not be required for adhoc callsign
highlighting. It should be reserved for commonly recurring targets and
limited to no more than 100 active highlighting requests at any one
time, otherwise there may be performance impacts on WSJT-X.
This could make help text windows bigger than the screen, if we want
to go there then using a QLabel sub-class will need to change,
probably by using a read-only QTextEdit instead as that provides
scroll bars. Maybe consider a multi-column table for the contents as
an alternative to scroll bars.
The wsjtx process creates control files .start, .stop, or .quit and
the jt9 process deletes them. This is intended to avoid any race
conditions that get the processes out of sync.
On the Fortran side:
- For the nzhsym=41 activation, bail out if m_ihsym reaches 45
- For the nzhsym=47 activation, bail out if m_ihsym reaches 48
- Change the format and content of what's written to fort.71
- Change msdelay from 10 to 1
In mainwindow.cpp:
- change format and content of what's written to qDebug
- always start FT8 decoder at m_ihsym = 41, 47, and 50
- don't start function decode() is decoder is already busy
- send updated m_ihsym to jt9[.exe] via ss(1,1). Bill won't like this!
- jt9 bails out of the 41-buffer pass at m_ihsym=45.
Hashtable entries now include the 4-digit grid obtained from the most
recent Fano decode of the callsign. The stored grid is used to validate
OSD decodes. OSD decodes of type 1 messages are accepted only if the
callsign is present in the hashtable and if the grid matches the grid
stored in the hashtable.
the decoders. Also, an experimental change to the FT4 decoder to base
AP decoding passes on 4-symbol block detection instead of single symbol
detection. This provides about 1 dB improvement on the AWGN channel.
Sensitivity changes on other channels are TBD.
The current frequency, mode and, call were incorrectly being used to
create a new worked before record from a logged QSO. This meant that
band changes etc. made before clicking "Ok" to log a QSO would be
erroneously attributed to the worked before records.
The Status(1) message acquires the new fields Frequency Tolerance, T/R
Period, and Configuration Name. The Rx DF, Tx DF fields become
unsigned (this should be a benign change which is just for correctness
as -ve values have never been possible).
The Close(6) message becomes bi-directional allowing external
applications to gracefully close down WSJT-X instances.
A new message SwitchConfiguration(14) is provided that allows an
external application to switch the current configuration of a WSJT-X
instance.
Another new message Configure(15) is provided to allow external
applications to adjust some key parameters like the mode and submode.
See the NetworkMessages.hpp header commentary for full details. The
UDPExamples/MessageAggregator reference application has been updated
to be able to exercise all of the above changes.
Note that this commit enforces stricter checking on the
"Settings->Reporting->Allow UDP requests" option, which must be
checked before any state changing incoming messages to a WSJT-X
instance are processed.
This change may break N1MM Logger+ integration, notably the CLASS ADIF
field is populated which may not be recognized by N1MM Logger+, nor
interfaces to it.
One exception to ADIF conformance is that the ARRL_SECT field may be
populated with the value DX despite it not being a valid ARRL_SECT
enumeration value. This is done for consistency with N1MM Logger+ ADIF
exports.
The Status(1) message also acquires the current configuration name as
a new field. See NetworkMessage.hpp for details. The UDP reference
example program message_aggregator acquires the ability to display and
change the configuration of a WSJT-X client to exercise these new
features.
Re-enabling the WSJT-X i18n facilities. This allows translation files
to be created for languages that are automatically used to lookup
translatable strings. To enable a new language the language name must
be added to the CMakeLists.txt LANGUAGES list variable in BCP47 format
(i.e. en_US, en_GB, pt_PT, ...). Do one build with the CMake option
UPDATE_TRANSLATIONS enabled (do not leave it enabled as there is a
danger of loosing existing translated texts), that will create a fresh
translations/wsjtx_<lang>.ts file which should be immediately checked
in with the CMakeLists.txt change. The .ts should then be updated by
the translator using the Qt Linguist tool to add translations. Check
in the updated .ts file to complete the initial translation process
for that language.
To aid translators their WIP .ts file may be tested by releasing
(using the lrelease tool or from the Linguist menu) a .qm file and
placing that .qm file in the current directory before starting
WSJT-X. The translations will be used if the system locale matches the
file name. If the system locale does not match the file name; the
language may be overridden by setting the LANG environment variable.
For example if a wsjtx_pt_PT.qm file is in the current directory
WSJT-X will use it for translation lookups, regardless of the current
system locale setting, if the LANG variable is set to pt_PT or pt-PT.
On MS Windows from a command prompt:
set LANG=pt_PT
C:\WSJT\wsjtx\bin\wsjtx
elsewhere:
LANG=pt_PT wsjtx
changes on the C++ side. Basically works except that Tx audio has
incorrect DT and audio is truncated at the end. Also, command line
decoding using JT9 is not as sensitive as decoding from within WSJT-X.
Where tool tips are defined in rich text, equivalent pain test
accessible descriptions have been added so that screen readers do not
announce HTML tags.
Refactored date time delegates to use a simpler default editor via a
default item editor factory for QDateTime values, the editor is a
standard QDateTimeEdit with a format that includes seconds and renders
assuming the time is UTC.
Modified the Cabrillo log and Fox log database table models to provide
QDateTime items for the edit role of date time fields, and formated
date time strings including seconds and assumed as UTC for the display
role.
