Date   

locked Re: JT Alert with JTDX - setup

Andy M0NKR
 

Thanks for the help!


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

d_ziolkowski
 

"Just my opinion, Python and N3FJP Logging software do a better job of logging and alerting."

compared to what?

Dan KC2STA

On Wed, Mar 17, 2021 at 5:28 PM N4FWD <n4fwd.ar@...> wrote:
After much testing and trying different approaches to the communication problem, I have to agree with the author that JTAlert will never be ported to Linux or MacOS. From what I have been able to determine, JTAlert does all the setup programmically (ie. the Microsoft way of doing things). Porting such a program would entail a major re-write of the internals.

Thank you to all who assisted me with this experiment. Just my opinion, Python and N3FJP Logging software do a better job of logging and alerting.



--
Dan Ziolkowski KC2STA
SKCC #4290T
Ubuntu LINUX


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

HamApps Support (VK3AMA)
 

On 18/03/2021 6:31 am, N4FWD wrote:
Thank you for the insight into where JTAlert is looking for its "flag" that wsjtx is installed.

FYI, JTAlert doesn't go looking for the WSJT-X config (.ini) file until it has detected a running instance of WSJT-X running on the local machine.
If WSJT-X is not detected running on the local PC, JTAlert never goes looking for the .ini file, it waits until WSJT-X is started.

de Laurie VK3AMA
 


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

HamApps Support (VK3AMA)
 

On 17/03/2021 10:29 pm, N4FWD wrote:
I have surmised is that JTAlert is using a different Microsoft method to determine that wsjtx is running.

JTAlert at startup enumerates the running wsjtx.exe processes running on the local machine. It does this so that it can provide a zero-setup experience for the end-user (for the JTAlert<->WSJT-X interaction). Enumerating the running processes is also critical in providing automatic multi-instance support (again with zero settings).

de Laurie VK3AMA


locked Re: "Any Digital Mode" and Wanted Zone

Laurie, VK3AMA
 

On 18/03/2021 12:06 am, Joe Subich, W4TV wrote:
<App_DXKeeper_EQSL_RCVD> is 'Y' because the QSO has been confirmed in
eQSL.

<APP_DXKeeper_EQSL_MEMBER> is "Y" because the station is an eQSL member
but has not supplied the necessary documentation for AG status. If the
station would supply the documentation, <APP_DXKeeper_EQSL_MEMBER>
would be "A".

The problem is the eQSL confirmation is not valid for WAZ because the
station is not AG.

DXKeeper has always identified *all* eQSL confirmations as EQSL_QSL_RCVD
= 'Y' consistent with ADIF.  DXKeeper only *counts* eQSL confirmations
if EQSL_MEMBER = 'A'.

73,

   ... Joe, W4TV
OK Jo9e.

I was unaware that DXKeeper flagged non-AG QSLs as confirmed.

I will need to extend JTAlert to account for that.

de Laurie VK3AMA


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

N4FWD <n4fwd.ar@...>
 

After much testing and trying different approaches to the communication problem, I have to agree with the author that JTAlert will never be ported to Linux or MacOS. From what I have been able to determine, JTAlert does all the setup programmically (ie. the Microsoft way of doing things). Porting such a program would entail a major re-write of the internals.

Thank you to all who assisted me with this experiment. Just my opinion, Python and N3FJP Logging software do a better job of logging and alerting.


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

N4FWD <n4fwd.ar@...>
 

Mike W9MDB, Thank you for the insight into where JTAlert is looking for its "flag" that wsjtx is installed. 


locked Re: "Any Digital Mode" and Wanted Zone

Joe Subich, W4TV
 

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?
<App_DXKeeper_EQSL_RCVD> is 'Y' because the QSO has been confirmed in
eQSL.

<APP_DXKeeper_EQSL_MEMBER> is "Y" because the station is an eQSL member
but has not supplied the necessary documentation for AG status. If the
station would supply the documentation, <APP_DXKeeper_EQSL_MEMBER>
would be "A".

The problem is the eQSL confirmation is not valid for WAZ because the
station is not AG.

DXKeeper has always identified *all* eQSL confirmations as EQSL_QSL_RCVD
= 'Y' consistent with ADIF. DXKeeper only *counts* eQSL confirmations
if EQSL_MEMBER = 'A'.

73,

... Joe, W4TV


On 2021-03-16 11:31 PM, HamApps Support (VK3AMA) wrote:
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

Michael Black
 

It's looking for the WSJT-X.ini file to get the port settings.

The path would be %LOCALAPPDATA%\WSJT-X\WSJT-X.ini

Where the WSJT-X directory also includes the -r switch of WSJT-X if used.  So "wsjtx -r test" would be "WSJT-X - test"

So you need to figure out where %LOCALAPPDATA% is and probably do a hard link to WSJT-X.ini

Found this info that should help.

The Application Data folder is saved in the APPDATA environment variable.

You can see its value by running: (a weird combination of wine and Unix  )
wine cmd /c set|grep APPDATA

The output you recieve should look like this:
APPDATA=C:\windows\profiles\mohag\Application Data
LOCALAPPDATA=C:\windows\profiles\mohag\Local Settings\Application Data

The physical folder would then be
~/.wine/drive_c/windows/profiles/`whoami`/Application" "Data


Mike W9MDB

On Wednesday, March 17, 2021, 06:29:42 AM CDT, N4FWD <n4fwd.ar@...> wrote:


In answer to the question "how are you running it on Linux?", WINE 6.4 and some Microsoft components.
More information:
 Using various networking tools, I determined that initially, JTAlert does not listen to port 2237 on address 127.0.0.1. I have surmised is that JTAlert is using a different Microsoft method to determine that wsjtx is running.
I can see that wsjtx is sending the UDP packets to 127.0.0.1:2237. I can see the JTAlert is opening listening ports. I do not see a listening port being opened on 127.0.0.1:2237.

It is a shame that JTAlert is locked down to Microsoft as it looks like a great program.


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

N4FWD <n4fwd.ar@...>
 

There is no need to port JTAlert to Linux or MacOS. Instead of looking for wsjtx, if JTAlert would simply listen for UDP packets on 127.0.0.1:2237 as the documentation says, then I believe that it would work just fine.


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

N4FWD <n4fwd.ar@...>
 

In answer to the question "how are you running it on Linux?", WINE 6.4 and some Microsoft components.
More information:
 Using various networking tools, I determined that initially, JTAlert does not listen to port 2237 on address 127.0.0.1. I have surmised is that JTAlert is using a different Microsoft method to determine that wsjtx is running.
I can see that wsjtx is sending the UDP packets to 127.0.0.1:2237. I can see the JTAlert is opening listening ports. I do not see a listening port being opened on 127.0.0.1:2237.

It is a shame that JTAlert is locked down to Microsoft as it looks like a great program.


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

4401 - 4420 of 37807