locked Version 2.50.0 request

John C

Laurie, a request...   the little grey dot that appears in the top right corner to indicate "Online for text message"...   could it be made larger please, currently, it is quite hard to see.


Other than that, I really like the new version




locked Re: 2.5.0 -- AutoIt Error

WarrenG KC0GU

I am running JTAlert 2.50.0, WSJT-x v2.3.0, HRD Logbook V6.7.0.323 and having no issues with logging.  I do not use the MS Access DB, as Laurie has pointed out it is problematic, especially when HRD does updates.  I use the Maria SQL database, it appears to be more stable and faster with HRD.

You can contact me off group, I'm good in QRZ.

locked JTAlert and HRD Logbook #HRD

Ben Goldfarb

Having read an earlier post from Laurie about potential issues with HRD's Access DBs, I resolved my problems with JTAlert 2.5.0 by simply converting my HRD log to MySQL.

After an initial failure with 2.5.0, I had reverted to 2.16.17. Once I converted the HRD log database to MySQL, the long standing problem of JTAlert crashing after settings were applied disappeared, which inspired me to try the 2.5.0 install again. Bingo! The issues with JTAlert 2.5.0 went away.

And so, I am a very happy camper. Kudos to Laurie, who added everything I had hoped for and then some! Excellent product and a great service to the digital ham community. Thank you very much!

73 de Ben AE4NT

locked Re: Slow ADIF import - Confirmed

HamApps Support (VK3AMA)

On 14/04/2021 1:35 am, John Holmes W9ILY wrote:

As you may recall my ADI fie is over 85 MB for over 249,000 records and the load time took over 116,000 ms to complete. Can this be improved? Thanks for all of your latest enhancements!


John W9ILY


I can confirm this abnormal behavior.

The adif import code of 2.50.0 is an exact copy of the old 2.16.17 import code. The only difference is the underlying .NET runtime used.

After much head scratching and tests it was tracked down to the code used for locating the position of an adif tag within an adif record. I don't use regex for this has proved even slower when processing thousands of records in a tight loop.

I don't have an explanation as to why the new NET5 runtime version of the inbuilt command is so much slower than the old NET4.7.2 Framework version.

Results for a 183K record adif...
  •  JTAlert 2.16.17      : Elapsed time ~16.3 secs (~11.2k records per sec)
  •  JTAlert 2.50.0       : Elapsed time ~70.7 secs (~2.5K records per sec)
  •  JTAlert 2.50.0 fixed : Elapsed time ~7.0 secs  (~26K records per sec)

I'll send you a new build to test later today.

de Laurie VK3AMA
JTAlert 2.16.17

JTAlert 2.50.0

Fixed JTAlert 2.50.0

locked Re: 2.5.0 -- AutoIt Error

David - AK2L

I believe it is MSAccess as I have never attempted to switch to another database.  If others are using HRD without trouble, then I will try your solution.

For now, I have changed the logging so that WSJT-X sends the QSO to HRD Logbook.  JTAlert is set to use an ADIF file.  Every few days, I will export an ADI from HRD and have JTAlert scan that for alert updates.

Note: I did try to have JTAlert send (UDP) the QSO to HRD, but HRD was not picking up the submode from a MFSK/FT4 QSO whereas it picked it up from WSJT-X just fine.  Bug perhaps?  Settings error on my part?

In any case, the logging issue is a small inconvenience and I love all the improvements in JTAlert.

Thanks for the great program.

locked Re: JTAlert 2.50.0 Upgrade help needed

Bill Rogers

Thanks for the reply! This is a well thought out application. 

I was able to downgrade to 2.16.17 which was smooth. I will take another crack at the upgrade soon. I am pretty sure I downloaded and installed the updated .NET for the right OS but maybe I missed something.

73 es thanks,
Bill K2TER 

On Apr 13, 2021, at 2:36 PM, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:

On 14/04/2021 1:10 am, Bill Rogers wrote:
I upgraded JTAlert to 2.50.0 from 2.16.10 (I think) for use with WSJT-X.  After the install the Callsign Window and others like "About" don't come up when selected. I am also getting an Unable to communicate with the WSJT-X process: UDP Port 2237 IP Address 

I did not modify my setup after the installation and it appears WSJT-X is still set up to use port 2237.

Is there a remedy or something to try?

Is there a way to go back to the older version safely?

Bill K2TER

All those symptoms indicate that the JTAlertV2.Manager.exe process is not running.

That process requires the .NET 5 Desktop Runtime to be installed. Make sure it is installed and of the correct architecture  (32bit or 64bit), The Runtime needs to match your Windows architecture.

If your running Windows 64bit install the X64 runtime, if 32bit install the X86 runtime.

de Laurie VK3AMA

locked Can't find call sign window


I did the install for the new JTAlert and all was good. I turned off everything and when I restarted I can no longer see the call sign window. I've checked behind all the other open window. No luck. I also now notice a red icon with JT Manager running as well. Any thoughts on where to start with this?
Brad, KF0CUD

