On 20/05/2021 2:45 am, n3ps via
I am currently
running the most current versions of WSJTX, JTAlert and HRD
I initially installed JT Alert to support QSO logging from WSJTX
to HRD Logbook (via the TCP/IP API). However, HRD Logbook
recently implemented support to allow QSOs to be logged directly
from WSJTX (via UDP Broadcast) without the need to use JTAlert as
I am trying to determine if I take advantage of the recently
implemented support to allow WSJTX to update HRD Logbook directly
(via UDP Broadcast), will I be loosing any other JT Alert
functionality that is mission critical to my FT4/FT8 operations
(e.g., Worked B4, Wanted Alerts, etc)?
Paul / N3PS
I wouldn't categorize the use of the WSJT-X "Secondary UDP Server
(depreciated)" by HRD to log QSOs as a recent implementation. That
has been happening for quite some time and has been the cause of
numerous duplicate logging complaints.
If you want to log QSOs directly into HRDLogbook without JTAlert
you will need to turn off HRD logging in JTAlert to avoid
duplicate log entries. Turning off logging in JTAlert has a number
- You loose the ability for accurate B4
reporting by JTAlert, especially if QSOs have been logged to
HRDLogbook while JTAlert has not been running. In that
situation JTAlert will never be aware of those new QSOs unless
you take steps to perform manual adif imports into the JTAlert
internal B4 database (which is used when logging is disabled).
- The ability to automate the JTAlert Alert
database rebuild with your needs for the many different Alert
types is lost completely and all Alerts will need to be
manually updated whenever you confirm entities via QSL card or
Lotw/Eqsl confirmations. Two of the Alert types, Grids &
Prefixes, cannot be manually updated and are only updated via
the rebuild process which involves scanning the logbook, which
cannot happen if logging is disabled.
- The logging of xml lookup data of your
QSO partner is lost with logging disabled.
- The ability to
pre-enter or modify QSO data prior to logging via the log
fields area of JTAlert is lost with logging disabled.
Honestly, I don't see much value in running
JTAlert with logging disabled which will need to happen if you
wish to log directly from WSJT-X to HRDLogbook.
I don't see any downside in letting JTAlert
perform the logging into HRD, except for one, HRDSupport have a
dislike for JTAlert and tend to point the finger at JTAlert when
a user tries to get a problem in HRD resolved. The mere mention
of JTAlert is enough for some in HRDSupport to dismiss the
complaint as a JTAlert issue without any attempt at resolution.
This has happened numerous times, despite the problem having
been clearly isolated to within the HRD suite. But that is not a
technical issue that should influence the decision to use
WSJT-x -> JTAlert -> HRDLogbook for logging.
de Laurie VK3AMA