JTAlert doesn't restrict spotting of specific bands. There is no facility for that in the code. Heck, it will even correctly spot bands for which there is no direct JTAlert alerting support, like 70cm

I meant multiple configs. JTAlert has no concept of Rigs or Rig control, that is the job of WSJT-X. JTAlert is simply monitoring the UDP traffic from WSJT-X, it doesn't need to know what rig was invol

Greg, Unfortunately, JTAlert does not support multiple configs per Callsign. The Config used is explicitly linked to the Callsign and the auto-start entries are stored in the Callsign specific config.

WSJT-X not responding to the Callsign clicks in JTAlert is a very common problem, more so in recent months. It is caused by not having WSJT-X setup correctly. Specifically, you don't have the "Accept

Pretty much that's it. The offline installer will have all the components for the framework installation avoiding going online when it comes time to install the framework. In my experience, the Web in

Another benefit of Logging direct to HRDLogbook from JTAlert, any QSOs that are logged when JTAlert/WSJT-X is not being used, say your RTTY, PSK, SSB & CW QSOs, will still be available to JTAlert when

#HRD

This should be easy to solve since there is only one log record involved. Check the QSO (that you believe is the MA record) in ACLog and check that is does indeed have MA set as the State for the 40m/

Ron, Your best option is to enable HRD logging in JTAlert. This avoids the QSO forwarding mechanism and has several benefits. You get full access to the alerting facilities and B4 reporting of JTAlert

#HRD

Tnx Chris. An ADIF parser that depends on field order (when the adif spec has no such requirement) is crazy. What did they get a first year student programmer to write the code? Treating an adif recor

#HRD

Ron, I see nothing wrong with that ADIF record you captured. The QSO_DATE is set and is of the correct format. I can't explain why HRD is not accepting the <QSO_DATE> field. Is all other data being lo

#HRD

Jim, I note that up until 2 hours ago your copy of JTAlert was happily sending 30m spots to HamSpots. A good 3+ hours after your post to the group. Can I assume that your problems have been resolved?

What version of JTAlert? Has this version previously behaved correctly? Is there an error message? Does JTAlert begin to start then close or does it never appear? What Windows version? If its WIn10 ha

Still sounds to me like Protection software interference. Not all Protection software behaves as you expect, often disabling the software simple turns off real-time scanning but other functions remain

Jerry, The WSJT-X update to rc3 should have no effect. If JTAlert is not presenting an error window, than it is unlikely it is closing due to a code failure, more likely it is being deliberately close

A fix is hard to suggest as you have provided minimal data about your operating environment. What are your PC specs, number of CPU cores, CPU speed, installed Ram, Windows version? It is very unlikely

Customizing the Ranges (by the user) will be available in the future, but not any-time soon. Sorry. For the next public release of JTAlert I have altered the range values to account for this significa

JTAlert will only consider deleted entries from your Log during the Rebuild process if the "Crystal Ball" plugin is installed and enabled ;) Seriously, the "Rebuild Alert Database" is just that a "Reb

What does JTAlert show in the titlebar? Is it displaying the current Band or just "???m"? If the later that indicates that JTAlert is not receiving and UDP data from JTDX. JTAlert has no concept of Ri

#JTDX #HRD

RRR. "DX" is never explicitly displayed like a State or Province. There is however a directed CQ indicator (see the Alerts -> CQ section of the Settings) that can be displayed, "#" versus the "*" for

While more memory is always good, CPU usage is the most critical. What is taskmanager telling you when WSJT-X is busy processing decodes at the end of a period? What CPU usage is it indicating? If you