locked Transmit frequency

Ernie Barnhart


Thank you for all that you do!

Using JTAlert v2.50.0, with Callsigns Window set for single click using ctrl-click does not change transmit frequency to receive frequency as I thought previous versions did. Comment?

I do like the new version with separate windows, and all the flexibility!

Ernie, N8DVE

locked 2nd instance Callsign window not following JTAlert main window on minimize

Gary Yarbrough, KE5TD

From the settings window in the Callsign window I have ticked the box for the Callsign window to follow the JTAlert main window and it works on the 1st instance.  On the 2nd instance I also ticked the box  but the Callsign window does not minimize when I minimize the JTAlert main window. Anyone else having this issue ?

Gary / KE5TD
Flex 6500
Win 10 Pro
AMD ryzen 7 16GB

locked the .NET 5 Desktop Runtime 64bit (x64)

Russ - KA1ERL

When I try to install the above, I receive and error 0x80070570.
How do I fix this error.  I scanned my drive and no file errors.
Thank you.

locked Re: 2.50 Like It - NET 5 - QSLpath indicators

Willi Passmann

Am 13.04.2021 um 03:43 schrieb HamApps Support (VK3AMA):
On 13/04/2021 11:32 am, James F. Boehner, MD via wrote:

My last computer on Windows 7 is my FT8 computer.  Fortunately, the 64-bit 5.0.5 framework loaded without a hitch.  I do not have the paid updates (I didn’t know they existed).  My Windows version is 6.1.7601 Service Pack 1.

’73 de JIM N2ZZ

Good to hear. I suspect however, that eventually, the .NET 5 runtime will have issues with Win7 SP1 per the Microsoft announcement. Likely the intention is that Win7 will not be supported without the ESU, but the underlying code has not reached that point or they simply forgot to enable a switch. Only time will tell.

de Laurie VK3AMA

I can also confirm that the .NET 5 runtime and JTAlert 2.50 are running fine with my Win7 Prof. SP1, without paid updates.

I like the new version, for example the indication of the desired continent for directed calls is very informative, much better than the solution used in 2.16.
I wonder if the triangles for EQSL and LotW could also replaced by one letter (E / L) in the according corners in the entries of the callsign window? Then one would not have to remember which corner stands for which QSL route.

vy 73,
Willi, DJ6JZ

locked Re: km vs miles

Fred Roberts

      Bingo! That was it! Thank you and yes, you are correct, it was the Callsigns window.  This new version is superb. Thank you for the  hard work that went into it, and the very thorough Beta testing that it went through before release.

Sent from my phone.....Fred

On Tue, Apr 13, 2021, 2:43 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
On 14/04/2021 2:35 am, Fred Roberts wrote:
I've spent the last 30 minutes trying to find the setting to change km to miles when I hover over a station in the decodes window. 
I have 'display distance in miles' checked in WSJT-x 2.2.2.
I must be blind because I can't find the option in JTalert.

Fred, I think your mean the "Callsigns" window, not the "Decodes" window. They are two different beasts. See the titlebar.

Most of what gets displayed in the new Callsigns window is coming from the old JTAlert, it is still performing the Alerting checks on the incoming decodes. Have a look ate the "Settings -> Decoded Callsign Data Tooltip" menu of the main JTAlert (the old JTAlert) window.


de Laurie VK3AMA

locked JTAlert 2.50.0 is a hybrid application. An explanation.

HamApps Support (VK3AMA)

I have noted some complaint about the location of some settings not being found in the new 2.50.0 introduced windows because they still exist within the old JTAlert Settings window or vise-versa.

While JTAlert 2.50.0 is a significant new release, it still contains much of the old JTAlert code, specifically involving the Alerting and Logging operations.

2.50.0 is a hybrid of the old AutoIT slow single-threaded code, the V2 series, and the new C# modern multi-threaded object oriented code of JTAlertV3. JTAlertV3 was taking forever to complete and release, so I decided to bring some of the already coded V3 components into the V2 code-base. Thus was born 2.50.0.

Due to this hybridization effort of V2 code with V3 code there is some functionality that still lives in the V2 code and as such their associated settings are still within the old V2 Settings window.

With 2.50.0 you gain the benefits of the much faster code and user friendly UI enhancements that are V3 based.

All future changes and enhancements to JTAlert will be coming from the V3 code-base.

de Laurie VK3AMA

locked Re: JTAlert Will Not Install

Ed Wilson


Yes, I have installed the .NET update as suggested on your website. I seem to recall that there is a way of checking to see that it was installed properly, but I must have deleted the post where that information was given. Would you kindly let me know how to verify that the .NET update was actually installed?


Ed, K0KC

locked Re: dB vs Grid?

Joe Subich, W4TV

That would require a change in WSJTX.


... Joe, W4TV

