Date   

locked Re: No decodes in call sign window

Michael Black
 

What antivirus are you using?

Sounds kind of like it's removing something but the delayed reaction is strange.

You can try putting an exclusion on the JTAlert program directory.

Mike W9MDB




On Tuesday, September 7, 2021, 07:55:07 PM CDT, Robert Railer <rarailer@...> wrote:


I have to delete and reload JtAlert several times to get call signs to propagate in the call signs box.  When I shut down the program and restart it, no call signs appear again making me have to delete the program and reload once again several times until it works properly.  
What is missing that will not allow the call signs to propagate each time I restart the program?
Rob K8RAR    73


locked No decodes in call sign window

Robert Railer
 

I have to delete and reload JtAlert several times to get call signs to propagate in the call signs box.  When I shut down the program and restart it, no call signs appear again making me have to delete the program and reload once again several times until it works properly.  
What is missing that will not allow the call signs to propagate each time I restart the program?
Rob K8RAR    73


locked Re: Can get Callsigns window to display JTAlert 2.50.5

Fred Kemmerer
 

I just reinstalled the 2.50.5 and NET Framework updates on my computer a second time. This seems to have cleared up the problem.
--
Best and 73,

Fred, AB1OC
https://stationproject.blog
https://www.n1fd.org


locked V2.505 and worked B4

Bob Frostholm
 

Hi Laurie,

I too have noticed occasionally that stations I have worked before show up an unworked... but only briefly... maybe for a few decode cycles (less than 10). Most recently, last evening with V31MA.

Yes, the rig frequency is set in WSJT-x V2.5.0 rc5

Here are my settings:

73

Bob

Ko6Lu


-------- Forwarded Message --------
Subject: Re: [HamApps] V2.505 and worked B4
Date: Tue, 7 Sep 2021 18:21:16 +1000
From: HamApps Support (VK3AMA) via groups.io <vk3ama.ham.apps@...>
Reply-To: Support@HamApps.groups.io
To: Support@HamApps.groups.io


On 7/09/2021 5:15 pm, Jacques F1VEV wrote:
I have noticed recently a lot of worked B4 call signs showing up in the call sign window if I double click then call sign comes up in main window  as QSO B4 ?

I have tried rebuilding data base  choosing ignore based on log entry and also older then etc ; but noting they still show up ? 

Using WSJTX 2.4.0 JTAlert 2.50.5 HRD logbook 6.7.0.357 on SQL  on W10 Pro   ( JTA logs direct to HRD)
I have tried all suggestion I have read about to no avail I must be blind to something obvious  pointer will be welcomed 
Thank you Jacques 
F1VEV

Firstly, The Alert Database rebuild does not affect the B4 status.

If a Callsign is not showing a B4 when decoded but does when that Callsign becomes the DXCall in WSJTX that will be due to the Worked B4 settings in JTAlert, especially if you have a date threshold set for the B4 or the B4 is ignored for some Alerts.

The "QSO B4" shown in the main JTAlert window when you're in QSO with the Callsign indicates that is an existing QSO in your log for the current Band & Mode. That "QSO B4" status is a log status, not an Alert status, and is independent of the B4 reporting of the live decodes.

What settings do you have set under the  "Alerts -> Worked B4" section of the Settings widow?

de Laurie VK3AMA


--
Bob
KO6LU


locked Can get Callsigns window to display JTAlert 2.50.5

Fred Kemmerer
 

I just upgraded to JTAlert 2.50.5 and the NET Framework version that was specified for this upgrade. Since upgrading, I can no longer get the Callsigns window to come up. I've also tried the "Bring all windows back to the primary display" menu item and that did not help. I don't see the callsigns window running in the takbar when I hover over the JTAltert icon. Can someone help?
--
Best and 73,

Fred, AB1OC
https://stationproject.blog
https://www.n1fd.org


locked Re: V2.505 and worked B4

Jacques F1VEV
 
Edited

On Tue, Sep 7, 2021 at 01:21 AM, HamApps Support (VK3AMA) wrote:
 This is what I tried last as I would have thought it was the most restrictive  but some still show  despite last QSO was over 18 months ago  Cheers  Jacques 
--
F1VEV

edit the callsign window is on all decode should it be on alerts only 


locked Re: V2.505 and worked B4

HamApps Support (VK3AMA)
 

On 7/09/2021 5:15 pm, Jacques F1VEV wrote:
I have noticed recently a lot of worked B4 call signs showing up in the call sign window if I double click then call sign comes up in main window  as QSO B4 ?

I have tried rebuilding data base  choosing ignore based on log entry and also older then etc ; but noting they still show up ? 

