Hi Dave,
comments in line below.
On 05/12/2020 15:37, Dave Slotter, W3DJS wrote:
Hi Bill,
Thank you for such a detailed and thoughtful response.
Understood that QRZ XML API is a paid service. And yes, there are free
services like HamQTH.com XML API.
Three questions come to mind:
a) What do you mean by "We also allow users to substitute an augmented
ADIF log file"?
WSJT-X keeps its main logged QSO information in an ADIF format file.
There's nothing to stop users replacing that file with one augmented
with QSOs in other modes, e.g. they might be interested in working new
DXCC Entities that they have not worked in any other mode. WSJT-X even
offers a push-button that causes the ADIF log file to be rescanned, to
populate the in-memory indexes of worked before information, without
having to pause normal WSJT-X operation.
b) I re-familiarized myself with the User Guide, section 11. Logging
and did not see an answer to this question: To what purpose is an
empty name field provided in the WSJT-X Logging dialog?
The Name field on the Log QSO dialog it there for the user to insert
information that may be gathered at the time of the QSO, similarly the
propagation mode was recently added. The Name field value, if present,
populates the NAME field of the ADIF QSO record. That same information
is published via the WSJT-X UDP Message Protocol "QSO Logged"(5) message
and in the "Logged ADIF"(12) message. By this means interoperating
station logging applications, or bridge applications to them, can pick
up the entered information.
c) Understanding that you are concerned with (among other things)
feature creep in the core application, would you be willing for a
compromise here? Rather than add that functionality into the main
application, would you be open to an implementation of a plugin
interface to allow third-party developers to add optional
functionality for inserting the name field? That way you do not have
feature creep in the main application, and users can decide for
themselves whether or not to enhance their experience with WSJT-X.
Currently WSJT-X has no use for a QSO partner name field in its ADIF log
file, even though it has the capability to enter that field when logging
a QSO, as I explain above. I assume you envisage WSJT-X scanning
previous logged QSOs to redisplay the last name recorded, if any, in the
log QSO dialog, or perhaps elsewhere in the UI during QSOs, or even
against decoded messages. Each of those options requires a greater
degree of processing and data management, but I don't see any real gain
for users when the vast majority of QSOs made with WSJT-X do not
exchange such niceties as an operator name.
It seems to me that an application could be developed to subscribe to
the WSJT-X UDP Message Protocol and augment Logged QSO messages along
the lines you suggest. Such an application could then itself offer a
service of augmented logged QSO records. Such an application need not
have any interaction with WSJT-X other than subscribing to the UDP
datagrams that are already available. Note that this is something that
JTAlert and probably other station logging applications already do.
Thank you for your consideration.
--
Dave Slotter, W3DJS <https://www.qrz.com/db/W3DJS>
73
Bill
G4WJS.
On Sat, Dec 5, 2020 at 8:24 AM Bill Somerville <[email protected]
<mailto:[email protected]>> wrote:
On 03/12/2020 14:25, Dave Slotter, W3DJS wrote:
Bill and Joe:
If I were to develop an integration with QRZ to automatically
look up the full names of people associated with a callsign
that's getting logged and populate the name field in the log
window, would you be receptive to receiving and incorporating
said patch?
Please advise, and thank you.
--
Dave Slotter, W3DJS <https://www.qrz.com/db/W3DJS>
Hi Dave,
thanks for offering to develop such a facility, but personally I
feel this is out of scope for WSJT-X. In general WSJT-X is a
*source* of information gathered on the air, up to and including
logging QSOs. There are data feeds consumed by WSJT-X, but not
many and none with any real-time demand. We optionally take a list
of known users of the ARRL LoTW service so that decodes of CQ
calls from users can be highlighted. This is considered by many to
to be valuable information when selecting who to work because it
may reflect the likelihood of getting a QSO confirmed for award
purposes. We also allow users to substitute an augmented ADIF log
file, perhaps from a main station logging application, that also
allows WSJT-X to highlight potentially more valuable QSO partners
with respect to the user's DXing goals. Adding further data feeds,
particularly when the information acquired is available from many
sources and hence subject to ambiguity, is not a high priority.
Furthermore once these sort of more arbitrary information inputs
are considered as worth implementing, then there are many more
that might have perceived equal or greater merit to some user
subsets. That could lead to WSJT-X mission creep into the domain
of main station logging applications, which to a greater or lesser
extent already do these functions well as part of their core
capabilities.
I note also that the QRZ.COM <http://QRZ.COM> XML data feed is not
a free service and therefore may not be required by many users who
do not think this sort of information is worth the price. There
will surely be others that request the same information from free
to use sources like the Hamcall service, or perhaps from one of
the variety of paid call-book services that they may already be
subscribing to. The scope of such a facility will quickly grow far
beyond what you propose, with an associated ongoing maintenance
and support burden that may detract from the core purpose of a
weak signal communications tool.
73
Bill
G4WJS.
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
