Date   

locked Re: More CQ Marathon info

Steve, N3SL
 

Phil,

When the alert fires, what "reason" is JTAlert telling you?  (put your mouse pointer over the alerted call in the JTA window - a popup will tell you what triggered the alert - plus other info)
Sounds to me like ZA on 30 may have fired for a reason other than Marathon.

On Fri, Feb 5, 2021 at 5:04 AM Phil Cooper via groups.io <pcooper=suremail.gg@groups.io> wrote:

Laurie and the group,

 

I have checked the "Auto clear triggered Alert entry after logging", but I am still getting alerts for an entity that was logged on another band.

 

As an example, I worked ZA/IN3PPH on 40m FT8 yesterday (4th), but JTAlert is giving me an alert today when he was on 30m FT8.

 

The only way I can prevent this is to do a rebuild of my log, which was what I had to do before.

 

So, does the Auto clear only work for the same band/mode in the same session?

 

73 de Phil GU0SUP


locked More CQ Marathon info

Phil Cooper
 

Laurie and the group,

 

I have checked the "Auto clear triggered Alert entry after logging", but I am still getting alerts for an entity that was logged on another band.

 

As an example, I worked ZA/IN3PPH on 40m FT8 yesterday (4th), but JTAlert is giving me an alert today when he was on 30m FT8.

 

The only way I can prevent this is to do a rebuild of my log, which was what I had to do before.

 

So, does the Auto clear only work for the same band/mode in the same session?

 

73 de Phil GU0SUP


locked Re: About worked b4 #HRD

Dave Garber
 

those highlights look like they are from jtalert, so check you alert settings.  you may have another alert type  selected to activate before the 'B4' alert.   the order can be changed

Dave Garber
VE3WEJ / VE3IE


On Fri, Feb 5, 2021 at 4:39 AM jorge garcia via groups.io <ea8tl=yahoo.com@groups.io> wrote:
Hello

I have a problem with worked b4, see picture:


ALERT > CLEAR B4 CACHE was clicked multiple times , JTAlert was restart mutiple times, "Do not check or report logging success/failure" not enabled.
Im using Ham Radio Deluxe 6.
In general the worked b4 works fine, but with some callsign I have this problem.

Any idea?
Thank you....
JORGE G.
EA8TL


locked About worked b4 #HRD

Jorge EA8TL
 

Hello

I have a problem with worked b4, see picture:


ALERT > CLEAR B4 CACHE was clicked multiple times , JTAlert was restart mutiple times, "Do not check or report logging success/failure" not enabled.
Im using Ham Radio Deluxe 6.
In general the worked b4 works fine, but with some callsign I have this problem.

Any idea?
Thank you....
JORGE G.
EA8TL


locked Alert with JTDX

 

Cant load alert to JTDX even tho JTDX is up and running.
Thanks
--
DAVE NU4N


locked Re: JTAlert--->DXKeeper problem

HamApps Support (VK3AMA)
 

On 5/02/2021 10:16 am, Jim Monroe wrote:
Thanks for your reply and I thought you solved my problem as I didnt have those checkmarked, I have only been hitting the Logging button and down to the DXLab DXKeeper tab without double hitting the Logging button. So now when I log a qso it filles the name and qth window in DXKeeper but not the address square unless I manually hit the CBA button than it fills with name and complete address. So close....In JTAlert I do have check marked "log full qth from xml lookups" I assume that should include the complete address. 
Jim, n7esu

I don't know what you mean by double hitting the Log button. There should only be one Log button clicked. That is the "OK" button on the WSJT-X "Log QSO" window only. Once you click that JTAlert automatically picks up the new QSO data, combines it with what ever data it has retrieved from the XML lookup (which can be seen in the Log fields area of JTAlert), formats the necessary command and sends to DXKeeper.

If you don't hit the "OK" button, than JTAlert will never log anything, that operation is mandatory and is how it has always worked, otherwise JTAlert will have no knowledge of what you want to log.

The XML data JTAlert downloads is not populated in DXKeeper prior to logging, only the DX Call callsign is sent to DXKeeper prior to logging. You should not be trying to log from within DXKeeper, I suspect that is what your doing. Let JTAlert do its thing in passing the WSJT-X QSO data with the XML data onto to DXKeeper.

de Laurie VK3AMA


locked Re: JTAlert--->DXKeeper problem

Jim Monroe
 

Ron,
Thanks for your reply and I thought you solved my problem as I didnt have those checkmarked, I have only been hitting the Logging button and down to the DXLab DXKeeper tab without double hitting the Logging button. So now when I log a qso it filles the name and qth window in DXKeeper but not the address square unless I manually hit the CBA button than it fills with name and complete address. So close....In JTAlert I do have check marked "log full qth from xml lookups" I assume that should include the complete address. 
Jim, n7esu

