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

Reply via email to