Using WSJTX 2.4.0 JTAlert 2.50.5 HRD logbook 6.7.0.357 on SQL  on W10 Pro   ( JTA logs direct to HRD)
I have tried all suggestion I have read about to no avail I must be blind to something obvious  pointer will be welcomed 
Thank you Jacques 
F1VEV

Firstly, The Alert Database rebuild does not affect the B4 status.

If a Callsign is not showing a B4 when decoded but does when that Callsign becomes the DXCall in WSJTX that will be due to the Worked B4 settings in JTAlert, especially if you have a date threshold set for the B4 or the B4 is ignored for some Alerts.

The "QSO B4" shown in the main JTAlert window when you're in QSO with the Callsign indicates that is an existing QSO in your log for the current Band & Mode. That "QSO B4" status is a log status, not an Alert status, and is independent of the B4 reporting of the live decodes.

What settings do you have set under the  "Alerts -> Worked B4" section of the Settings widow?

de Laurie VK3AMA


locked V2.505 and worked B4

Jacques F1VEV
 

Hello,

I have noticed recently a lot of worked B4 call signs showing up in the call sign window if I double click then call sign comes up in main window  as QSO B4 ?

I have tried rebuilding data base  choosing ignore based on log entry and also older then etc ; but noting they still show up ? 

Using WSJTX 2.4.0 JTAlert 2.50.5 HRD logbook 6.7.0.357 on SQL  on W10 Pro   ( JTA logs direct to HRD)
I have tried all suggestion I have read about to no avail I must be blind to something obvious  pointer will be welcomed 
Thank you Jacques 
F1VEV


locked Re: Log data not transferring to Logger32

HamApps Support (VK3AMA)
 

On 6/09/2021 11:27 pm, Gerard Arsenault wrote:

Thanks Laurie. Obviously I have very little understanding of the coding involved. What I can't grasp is why for a number of years logging worked automatically and continuously between WSJT-X and Logger 32 before updates and a new radio. I will follow your advice and check with the Logger 32 forum.
73,

Jerry VE9CD

I don't know how you had WSJT-X, JTAlert and Logger32 working together. JTAlert doesn't log to Logger32, it is not supported as JTAlert cannot read the proprietary log file format used by Logger32. Either Logger32 was intercepting the WSJTX log UDP message or it was listening to the UDP resend that JTAlert provides, ether way, JTAlert must have been setup for some other log type or no log.

I have been told that there are instructions for JTAlert within the Logger32 help documentation. I cannot confirm that however as I have not seen it. You're best to ask the Logger32 people.

de Laurie VK3AMA


locked Re: Error line 10388

HamApps Support (VK3AMA)
 

On 7/09/2021 7:17 am, André C wrote:
Hello  I have a problem,  I installed JTalert 2.50.5 with WSJTX 2.4.0 and desktop NET 3.0.9  on Windows10 64 bits.  Everything is 64 bits.  Problem apears after JTalert start decoding callsigns in the callsign window and then a popup box appears saying   error lIne 10388 variable used without being declared.
I re-installed JTalert but problem remain the same.

Any Advice ?   

73 André VE2WNF 

This type of random error is normally infrequent and typically occurs only once or twice for the small number of users who experience it. There is no known cause or fix.

If you are getting the error every time JTAlert starts decoding suggests a problem with the log file that JTAlert is reading to determine the B4 status. Are you using HRDLogbook? If so, that may be the problem. In recent months a small number of HRD users have experienced problems that were resolved by creating a new logfile within HRDLogbook and importing the QSOs from the old log into the new log. You will then need to set the new logfile in the JTAlert Settings. See if that works for you.

If you're not using a HRD log, perhaps it is the JTAlert config file that is a problem. You can try deleting the file and allowing JTAlert to automatically create a new file. You will need to re-enter all your old settings as they will be lost when you delete the config file. For your Callsign the config file can be found at %localappdata%\HamApps\
VE2WNF\config\JTAlertX\config.sqlite
Stop JTAlert, delete that file or move it to a safe location, start JTAlert.

de Laurie VK3AMA


locked Re: Log data not transferring to Logger32

Dave Garber
 

i dont know logger32 at all, but perhaps you were sending udp's via wsjt, and not jtalert


Dave Garber
VE3WEJ / VE3IE


On Mon, Sep 6, 2021 at 9:27 AM Gerard Arsenault <jerrya@...> wrote:

Thanks Laurie. Obviously I have very little understanding of the coding involved. What I can't grasp is why for a number of years logging worked automatically and continuously between WSJT-X and Logger 32 before updates and a new radio. I will follow your advice and check with the Logger 32 forum.
73,

Jerry VE9CD


locked Error line 10388

André C
 

Hello  I have a problem,  I installed JTalert 2.50.5 with WSJTX 2.4.0 and desktop NET 3.0.9  on Windows10 64 bits.  Everything is 64 bits.  Problem apears after JTalert start decoding callsigns in the callsign window and then a popup box appears saying   error lIne 10388 variable used without being declared.
I re-installed JTalert but problem remain the same.