On Thu, Feb 4, 2021 at 8:17 AM Ron W3RJW via groups.io <w3rjw=verizon.net@groups.io> wrote:
Perhaps checks missing?


--
73
Ron, W3RJW


locked Re: CQ Marathon query

Phil Cooper
 

Hi Laurie,

 

Wow, many thanks for clearing that up!

I was feeling very confused, and will re-set that tomorrow.

It was not set, partly because I wasn’t clear about the meaning, although it did seem to be the answer given by Jim N6VH. However, when you sent your reply, I was starting to think that it would mean I would no longer get alerts for new band-slots.

 

Thanks again for all your support with JTAlert. I could not live without it now.

 

73 de Phil GU0SUP

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of HamApps Support (VK3AMA)
Sent: 04 February 2021 18:56
To: Support@HamApps.groups.io
Subject: Re: [HamApps] CQ Marathon query

 

On 4/02/2021 11:25 pm, Phil Cooper via groups.io wrote:

Ah, so you are saying that if this box is checked, and I work (for example) P5XXX on 20m FT8, I will NOT get an alert when he pops up on another band?

 

I only want to stop alerts for any given country worked in the current year for CQ Marathon, as countries only count once, regardless of band/mode.

 

For now, i have unchecked that box again, as I don't wish to miss new DXCC slots.

 

73 de Phil GU0SUP

Rereading my response I can understand your confusion. The relevant part "This option is available for all the Alert types" could have been reworded. "This option is available for all the Alert types on a per Alert basis" may be better wording.

In a nut-shell, each Alert type has multiple options, each being independent of the same options in another Alert type. So you could set the Marathon Alert to track by any band and any mode while at the same time have the DXCC Alert track individual Bands and Modes. The same applies for the "Auto clear triggered Alert entity after logging" option. You can safely apply that option for the Marathon Alert without affecting your DXCC Alerts which you could have set for individual Bands and Modes and require a QSL confirmation (eg LoTW confirmed) for an Entity to be no longer Alerted.

de Laurie VK3AMA


locked Re: CQ Marathon query

HamApps Support (VK3AMA)
 

On 4/02/2021 11:25 pm, Phil Cooper via groups.io wrote:

Ah, so you are saying that if this box is checked, and I work (for example) P5XXX on 20m FT8, I will NOT get an alert when he pops up on another band?

 

I only want to stop alerts for any given country worked in the current year for CQ Marathon, as countries only count once, regardless of band/mode.

 

For now, i have unchecked that box again, as I don't wish to miss new DXCC slots.

 

73 de Phil GU0SUP

Rereading my response I can understand your confusion. The relevant part "This option is available for all the Alert types" could have been reworded. "This option is available for all the Alert types on a per Alert basis" may be better wording.

In a nut-shell, each Alert type has multiple options, each being independent of the same options in another Alert type. So you could set the Marathon Alert to track by any band and any mode while at the same time have the DXCC Alert track individual Bands and Modes. The same applies for the "Auto clear triggered Alert entity after logging" option. You can safely apply that option for the Marathon Alert without affecting your DXCC Alerts which you could have set for individual Bands and Modes and require a QSL confirmation (eg LoTW confirmed) for an Entity to be no longer Alerted.

de Laurie VK3AMA


locked Re: JTAlert--->DXKeeper problem

Ron W3RJW
 

Perhaps checks missing?


--
73
Ron, W3RJW


locked Re: CQ Marathon query

Steve, N3SL
 

Phil,
The checkbox is on "every" alert/award page, so each is individually configurable.  

On Thu, Feb 4, 2021 at 6:25 AM Phil Cooper via groups.io <pcooper=suremail.gg@groups.io> wrote:

Hi Laurie,

 

Ah, so you are saying that if this box is checked, and I work (for example) P5XXX on 20m FT8, I will NOT get an alert when he pops up on another band?

 

I only want to stop alerts for any given country worked in the current year for CQ Marathon, as countries only count once, regardless of band/mode.

 

For now, i have unchecked that box again, as I don't wish to miss new DXCC slots.

 

73 de Phil GU0SUP

 

 

-----Original Message-----
From: "Laurie, VK3AMA" <hamapps.support@...>
Sent: Thursday, 4 February, 2021 01:35
To: Support@HamApps.groups.io
Subject: Re: [HamApps] CQ Marathon query



On 4/02/2021 3:28 am, Jim N6VH wrote:

Go to Settings - Alerts - Wanted CQ Marathon.

Check "Auto clear triggered Alert entity after logging".


That will be the answer.

