Date   

locked Re: Double Logging Issue

Dave AA6YQ
 

+ AA6YQ comments below

I am back home again, and am able to look at my JTAlert settings.
If I have both "Enable DXLab DXKeeper Logging", under Logging, and DXLab DXKeeper.
AND
have "Post decoded Callsigns to Spotcollector as local spots", under Applications, DXLab Suite.

checked, I will get double logging when I save a QSO. Turning off one of these will stop it.
I have the Spotcollector one unchecked and it works fine.

+ If you're using JT-Alert, then the Enable box in the WSJT-X panel on the "Spot Sources" tab of SpotCollector's Configuration
window should be unchecked.

If your getting double logging when SpotCollector is taking spots from JTAlert, that indicates a setting problem within
SpotCollector. The spotting instruction cannot be misinterpreted as a logging instruction, the two are totally different, one is a
TCPIP instruction while the other is a DDE instruction plus the format of the instructions are totally different.

There is a comprehensive setup document produced by the DXLab author (sorry, I don't have the link) that covers working with
JTAlert or WSJT-X directly.

+ Step-by-step instructions for JT-Alert interoperation with DXLab are here:

https://www.dxlabsuite.com/dxlabwiki/GettingStartedwithK1JTModesWithJTAlert

73,

Dave, AA6YQ


locked Re: Double Logging Issue

HamApps Support (VK3AMA)
 

On 16/03/2021 1:43 pm, Duncan Campbell wrote:
I am back home again, and am able to look at my JTAlert settings.
  If I have both "Enable DXLab DXKeeper Logging", under Logging, and DXLab DXKeeper.
AND
 have "Post decoded Callsigns to Spotcollector as local spots", under Applications, DXLab Suite.

checked, I will get double logging when I save a QSO.  Turning off one of these will stop it.
I have the Spotcollector one unchecked and it works fine.

73 de Duncan, KF6ILA

If your getting double logging when SpotCollector is taking spots from JTAlert, that indicates a setting problem within SpotCollector. The spotting instruction cannot be misinterpreted as a logging instruction, the two are totally different, one is a TCPIP instruction while the other is a DDE instruction plus the format of the instructions are totally different.

There is a comprehensive setup document produced by the DXLab author (sorry, I don't have the link) that covers working with JTAlert or WSJT-X directly. I suspect a setting used for direct WSJT-X interaction is the problem.

de Laurie VK3AMA


locked Re: How JTAlert communicates with WSJT-Xand logger such as HRD

HamApps Support (VK3AMA)
 

On 17/03/2021 5:06 am, g4wjs wrote:
I was under the impression that JTAlert was a MS Windows only application, how are you running it on Linux?

--
73
Bill
G4WJS.
That's the case. JTAlert is Windows only.
Currently, there are no plans to migrate to Linux or MacOS.

de Laurie VK3AMA


locked Re: Start problem Subscript used on non-accessible variable

HamApps Support (VK3AMA)
 

On 16/03/2021 8:57 am, Frank IZ7AUH wrote:

thank you for your answer, I apologize for the delay in my reply, this error does not appear often, I wish I could solve it and I am aware that it is not a JTALERT error I am looking for a solution and I update you on this, thanks, I hope one day  you can also support MSHV other nice software

IZ7AUH 


Frank,

Sorry, I can't provide a solution for you. You could try an older version of JTAlert and see if it fixes the issue.

As for MSHV support by JTAlert. That is very unlikely. MSHV has broken the UDP protocol and doesn't report Band or DXCall changes, so there is no way for JTAlert to know who your in QSO with and on what Band. This critical defect has been reported to the MSHV people by myself and others several times, but they appear to be not interested in fixing this critical defect.

de Laurie VK3AMA


locked Re: "Any Digital Mode" and Wanted Zone

HamApps Support (VK3AMA)
 

On 16/03/2021 10:07 am, Joe Subich, W4TV wrote:
On second look ... DXKeeper is correct.  The eQSL confirmation is
by a station that it *NOT AG*.  This it doesn't count for CQ WAZ.

Are you checking the "eQSL.cc member" field in DXKeeper for "A"
(AG status)?

73,

   ... Joe, W4TV

No.

The presence or non-presence of a "eQSL (AG)" field in any of the supported loggers is not checked. A station can be eQSL(AG) but not have confirmed the QSO. JTAlert looks for an eQSL specific confirmation field in the log. In the case od DXKeeper, it is the "APP_DXKeeper_EQSL_QSL_RCVD" field.

What does the QSO in question show? Is the
"APP_DXKeeper_EQSL_QSL_RCVD" set but the "AG" field does not indicate they are AG (I don't know its exact name without looking)? If they are not "AG" surely EQSL_QSL_RCVD should not be set. Or does DXKeeper now flag non-AG QSL as EQSL_QSL_RCVD?

de Laurie VK3AMA


locked Re: How JTAlert communicates with WSJT-Xand logger such as HRD

g4wjs
 

On 16/03/2021 13:42, N4FWD wrote:
I am trying to get JTAlert 2.16.17 to talk with WSJT-X 2.3.0. Both programs are running on Linux Mint 20.1. I seem to have hit a snag with the UDP server settings. Searching online, I have tried the 127.0.0.1:2237 with the three check-boxes enabled on the right side of that Reporting menu area.
JTAlert gives me the following alerts:
First window: Reading settings data
                       Standby
Second window: Waiting for WSJT-X to start
                            WSJT-X must be running before JTAlert can continue

I tried different versions of JTAlert and all of them give me the same alerts as above.

Any suggestions?
OM,

I was under the impression that JTAlert was a MS Windows only application, how are you running it on Linux?



--
73
Bill
G4WJS.


locked Re: How JTAlert communicates with WSJT-Xand logger such as HRD

Admin <n4fwd.ar@...>
 

I am trying to get JTAlert 2.16.17 to talk with WSJT-X 2.3.0. Both programs are running on Linux Mint 20.1. I seem to have hit a snag with the UDP server settings. Searching online, I have tried the 127.0.0.1:2237 with the three check-boxes enabled on the right side of that Reporting menu area.
JTAlert gives me the following alerts:
First window: Reading settings data
                       Standby
Second window: Waiting for WSJT-X to start
                            WSJT-X must be running before JTAlert can continue

I tried different versions of JTAlert and all of them give me the same alerts as above.

Any suggestions?


locked JT Alert with JTDX - setup

Andy M0NKR
 

Afternoon,

I am after some assistance in setting up JTALERT.

I use Logger32 as the logbook and currently have spots coming from JTDX to the UDPband map window within Logger32.

I've loaded the latest JT Alert along with database and sounds.

what do I need to config to get JT alert to see the spots as I receive nothing.

73
Andy
M0NKR


locked Re: Disappearing B4's in FT4

Richard Preece
 

Thanks Laurie, that fixed it.

Rich


locked Re: Double Logging Issue

Duncan Campbell
 

I am back home again, and am able to look at my JTAlert settings.
  If I have both "Enable DXLab DXKeeper Logging", under Logging, and DXLab DXKeeper.
AND
 have "Post decoded Callsigns to Spotcollector as local spots", under Applications, DXLab Suite.

checked, I will get double logging when I save a QSO.  Turning off one of these will stop it.
I have the Spotcollector one unchecked and it works fine.

73 de Duncan, KF6ILA

 


locked Re: JTAlert alternate gui display

bill@...
 

Laurie,

Thank you very much for your fast reply. I did not realize that these view settings were there! I assumed that you had 2 different views one x units high and a second one x+y units high and used some key or key combo to toggle between them. As a retired developer, I should have looked further. Great piece of software, and I appreciate being able to utilize such a well developed and tested program.

 

Thanks

Bill K2PAA

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: Monday, March 15, 2021 06:30 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] JTAlert alternate gui display

 

On 16/03/2021 7:35 am, bill@... wrote:

Can anyone tell me how to toggle between the full-screen display with all functions and the reduced display which only displays calls?

Probably something simple but not documented that I could find.

tnx K2PAA bill


JTAlert has never offered a full-screen display. Its size is hard-coded and only adjusts (vertically) if additional views are enable , like additional Callsign display rows, the Log Fields and the Confirmed Band display. Visibility of all these is controlled under the "View" menu of JTAlert.

de Laurie VK3AMA


locked Re: "Any Digital Mode" and Wanted Zone

Joe Subich, W4TV
 

Laurie,

Well ... I filtered my DXKeeper log for 30 meters and zone 12 then examined each digital QSO. Seems DXKeeper missed an eQSL
confirmation. I need to bounce this one back to Dave <G>.
On second look ... DXKeeper is correct. The eQSL confirmation is
by a station that it *NOT AG*. This it doesn't count for CQ WAZ.

Are you checking the "eQSL.cc member" field in DXKeeper for "A"
(AG status)?

73,

... Joe, W4TV

On 2021-03-15 7:00 PM, Joe Subich, W4TV wrote:
Laurie,

The "Any Digital Mode" tracking does exclude RTTY if the required
checkbox is enabled for the CQ Zone Alert under the "Rebuild Alert
Database" section of the Settings window.
The required checkbox is checked.

My only thoughts as to why JTAlert is not Alerting on a CQ zone that DXLab is is that JTAlert is looking at a different filtered view of
your Log compared to what DXLab is using.
DXKeeper does not filter the log for CQ WAZ  - all QTHs count as long
as they are in the same DXCC country.  All of my QTHs have been in the
same DXCC country.
Well ... I filtered my DXKeeper log for 30 meters and zone 12 then
examined each digital QSO.  Seems DXKeeper missed an eQSL confirmation.
I need to bounce this one back to Dave <G>.
73,
   ... Joe, W4TV
On 2021-03-15 6:27 PM, HamApps Support (VK3AMA) wrote:
On 14/03/2021 1:57 pm, Joe Subich, W4TV wrote:
I think there is an error in "Any Digital Mode" in Wanted Zones.

It appears that "Any Digital Mode" includes RTTY.  However, the
rules for CQ WAZ *exclude* RTTY from "Digital" (there is a separate
award for RTTY).

I noticed DXLab/SpotCollector calling out FT8 spots from my own
JTAlert feed on 30 meters but no alerts from JTAlert.  I tracked
it down (apparently) to a RTTY confirmation on that band.

73,

   ... Joe, W4TV
Joe,

The "Any Digital Mode" tracking does exclude RTTY if the required checkbox is enabled for the CQ Zone Alert under the "Rebuild Alert Database" section of the Settings window.



This has been in place for many years now. If I recall correctly this was first suggested by yourself.

I just now ran some tests. and cannot fault the behavior.

  * With an empty log, I ran the rebuild and all CQ zones were correctly
    set as needed.
  * A single RTTY QSO was added to the log and the rebuild rerun
    (without the ignore checkbox ticked). The zone was correctly flagged
    as no longer need under the "Any Mode" & "Any Digital Mode" sections
    of the CQ Alert.
  * The JTAlert setting for ignoring RTTY was enabled and the rebuild
    rerun. The "Any Digital Mode" section correctly changed accounting
    for the changed setting with the zone being flagged as needed.

My only thoughts as to why JTAlert is not Alerting on a CQ zone that DXLab is is that JTAlert is looking at a different filtered view of your Log compared to what DXLab is using. While the Log file may be the same, if you have multiple myQTH ID available in DXKeeper, you need to ensure that JTAlert is set to use myQTH IDs similar to DXLab. If you have no myQTH IDs set in JTAlert than the entire log is used for the rebuild.

Assuming you have the "Ignore RTTY" checkbox ticked, a search your log will likely uncover a digital mode QSO (not RTTY) for the Band that JTAlert did not alert on.

de Laurie VK3AMA


locked Re: "Any Digital Mode" and Wanted Zone

Joe Subich, W4TV
 

Laurie,

The "Any Digital Mode" tracking does exclude RTTY if the required
checkbox is enabled for the CQ Zone Alert under the "Rebuild Alert
Database" section of the Settings window.
The required checkbox is checked.

My only thoughts as to why JTAlert is not Alerting on a CQ zone that DXLab is is that JTAlert is looking at a different filtered view of
your Log compared to what DXLab is using.
DXKeeper does not filter the log for CQ WAZ - all QTHs count as long
as they are in the same DXCC country. All of my QTHs have been in the
same DXCC country.

Well ... I filtered my DXKeeper log for 30 meters and zone 12 then
examined each digital QSO. Seems DXKeeper missed an eQSL confirmation.
I need to bounce this one back to Dave <G>.

73,

... Joe, W4TV


On 2021-03-15 6:27 PM, HamApps Support (VK3AMA) wrote:
On 14/03/2021 1:57 pm, Joe Subich, W4TV wrote:
I think there is an error in "Any Digital Mode" in Wanted Zones.

It appears that "Any Digital Mode" includes RTTY.  However, the
rules for CQ WAZ *exclude* RTTY from "Digital" (there is a separate
award for RTTY).

I noticed DXLab/SpotCollector calling out FT8 spots from my own
JTAlert feed on 30 meters but no alerts from JTAlert.  I tracked
it down (apparently) to a RTTY confirmation on that band.

73,

   ... Joe, W4TV
Joe,
The "Any Digital Mode" tracking does exclude RTTY if the required checkbox is enabled for the CQ Zone Alert under the "Rebuild Alert Database" section of the Settings window.
This has been in place for many years now. If I recall correctly this was first suggested by yourself.
I just now ran some tests. and cannot fault the behavior.
 * With an empty log, I ran the rebuild and all CQ zones were correctly
   set as needed.
 * A single RTTY QSO was added to the log and the rebuild rerun
   (without the ignore checkbox ticked). The zone was correctly flagged
   as no longer need under the "Any Mode" & "Any Digital Mode" sections
   of the CQ Alert.
 * The JTAlert setting for ignoring RTTY was enabled and the rebuild
   rerun. The "Any Digital Mode" section correctly changed accounting
   for the changed setting with the zone being flagged as needed.
My only thoughts as to why JTAlert is not Alerting on a CQ zone that DXLab is is that JTAlert is looking at a different filtered view of your Log compared to what DXLab is using. While the Log file may be the same, if you have multiple myQTH ID available in DXKeeper, you need to ensure that JTAlert is set to use myQTH IDs similar to DXLab. If you have no myQTH IDs set in JTAlert than the entire log is used for the rebuild.
Assuming you have the "Ignore RTTY" checkbox ticked, a search your log will likely uncover a digital mode QSO (not RTTY) for the Band that JTAlert did not alert on.
de Laurie VK3AMA


locked Re: JTAlert alternate gui display

HamApps Support (VK3AMA)
 

On 16/03/2021 7:35 am, bill@... wrote:
Can anyone tell me how to toggle between the full-screen display with all functions and the reduced display which only displays calls?

Probably something simple but not documented that I could find.

tnx K2PAA bill

JTAlert has never offered a full-screen display. Its size is hard-coded and only adjusts (vertically) if additional views are enable , like additional Callsign display rows, the Log Fields and the Confirmed Band display. Visibility of all these is controlled under the "View" menu of JTAlert.

de Laurie VK3AMA


locked Re: "Any Digital Mode" and Wanted Zone

HamApps Support (VK3AMA)
 

On 14/03/2021 1:57 pm, Joe Subich, W4TV wrote:
I think there is an error in "Any Digital Mode" in Wanted Zones.

It appears that "Any Digital Mode" includes RTTY.  However, the
rules for CQ WAZ *exclude* RTTY from "Digital" (there is a separate
award for RTTY).

I noticed DXLab/SpotCollector calling out FT8 spots from my own
JTAlert feed on 30 meters but no alerts from JTAlert.  I tracked
it down (apparently) to a RTTY confirmation on that band.

73,

   ... Joe, W4TV

Joe,

The "Any Digital Mode" tracking does exclude RTTY if the required checkbox is enabled for the CQ Zone Alert under the "Rebuild Alert Database" section of the Settings window.

   

This has been in place for many years now. If I recall correctly this was first suggested by yourself.

I just now ran some tests. and cannot fault the behavior.
  • With an empty log, I ran the rebuild and all CQ zones were correctly set as needed.
  • A single RTTY QSO was added to the log and the rebuild rerun (without the ignore checkbox ticked). The zone was correctly flagged as no longer need under the "Any Mode" & "Any Digital Mode" sections of the CQ Alert.
  • The JTAlert setting for ignoring RTTY was enabled and the rebuild rerun. The "Any Digital Mode" section correctly changed accounting for the changed setting with the zone being flagged as needed.

My only thoughts as to why JTAlert is not Alerting on a CQ zone that DXLab is is that JTAlert is looking at a different filtered view of your Log compared to what DXLab is using. While the Log file may be the same, if you have multiple myQTH ID available in DXKeeper, you need to ensure that JTAlert is set to use myQTH IDs similar to DXLab. If you have no myQTH IDs set in JTAlert than the entire log is used for the rebuild.

Assuming you have the "Ignore RTTY" checkbox ticked, a search your log will likely uncover a digital mode QSO (not RTTY) for the Band that JTAlert did not alert on.

de Laurie VK3AMA


locked Re: Start problem Subscript used on non-accessible variable

Frank IZ7AUH
 

thank you for your answer, I apologize for the delay in my reply, this error does not appear often, I wish I could solve it and I am aware that it is not a JTALERT error I am looking for a solution and I update you on this, thanks, I hope one day  you can also support MSHV other nice software

IZ7AUH 


On Wed, Mar 3, 2021 at 03:57 PM, HamApps Support (VK3AMA) wrote:

This is a new type of error. I don't recall ever seeing this specific error reported.
The line number referenced is within the block of code that gets a list of running processes on the PC in order to find the wsjt-x processes and assign the JTAlert instance to the appropriate wsjtx instance (based on how long the wsjtx process has been running). This code has not changed for many years now, so I am reasonably confident the error is not caused by a coding error. Deleting files in the users appdata directory will have no effect as this block of code doesn't access any files.

My best guess is that your PC protection software is interfering. You may need to take steps to mark JTAlert and its files/directories as safe.


locked JTAlert alternate gui display

bill@...
 

Can anyone tell me how to toggle between the full-screen display with all functions and the reduced display which only displays calls?

Probably something simple but not documented that I could find.

tnx K2PAA bill


locked Re: DX Atlas

Dave Garber
 

I was kind of wondering what fhis had to do with hamapps or dxatlas


On Mon., Mar. 15, 2021, 2:38 p.m. Larry Banks via groups.io, <larryb.w1dyj=verizon.net@groups.io> wrote:
I assume you were discussing DXMaps.

73 -- Larry -- W1DYJ

 
From: Craig
Sent: Monday, March 15, 2021 14:07
Subject: Re: [HamApps] DX Atlas
 
Hi Larry - where is that specific  "Select Options" located? Which App?
Thanks,

Craig
NZ4CW


locked Re: DX Atlas

Larry Banks
 

I assume you were discussing DXMaps.

73 -- Larry -- W1DYJ

 

From: Craig
Sent: Monday, March 15, 2021 14:07
Subject: Re: [HamApps] DX Atlas
 
Hi Larry - where is that specific  "Select Options" located? Which App?
Thanks,

Craig
NZ4CW


locked Re: DX Atlas

Craig
 

Hi Larry - where is that specific  "Select Options" located? Which App?
Thanks,

Craig
NZ4CW

2781 - 2800 of 36176