forgot to mention I am using the single click option to select a call.

I found it. I did not have the accept etc. checks in WSJT-X for the UDP address which WAS populated OK.
Sorry for not finding this sooner. Now clicking on a call in Alerts works beautifully.  73, K0AZ

Suspect I am missing something in JT Alerts set up. Everything else seems to work fine.
Cannot answer callsign by double clicking that call in the Alerts window. Any help appreciated.
Thanks, K0AZ

On 2021-10-11 2:00 AM, Robert Bencsko wrote:

I would still like to know where it pulls the info to update that?

Both LotW and eQSL provide a file of users (LotW) and AG users (eQSL).
Laurie downloads those files and the FCC license database which are
included in the JTAlert callsign database that he updates approximately
every two weeks at <www.hamapps.com>. Scroll to the bottom of the page
for "Support File Downloads."

73,

... Joe, W4TV


On 2021-10-11 2:00 AM, Robert Bencsko wrote:

Just was able to contact someone else via JTAlert texting.  He said I had all three icons on my decode so it seems to be working but not sure why my other friend doesn't see them
I would still like to know where it pulls the info to update that?

OK thank you, i will check on his version.  I recently updated mine.

Just was able to contact someone else via JTAlert texting.  He said I had all three icons on my decode so it seems to be working but not sure why my other friend doesn't see them
I would still like to know where it pulls the info to update that?

On 11/10/2021 4:32 pm, Robert Bencsko wrote:

I recently upgraded my callsign from W7AMC to AD7J.  Now my friend says the only flag he has on my decode is TEXT, NO LoTW or eQSL.
LoTW I have updated with new TQSL cert and have been uploading updated via Ham Radio Deluxe with no problems.  eQSL I added another call to account and have also been uploading with no issue. In JTAlert I have updated all the call's and password for logging.
Where does JTAlert get the information to display the icons?  I don't now for sure where else to look for the cause

Your Callsign, AD7J, is recorded in the Callsigns database and shows you in NV and use eQSL(AG) and LoTW.

Each JTAlert release automatically includes the most up-to-date Callsign database at the time of release, If someone is not seeing the correct info for your callsign than they are likely using a old version of JTAlert which has an old database that does not include your new callsign. If they don't want to upgrade JTAlert, than they need to install the Callsign database and keep it updated. The database is updated approximately every 2 to 3 weeks..

de Laurie VK3AMA

Also on eQSL I have been authenticated and received the cert. I'll have to ask my friend what it shows for me in PSKReporter.  I'm just not sure where these pull their info.

I recently upgraded my callsign from W7AMC to AD7J.  Now my friend says the only flag he has on my decode is TEXT, NO LoTW or eQSL.
LoTW I have updated with new TQSL cert and have been uploading updated via Ham Radio Deluxe with no problems.  eQSL I added another call to account and have also been uploading with no issue. In JTAlert I have updated all the call's and password for logging.
Where does JTAlert get the information to display the icons?  I don't now for sure where else to look for the cause

On 11/10/2021 01:06, Joe Subich, W4TV wrote:

If the WSJTX version is 64 bit, you want the x64 installer.  If the 32
bit version of WSJTX is installed you want the x86 installer.

Hi Joe,

just a small correction, the architecture of WSJT-X (32- or 64-bit) is not relevant here. The architecture version of the Microsoft .NET Deskop Runtime needed is the one that matches the architecture of the version of *JTAlert* that has been installed.

73
Bill
G4WJS.



--
73
Bill
G4WJS.

On 2021-10-10 7:33 PM, Bob McLeod via groups.io wrote:

I have the PC now. Reading through the help file for JTAlert, it mentions about copying the information from the "About" screen for the current operating state, so I was going to have a look at that and compare the status to my own installation, but the about screen doesn't appear.

Sounds like the *wrong version* of dotNET 5.0.x is installed. You must
install the *DESKTOP* version. If you look in the right hand column
here: <https://dotnet.microsoft.com/download/dotnet/5.0> there are
*three* versions - ASP.NET Cor Runtime 5.0.10, .NET Desktop Runtime
5.0.10 and .NET Runtime 5.0.10. You want the *middle* one - the
*DESKTOP* version.

If the WSJTX version is 64 bit, you want the x64 installer. If the 32
bit version of WSJTX is installed you want the x86 installer.

Use Windows PC Settings -> Apps -> Apps and Features to look for
"Microsoft Windows Runtime - 5.0.xx" or Control Panel -> Programs
and Features to look for "Microsoft Windows Runtime - 5.0.x". If
you find "Microsoft Windows Runtime" *without* "DESKTOP" in the
name, the wrong version of dotNET 5.0.xx is installed.

73,

... Joe, W4TV


On 2021-10-10 7:33 PM, Bob McLeod via groups.io wrote:

I have the PC now.  Reading through the help file for JTAlert, it mentions about copying the information from the "About" screen for the current operating state, so I was going to have a look at that and compare the status to my own installation, but the about screen doesn't appear.  So I thought perhaps it is a corrupt installation, so I uninstalled, restarted the PC and installed again - but it is still the same.
By the way, it is a new Windows 10 laptop with nothing else on it - just WSJT-X, JTAlert and DXKeeper.
73 Bob VP8LP

