Date   

locked Re: JTAlert not connecting to WSJT-X #FT8

Bob McLeod
 

Problem solved.  As I was looking around the PC trying to work out what the issue was, I found several Windows functions not working - for example right click on the start menu - Control panel wouldn't open (although settings and device manager were OK).  So I started looking for a solution to that and ended up restoring Windows to it's out of the box state, saving personal settings only. 

I then went through all the sleep settings again etc , reloaded WSJT-X, JTAlert and DXKeeper, and Dimension for the timing, and everything is working now.  Just don't know what caused Win10 to go faulty.

Thanks to everybody who has contributed advice.

73
Bob VP8LP


locked Re: Cannot double click callsign in Alerts window and populate Generate Std Msgs in WSJTX #FT8

Mike Sanders
 

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


locked Re: Cannot double click callsign in Alerts window and populate Generate Std Msgs in WSJTX #FT8

Mike Sanders
 

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


locked Cannot double click callsign in Alerts window and populate Generate Std Msgs in WSJTX #FT8

Mike Sanders
 

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


locked Re: LoTW & eQSL Flags missing on remote decode of my call #FT8

Joe Subich, W4TV
 

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?


locked Re: LoTW & eQSL Flags missing on remote decode of my call #FT8

Robert Bencsko
 

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


locked Re: LoTW & eQSL Flags missing on remote decode of my call #FT8

Robert Bencsko
 

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?


locked Re: LoTW & eQSL Flags missing on remote decode of my call #FT8

Laurie, VK3AMA
 

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


locked Re: LoTW & eQSL Flags missing on remote decode of my call #FT8

Robert Bencsko
 

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.


locked LoTW & eQSL Flags missing on remote decode of my call #FT8

Robert Bencsko
 

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


locked Re: JTAlert not connecting to WSJT-X #FT8

g4wjs
 

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.


locked Re: JTAlert not connecting to WSJT-X #FT8

Joe Subich, 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.
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


locked Re: JTAlert not connecting to WSJT-X #FT8

Bob McLeod
 

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


locked Re: JTAlert for WSJT-X vs JTAlert for JTDX

Carl - WC4H
 

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


locked Re: JTAlert for WSJT-X vs JTAlert for JTDX

Roger- AC6BW
 

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


locked Re: JTAlert not connecting to WSJT-X #FT8

Bob McLeod
 

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


locked Re: JTAlert not connecting to WSJT-X #FT8

HamApps Support (VK3AMA)
 

On 10/10/2021 2:04 pm, HamApps Support (VK3AMA) via groups.io wrote:
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


locked Re: JTAlert not connecting to WSJT-X #FT8

HamApps Support (VK3AMA)
 

On 10/10/2021 6:15 am, Bob McLeod via groups.io wrote:
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


locked Re: JTAlert for WSJT-X vs JTAlert for JTDX

HamApps Support (VK3AMA)
 

On 10/10/2021 4:43 am, Mike Wilson wrote:

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




locked Re: JTAlert not connecting to WSJT-X #FT8

Joe Subich, W4TV
 

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

On 2021-10-09 9:26 PM, Bob McLeod via groups.io wrote:
Hi Joe, Yes, he has done a restart.
73
Bob VP8LP

541 - 560 of 37662