That setting causes an Entity to be automatically marked as no-longer needed in the Alert database. This option is available for all the Alert types, useful for those users who don't require a QSL confirmation to have an Entity set as no-longer need (so will not alert), that is they are happy for just working the Entity. Prior to this option being introduced, there was no automatic flagging of worked Entities, thus requiring the "Rebuild Alert Database" operation (previously called the Log Scan) to update the Alert database. For Entities that require just a worked status (like the Marathon) it is a simple set and forget option. Of course if you require a QSL confirmation (like LoTW for DXCC) donot enable that option.

Note: When I use the word "Entity", I am not referring to DXCC Entities, but using it to describe all the Alert type entities (DXCC, State, Zones, Grids, etc).

de Laurie VK3AMA


locked Re: JTAlert not working??

Morris WA4MIT
 
Edited

Thank you guys for the response but I am not using the new modes and why has Alert stopped working with JTDX. I spent most of yesterday trying to get Alert working but have had no success.
Do these new setting affect using Alert with JTDX? I tried going back to a older version of Alert I could not even get it to work I get a Alert is not responding and the Alert title bar and
what is on screen would not shut down or at least disappear I had to restart computer to get Alert off the screen. Strange happenings. This started with Alert at times not responding 
then after restarting Alert it worked but now it will not. I use JTDX 90% of time only on FT8/4 i have not used or tried the new modes at all. Attached a picture of what I am seeing using
JTDX. This is all I am able to get out of JTAlert right now. This latest Alert .17 My WSJTX (now 2.4.0 rc1) does not have the screen you guys are showing it and JTDX look like the picture I put up??
Thanks 73`s
Morris WA4MIT


locked Re: CQ Marathon query

Phil Cooper
 

Hi Laurie,

 

Ah, so you are saying that if this box is checked, and I work (for example) P5XXX on 20m FT8, I will NOT get an alert when he pops up on another band?

 

I only want to stop alerts for any given country worked in the current year for CQ Marathon, as countries only count once, regardless of band/mode.

 

For now, i have unchecked that box again, as I don't wish to miss new DXCC slots.

 

73 de Phil GU0SUP

 

 

-----Original Message-----
From: "Laurie, VK3AMA" <hamapps.support@...>
Sent: Thursday, 4 February, 2021 01:35
To: Support@HamApps.groups.io
Subject: Re: [HamApps] CQ Marathon query



On 4/02/2021 3:28 am, Jim N6VH wrote:

Go to Settings - Alerts - Wanted CQ Marathon.

Check "Auto clear triggered Alert entity after logging".


That will be the answer.

That setting causes an Entity to be automatically marked as no-longer needed in the Alert database. This option is available for all the Alert types, useful for those users who don't require a QSL confirmation to have an Entity set as no-longer need (so will not alert), that is they are happy for just working the Entity. Prior to this option being introduced, there was no automatic flagging of worked Entities, thus requiring the "Rebuild Alert Database" operation (previously called the Log Scan) to update the Alert database. For Entities that require just a worked status (like the Marathon) it is a simple set and forget option. Of course if you require a QSL confirmation (like LoTW for DXCC) donot enable that option.

Note: When I use the word "Entity", I am not referring to DXCC Entities, but using it to describe all the Alert type entities (DXCC, State, Zones, Grids, etc).

de Laurie VK3AMA


locked Re: JTAlert--->DXKeeper problem

Jim Monroe
 

Laurie,
Yes in JTAlert under web services --> online xml callbooks I have qrz.com xml lookup running, it even shows last lookup time and date and it working ok. Under the logging tab I have enabled dxlab dxkeeper logging . When I log qso everything populates DXKeeper except qrz.com data name and address...yet it shows last look up time and date with no errors...not sure what else I am missing,
Jim, n7esu

On Wed, Feb 3, 2021 at 4:46 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
On 4/02/2021 11:18 am, Jim Monroe wrote:
I cant figure out or remember how to get JTAlert to send to DXKeeper the name and address of a qso when logged. DXKeeper logs it ok when manually doing a look up or using the capture window. JTAlert shows last qso looked up when logging to its adi log. I am using QRZ hml. JTAlert and WSJT-X all working good and talking to each other and other logged info is saving in DXKeeper. This use to work until I re-built my computer and installed all fresh installs of everything. Thanks in advance for the help.
Jim, n7esu

It is automatic. If the name & qth fields in JTAlert contain data they will be logged. If they are empty then nothing is logged. Those fields can be populated either manually, from a previous QSO in your log or from the results of an XML lookup. My guess, is your not logging that data for QSOs with previously unworked (so not in your log) stations and don't have an XML service enabled in JTAlert.

de Laurie VK3AMA


locked Re: CQ Marathon query

Laurie, VK3AMA
 



On 4/02/2021 3:28 am, Jim N6VH wrote:

Go to Settings - Alerts - Wanted CQ Marathon.

Check "Auto clear triggered Alert entity after logging".


That will be the answer.

That setting causes an Entity to be automatically marked as no-longer needed in the Alert database. This option is available for all the Alert types, useful for those users who don't require a QSL confirmation to have an Entity set as no-longer need (so will not alert), that is they are happy for just working the Entity. Prior to this option being introduced, there was no automatic flagging of worked Entities, thus requiring the "Rebuild Alert Database" operation (previously called the Log Scan) to update the Alert database. For Entities that require just a worked status (like the Marathon) it is a simple set and forget option. Of course if you require a QSL confirmation (like LoTW for DXCC) donot enable that option.

Note: When I use the word "Entity", I am not referring to DXCC Entities, but using it to describe all the Alert type entities (DXCC, State, Zones, Grids, etc).

de Laurie VK3AMA


locked Re: JTAlert not working??

Laurie, VK3AMA
 



On 4/02/2021 4:04 am, neil_zampella wrote:


In addition to having a loopback interface selected in WSJT-X (a new requirement for 2.3.0), JTAlert needs to have the "Settings -> WSJT-X UDP Multicast on Loopback" menu ticked in order to work with the new WSJT-X interface changes.

   

de Laurie VK3AMA


locked Re: JTAlert--->DXKeeper problem

HamApps Support (VK3AMA)
 

On 4/02/2021 11:18 am, Jim Monroe wrote:
I cant figure out or remember how to get JTAlert to send to DXKeeper the name and address of a qso when logged. DXKeeper logs it ok when manually doing a look up or using the capture window. JTAlert shows last qso looked up when logging to its adi log. I am using QRZ hml. JTAlert and WSJT-X all working good and talking to each other and other logged info is saving in DXKeeper. This use to work until I re-built my computer and installed all fresh installs of everything. Thanks in advance for the help.
Jim, n7esu

It is automatic. If the name & qth fields in JTAlert contain data they will be logged. If they are empty then nothing is logged. Those fields can be populated either manually, from a previous QSO in your log or from the results of an XML lookup. My guess, is your not logging that data for QSOs with previously unworked (so not in your log) stations and don't have an XML service enabled in JTAlert.

de Laurie VK3AMA


locked Re: Post WSJTX 2.3 Install Issues

HamApps Support (VK3AMA)
 

On 4/02/2021 5:07 am, Patrick Hung wrote:
After installing WSJTX v.2.3 GA, JTAlert keeps showing me the following alert box, which will not go away after software or computer reboot; I also reinstalled v. 2.16.17, to no avail. Clicking on the OK button quits out of JTAlert.



No settings were changed on either WSJT-X or JTAlert throughout the WSJT-X upgrade; here they are below:





Any thoughts? Thanks in advance.

--
73,

Patrick - W6AJR

You have JTAlert set to resend received UDP traffic to port 2237. You have WSJT-X set to transmit UDP to port 2237. That is very very wrong and would result in JTAlert re-sending received UDP data back to the listening port which it would try and process and resend again in an endless infinite loop. This is likely the cause of the internal JTAlert error that brings down the program. If you need to resend UDP traffic it needs to be on a different port, other wise change the port and disable the setting.

de Laurie VK3AMA


locked Re: UDP Link to WSJT-X

HamApps Support (VK3AMA)
 

On 4/02/2021 6:39 am, Monty Wilson wrote:

Yesterday, as I was troubleshooting another issue, the communications between WSJT-X (2.3.0) and JTALERT (2.16.17) stopped for reasons unknown.

 

In troubleshooting I re-installed WSJT-X 2.2.2 since everything worked under that version, however, since the reload, I still do not have a connection between WSJT-X and JTALERT.

 

Anyone have an idea what to look for, what to try?

 

Monty, NR0A


Based on your posting in the WSJT-X group, my guess is that you have been playing with the UDP servers settings.

My response to your WSJT-X group message...

Looks like you have been playing with your WSJT-X UDP settings. Port 2333 is the default for the secondary UDP Server (depreciated). JTAlert uses the primary settings, and according to your error message is reading 2333. That looks wrong. My guess, without see your actual settings dialog, is that you have both the primary and secondary UDP servers set to use port 2333. Try changing back to the defaults, 2237 for the primary and 2333 for the secondary and don't enable the secondary server.

   

de Laurie VK3AMA



locked JTAlert--->DXKeeper problem

Jim Monroe
 

I cant figure out or remember how to get JTAlert to send to DXKeeper the name and address of a qso when logged. DXKeeper logs it ok when manually doing a look up or using the capture window. JTAlert shows last qso looked up when logging to its adi log. I am using QRZ hml. JTAlert and WSJT-X all working good and talking to each other and other logged info is saving in DXKeeper. This use to work until I re-built my computer and installed all fresh installs of everything. Thanks in advance for the help.
Jim, n7esu

3481 - 3500 of 36454