I have the PC now.  Reading through the help file for JTAlert, it mentions about copying the information from the "About" screen for the current operating state, so I was going to have a look at that and compare the status to my own installation, but the about screen doesn't appear.  So I thought perhaps it is a corrupt installation, so I uninstalled, restarted the PC and installed again - but it is still the same.

By the way, it is a new Windows 10 laptop with nothing else on it - just WSJT-X, JTAlert and DXKeeper.
73 Bob VP8LP

I suggest that, if you use both programs, you create a symbolic link from the wsjtx_log.adi in the WSJT-X folder to wsjtx_log.adi in the JTDX folder.  In Windows, I use LinkShellExtension.  Once installed it lets you pick the source and drop it as a symlink in another folder.

Using this method.  You don't have to worry about which file you are using if switching programs.

73.
Carl - WC4H

You need to copy the files wsjt.log and wsjt_log.adi from your WSJT-X application folder over to the new JTDX application folder.
This is mentioned in the JTDX documentation.
JTDX uses the same log file name structure as WSJT-X.
The WSJT-X files are located in: C:\Users\<username>\AppData\Local\WSJT-X.
Copy them over to the JTDX folder, and allow them to overwrite the existing files. The JTDX folder is at: C:\Users\<username>\AppData\Local\JTDX
--
73,
Roger
AC6BW

Hi Laurie/Jim

Laurie - SpotCollector has not even been downloaded, so don't think that is the answer.  The only DXLab things downloaded are DXKeeper and DXCommander, but I don't think DXCommander is actually running - he is controlling the radio through WSJT-X. 

Ref Jim's suggestion about Power/Sleep - he has worked through these settings, but as Jim says there are many places to check and not sure if he has caught them all, but as far as we can tell it shouldn't go to sleep in the future.

There may be a chance to get his PC later today (he lives 100 miles away from me) and we can have a play with it - have more time than him as I am retired.

Thanks for the replies.
73 Bob VP8LP

It is not possible to run JTAlert and SpotCollector concurrently if SpotCollector has WSJTX integration enabled.

Just to be clear. JTAlert and SpotCollector can run concurrently. I do it all the time.

But you cannot have SpotCollecter set to work with WSJTX directly. If you require SpotCollector to work with WSJTX directly, than you have no choice but to abandon using JTAlert.

JTAlert has had for many years the ability to feed decodes into SpotCollector. This is the only way to have SpotCollector and JTAlert running concurrently and for SpotCollector to display WSJTX decodes as local spots.


de Laurie VK3AMA

A friend is setting up his FT8 programs on a new PC.  He has WSJT-X, JTAlert and DXKeeper.  It was all working fine on the old PC, and he thinks he has installed it in the same way on the new PC.  In fact it seemed to be working, but the PC went to sleep at some stage with the programs open, and now JTAlert doesn't connect to WSJT-X (there is no band information in the title bar). That could have been a coincidence, but nothing he has tried will make it connect now - including making sure the 3 tick boxes on the WSJT-X Reporting tab that deal with UDP are checked.  I hope to be able to log on to remote view his PC later today, and I will go through checking the installations and settings against those on my working copy, but has anyone come across this before, or have any suggestions? Thanks Bob VP8LP

reading your other responses, my guess is that SpotCollector is running and it has WSJTX integration enabled. In that situation, SpotCollector is taking exclusive control of the UDP port and locking JTAlert out. It is not possible to run JTAlert and SpotCollector concurrently if SpotCollector has WSJTX integration enabled.

Normally, to allow multiple applications to work with WSJTX concurrently requires using UDP multicast. Unfortunately, the technology of SpotCollector does not support multicast UDP which is why the WSJTX integration needs to be turned off if you want to run JTAlert.

de Laurie VK3AMA

I recently tried out the jtdx, but found that the stations I have worked before are showing up as not worked. Is this normal? I thought I read that both alert’s used the same database file?

 

73 de KE5WCT

Mike Wilson

There is zero difference within JTAlert when it comes to B4 reporting when operating in wsjtx or jtdx mode. The two modes, wsjtx and jtdx are needed because there are certain functions with respect to the wsjtx UDP protocol that jtdx does not follow or have altered. The JTAlert code is littered with jtdx specific checks to control operation to work around the jtdx changes/defects not present with wsjtx

B4 reporting within JTAlert is not affected by the wstx or jtdx operating mode selected.

My guess is that you're referring to the B4 reporting within JTDX compared to WSJTX. JTAlert does NOT control the B4 reporting in those applications, it is the applications that are doing the B4 reporting based on adif log maintained by the application and by default they will be different. Logging a QSO in WSJTX will update its adif log, but that is not carried over to the JTDX log. This why both apps are reporting different B4 conditions.

de Laurie VK3AMA

Any other software (e.g., logger) running? Perhaps it is not multicast
enabled (or multicast is not enabled in WSJTX) and the other software is blocking the UDP port.


73,

... Joe, W4TV

Hi Joe, Yes, he has done a restart.
73
Bob VP8LP