locked Re: Potential For Lost JTAlert Functionality By Directly Updating HRD Logbook Via WSJTX ? #HRD


HamApps Support (VK3AMA)
 

On 20/05/2021 2:45 am, n3ps via groups.io wrote:
I am currently running the most current versions of WSJTX, JTAlert and HRD Logbook.

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 the middleman.

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

Paul,

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 of consequences.
  • 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

Join Support@HamApps.groups.io to automatically receive all group messages.