On 2021-04-13 12:27 PM, Glenn Jensen wrote:
I too like the new version – would be ideal to ‘sort’ by db….
Hey, version 2.6 …
Good stuff – Kudos – 73’s Glenn
From: <> On Behalf Of Bill - AA4M
Sent: Tuesday, April 13, 2021 8:55 AM
Subject: [HamApps] dB vs Grid?
I just downloaded 2.50.0 and spent about 2 hours working with it. All I can say is FLAWLESS, WOW!
I did have one request for an enhancement. Anybody who's ever worked DX knows that they often start a QSO with the dB report rather than a grid. I like this, especially in marginal conditions. What I'd like to see in JTAlert is an option to make my response to a CQ or tailgate (by double clicking in the callsign window) begin with my sending dB rather than grid location. Can such a feature ever be implemented?
Thanks for the great software Laurie!
73, Bill AA4M

locked Re: Callsign window in V2.50 opens independently from applications scheduled to open when starting

HamApps Support (VK3AMA)

On 14/04/2021 1:05 am, WU9D wrote:
That being said, the callsign window opens BEFORE any applications I have specified to open FIRST. The callsign window needs to open AFTER any applications specified, just like the JT Alert main window.

That is not the case. The Callsigns window is directly controlled by the JTAlert process. If JTAlert is not started, the Callsigns window will not start. It is impossible to open the Callsigns window without starting JTAlert first.

Regardless of how quickly the Callsigns window is displayed, it will not display and decoded/alerted Callsigns until the main JTAlert process has finished its start-up and established comms with WSJT-X.

What is the problem with the Callsigns window showing early, it still takes up the same amount of screen-space and in the same location as when it was last used. I honestly don't understand the complaint, unless I am missing something in your message.

What is the issue with the window showing a second or two early? Please explain.

de Laurie VK3AMA

locked Re: dB vs Grid?

Bill - AA4M

Hello Scott,

Thanks for the tip Scott.  That worked, the only (minor) problem is that it loses the setting when I close WSJT-X and start it up again.  I can easily live with this!  :)

BTW - you have a nice callsign!  See you in the pileups

73, Bill  AA4M

On 04/13/2021 10:06:25, Scott Armstrong wrote:

That function/feature already exists in WSJT-X.
Double right click on the Tx1 button. The Tx1 message box will grey out and all QSO will start with the  Tx2 message.

-Scott AA5AM

On Tue, Apr 13, 2021 at 10:54 AM Bill - AA4M <MrBill@...> wrote:
I just downloaded 2.50.0 and spent about 2 hours working with it.  All I can say is FLAWLESS, WOW!

I did have one request for an enhancement.  Anybody who's ever worked DX knows that they often start a QSO with the dB report rather than a grid.  I like this, especially in marginal conditions.  What I'd like to see in JTAlert is an option to make my response to a CQ or tailgate (by double clicking in the callsign window) begin with my sending dB rather than grid location.  Can such a feature ever be implemented?

Thanks for the great software Laurie!

73, Bill  AA4M

locked Re: 2.5.0 -- AutoIt Error

HamApps Support (VK3AMA)

On 14/04/2021 1:49 am, David - AK2L wrote:
Clearly, JTAlert doesn't like being connected to my HRD installation.  This is not a new problem; it existing in earlier versions of JTAlert as well.  But with the earlier versions, it would usually happen only once when I changed a setting.  I would then restart JTAlert and all would be well until I changed another setting.  With v2.50, it happens every time.

I would be interested to hear from other HRD6 users to see if they have seen any problems.

For now, I will look at logging directly from WSJT-X or perhaps changing my logging program altogether.

There are several members of the JTAlert Test Team that use HRD logging. None have reported this issue.

What Log type are you using in HRD? Is it MSAccess? There have been numerous problems with HRD MSAccess logs in recent months that have affected JTAlert. They didn't crash JTAlert but typically caused significant slowdown. The fix in all cases was to create a new Log in HRDLogbook and then set the new log in JTAlert. The problem appears to be tied into the ODBC DSN that HRD uses for its logs. Creating a new DSN, which happens when creating a new log seems to clear the problem. Some MSAccess log users have converted to MariaDB which solved the problem for them.

de Laurie VK3AMA

locked Re: JTAlert for JTDX and WSJT-X - ver. 2.50

John Profita

Edmundo, I do have 2 monitors but I have on 1 monitor my log program (LOG4OM) and the other window I run the JTDX or WSJT-X with JTAlert. Knowing that JTAlert is different for each. Because is the same for both. No JTAlert. I am decoding around 40 to 50 and sometimes even 60 plus. Not sure what to do at this point. Its frustrating for sure.

Tnx, John ND1X

locked Re: JTAlert for JTDX and WSJT-X - ver. 2.50

John Profita

Jim, I checked and and the JTAlert window is not behind the callsign window. Its no where to be found for some reason. I am sure its something simple but for the life of me I can't find it. Its frustrating! I like the callsign window.

John ND1X

2361 - 2380 of 36206