On 26/02/2021 16:48, Dave Slotter, W3DJS wrote:
Fellow hams and users of WSJT-X:
I am pleased to announce the creation and immediate availability of a
Python script to address some of the deficiencies of WSJT-X not
providing a method to automatically look up callsigns and missing grid
squares and fill them in.
This Python script has been successfully tested with Python3 and a
Raspberry Pi, although may easily be used on other Linux systems with
Python3. It has not been tested with Mac, but should probably work
there as well. It has not been tested under Windows.
The script has passed scrutiny by Pylint and Flake8.
*Prerequisites*: Requests and Watchdog Python libraries.
*Environment variables*: QRZ_USERNAME and QRZ_PASSWORD to be filled in
with your authentication tokens from QRZ.
Additional backends such as HamQTH may be added in the future if there
is demand.
*To use:* download the script, set the QRZ_USERNAME and QRZ_PASSWORD
environment variables and start up WSJT-X and the script. It will run
automatically.
CAUTION: do not independently edit the wsjtx_log.adi while this script
is running, or bad things will happen. This script only works when
WSJT-X is appending its ADIF log file with new entries, nothing else.
The Python script, update_wsjtx_log.py may be located and downloaded
from here:
https://github.com/dslotter/ham_radio_scripts/blob/main/update_wsjtx_log.py
<https://github.com/dslotter/ham_radio_scripts/blob/main/update_wsjtx_log.py>
--
Dave Slotter, W3DJS <https://www.qrz.com/db/W3DJS>
Hi Dave,
I have some concerns about this proposal. If I understand correctly you
intend to automatically update the WSJT-X ADIF log file with information
not passed on air, for example grid squares obtained from online call
book sources. Currently the information in the WSJT-X ADIF log file
comes from one of two sources, firstly information passed on air during
a QSO, and secondly information directly entered by the operator when
making or logging QSOs. For the operator, both of these sources are
first class information. My main concern is that WSJT-X worked before
information for grid-squares is determined from QSO records in the
WSJT-X ADIF log file, augmenting that record automatically with
information that can be inaccurate or out of date seems unwise.
Note I am aware that some users choose to replace their WSJT-X ADIF log
file with an export from their main station logging applications, and as
every competent logging application I have looked at already has call
book lookup functionality which is more or less automatic; so the same
issue can occur, but at least the user is knowingly replacing the log
data recorded by WSJT-X.
I think most WSJT-X users understand the way that WSJT-X records
information received on air plus extra data that may be added manually
during the QSO or in the Log QSO dialog window. I can see your
application leading to confusion about the source and accuracy of data
that may be considered "mission critical" for some users.
A second concern is your statement that you wish to place a constraint
of the use of the WSJT-X ADIF log file. That file is not yours to make
such constraints and your requirements are already not met. WSJT-X will
re-read the WSJT-X ADIF log file in the background after starting the
application, when, or soon after, the "Settings->Colors->Rescan ADIF
log" button is pressed, and when switching configurations. OK, none of
these processes change the content of the file, but locks will be
applied that may interfere with other applications attempting to write
to the file.
Perhaps it would be better if your application steered clear of the
WSJT-X ADIF log file altogether, instead taking the feed via UDP of
logged QSOs, either as ADIF records or as broken down fields (messages
12 or 5 respectively), and either offered a feed for other applications
with augmented QSO information, or an augmented ADIF log file or other
database format. Such an approach would avoid the ambiguity of
information stored in the WSJT-X ADIF log file discussed above, and
would have other benefits such as not needing to be run on the same host
as WSJT-X instances.
73
Bill
G4WJS.
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel