Installers randomly running the setup of an unrelated program is not common, but common enough that I have seen it several times over the years. A common cause is a Temp directory that is long-overdue

Bill, I would not classify this as misuse. The option was provided (many years ago) after numerous requests for such since JTAlert was automatically logging the Distance. Since there is no adif standa

Paul, JTAlert Settings window, Logging section, scroll the options down until you see the "Log bearing (heading) to ANT_AZ field" checkbox then enable it. The value logged is the value JTAlert used to

My 2cents, also consider excluding the DXKeeper & SpotCollector databases (directories and files) from AV real-time scanning. These database files get hit with lots of reads/writes and some AV softwar

Also, the OP mentioned JTDX which can be a real CPU hog if it hasn't been configured correctly. JTDX has an extended set of decoding options (compared to WSJT-X) in an effort to pull out more weak dec

Are you sure their local spots and not spots entering SC from the Cluster? de Laurie VK3AMA

Turn off DXKeeper logging in JTDX. de Laurie VK3AMA

Paul, JTAlert SpotCollector spots are only local, they never leave SpotCollector, that is they never reach the DX Cluster for the world to see. SpotCollector spots are useful for those who may have JT

OK, so the SRX_STRING & STX_STRING are not utilised by DXKeeper even though they contain the RX# and TX# data need by the Contest (assuming the user has recorded correct format data). Why are they inc

JTAlert is not a Contest Logger. It simply acts as logging bridge between WSJT-X and DXKeeper. There are no attempts to validate the Contest exchange based on different Contest rules or extract data f

There are no official mirrors for JTAlert. HamApps.com is rendering promptly and downloads are working fine. Maybe an issue with your ISP? de Laurie VK3AMA

Yes, I'm sure. DXKeeper doesn't need to be in Contest mode. If your tests were last month, than likely, you were using a version of JTAlert that didn't support logging of WSJT-X contest exchanges, as

Easy, JTAlert (since 2.12.8) logs WSJT-X 2.0.0 contest exchanges to DXKeeper. The exchange data SRX_STRING & STX_STRING are recorded in the "rx info" and "tx info" fields of DXKeeper. de Laurie VK3AMA

Simple, If you want to clear the DXKeeper Filter after logging a QSO, clear the DX Call in WSJT-X. While ever there is a DX Call shown in WSJT-X JTAlert will instruct DXKeeper to filter its display. d

You need to set JTAlert to send the appropriate lookup command to DXView when the WSJT-X DX Call field is changed/updated. JTAlert Settings window -> "Applications -> DXLab Suite" section. de Laurie V

Short answer, you can't. JTAlert doesn't populate the DXKeeper capture window. Use the JTAlert Log Field entry area to make any user changes and/or to auto-populate from an enabled XML service lookup.

Incorrect. JTAlert does log propagations data (SFI, A & K index), but you need to enable that option as it is off by default. See the Logging section of the JTAlert Settings window for the option. de

Also worth checking is if JTAlert is configured to generate local SC spots of WSJT-X activity. The spot rate is likely very high especially if WSJT-X is monitoring high-use bands like 20m & 40m. I saw

Classic GIGO. Garbage In, Garbage Out From https://www.techopedia.com/definition/3801/garbage-in-garbage-out-gigo The root cause of this is the grossly inaccurate Grid recorded in the QRZ.com xml data

That is to be expected, if your log contained VP6D QSOs without a Grid, and no grid was received from WSJT-X, JTAlert would have used the only source for the grid, the XML lookup. There was no need to