Any Advice ?   

73 André VE2WNF 


locked Re: enhancement request

Joe
 

No problem!  Happy to hear that the mod is in the works!! 

73s,

Joe/WQ6Q


locked Re: Worked B4 conflicting (some callsigns)

Michael Black
 

Do you maybe have some QSOs showing as MFSK mode?

Mike W9MDB




On Monday, September 6, 2021, 08:40:51 AM CDT, nd2k@... <nd2k@...> wrote:


Running JTAlert 2.50.5/WSJT 2.4.0/Log4OM V2 2.17.0.0

I have noticed with a small handful of calls, the Confirmed/Worked Bands Display
will correctly show a callsign worked (e.g. the 20M FT4 worked box is checked)
but the same callsign in the Callsigns Window does not show "B4"; nor is it
"grayed out" in the WSJT Band Activity column (indicating worked B4).

Again, this is only a small handful of callsigns, with not rhyme or reason to them
having anything in common. I rebuilt the database, but still no change.

Any ideas??

Al ND2K


locked Worked B4 conflicting (some callsigns)

nd2k@...
 

Running JTAlert 2.50.5/WSJT 2.4.0/Log4OM V2 2.17.0.0

I have noticed with a small handful of calls, the Confirmed/Worked Bands Display
will correctly show a callsign worked (e.g. the 20M FT4 worked box is checked)
but the same callsign in the Callsigns Window does not show "B4"; nor is it
"grayed out" in the WSJT Band Activity column (indicating worked B4).

Again, this is only a small handful of callsigns, with not rhyme or reason to them
having anything in common. I rebuilt the database, but still no change.

Any ideas??

Al ND2K


locked Re: Log data not transferring to Logger32

Gerard Arsenault
 

Thanks Laurie. Obviously I have very little understanding of the coding involved. What I can't grasp is why for a number of years logging worked automatically and continuously between WSJT-X and Logger 32 before updates and a new radio. I will follow your advice and check with the Logger 32 forum.
73,

Jerry VE9CD


locked Re: Callsign window actions not enabling WSJT "enable tx"

Jim Cary
 

Thanks Laurie.  Accept UDP requests was not clicked on.

Jim


locked Re: Callsign window actions not enabling WSJT "enable tx"

ON4AVJ@...
 

Hello,
I have the same problem, but I'm using JTDX. What are the setting there?
73
Jacques ON4AVJ


locked Re: enhancement request

HamApps Support (VK3AMA)
 

On 4/09/2021 8:44 am, Joe wrote:

In the new version of JTAlert (2.50.5), I note that for some windows, like the Decodes window, it makes sense to clear the panel after each decode, while for others, like the Callers panel, one can set the persistence of the information shown in that panel, from "no auto clear" down to 1 minute.  I would like to be able to set this same parameter for clearing the DXCC Alert window, so that I can see, what DX I might have missed while I was away from my station.  This is valuable information in that it lets you know, especially over a few days, when a DX entity was being decoded at your station.  Is there already a way to do this, or would this be a reasonable thing to add??

When I initially saw the drop down box with "Callers (own call alert)" I thought this was going to be a drop down that allowed me to select a panel for configuration.  Changing it so that it does, in fact, work that way doesn't seem like a major change, but I fully realize it may be more difficult that it appears, and/or, the priority of such a modification might be so far down the list as to be not likely in the near future.  Alternatively, and maybe even better, would be a separate window that simply captured every (time stamped) DXCC alert until cleared, if enabled.

Should I get my hopes up ;-)

Joe,

Persisting callsigns in the different Alert views of the Callsigns window, similar to the "Callers" view is already on my todo list. When I coded the persisting Callsigns for the "Callers" view I realized that this would be useful for other views. The underlying code framework is partially coded but not ready for going live. You can see some of that work in the Hamburger menu (3 horizontal line icon) of each view having a "Clear Callsigns" entry. Rest assured it will be happening, I just don't know when, soon I hope, but not in the next release I can say with confidence.

de Laurie VK3AMA


locked Re: JTAlert Main Window not Visible SOLVED

HamApps Support (VK3AMA)
 

On 6/09/2021 5:04 am, Robie - AJ4F wrote:
The JTalert main screen issue was resolved by deleting the ini file and letting JTAlert regenerate it,


The issue of no communication between WSJT-X and JTAlert was intermittent an has not recurred after switching JTAlert & WSJT-X to multicast.


Thanks for all the assistance!

Robie - AJ4F 
Thanks for the update.

I don't know what ini file you are referring to, JTAlert doesn't use ini files.

de Laurie VK3AMA

861 - 880 of 37666