Date   

locked Re: Potential For Lost JTAlert Functionality By Directly Updating HRD Logbook Via WSJTX ? #HRD

HamApps Support (VK3AMA)
 

On 20/05/2021 11:12 am, n3ps via groups.io wrote:
I find that ~ 5% of my logbook updates via JTAlert aren't 100% (missing parts of name and/or address or contain some weird characters).  They are correctable after entry by initiating a Lookup within HRD Logbook (as HRD pulls the info from a multiple sources), so I thought about just using UDP broadcast which would result in HRD doing the lookup as part of the logbook update.

I do rely heavily on the Worked B4 and Alert function within JT Alert, so I will continue doing the logbook updates via JT Alert . . .

--
Paul / N3PS

Paul,

If there is data missing from the QSOs logged by JTAlert that is something I would like to investigate. When you note a newly logged QSO with incomplete or inaccurate values send me a support request via the "Help" -> "Contact Support" menu, on the main JTAlert window. Include a note of the Callsign affected and the data problem.

de Laurie VK3AMA



locked Re: Potential For Lost JTAlert Functionality By Directly Updating HRD Logbook Via WSJTX ? #HRD

Paul N3PS
 

Thanks for the explanation Laurie.

I find that ~ 5% of my logbook updates via JTAlert aren't 100% (missing parts of name and/or address or contain some weird characters).  They are correctable after entry by initiating a Lookup within HRD Logbook (as HRD pulls the info from a multiple sources), so I thought about just using UDP broadcast which would result in HRD doing the lookup as part of the logbook update.

I do rely heavily on the Worked B4 and Alert function within JT Alert, so I will continue doing the logbook updates via JT Alert . . .

--
Paul / N3PS


locked Re: JTAlert talking to WSJT and JTDX

HamApps Support (VK3AMA)
 

On 20/05/2021 2:19 am, Dave Garber wrote:
Aclog uses the api on port 1100.   And jtalert should be set to that port and correct log file..   I did try it using the multicast.    Cant remember if it worked
FYI, JTAlert does use the port 1100 API for interaction with ACLog.

The original poster was having issues where the UDP server in WSJT-X was setup for unicast and ACLog was taking ownership of the UDP port preventing JTAlert from interacting with WSJT-X.

In the situation where 2 or more applications need to interact with WSJT-X concurrently, WSJT-X needs to be set to use multicast UDP and all applications wanting to work with WSJT-X will similarly need to changed over to using multicast. For JTAlert, that changeover is simple, a simple tick of a menu entry, all other settings like the correct multicast address and port are automatically determined by JTAlert. I don't know how or if ACLog can use multicast in their newly released ACLog 7.

de Laurie VK3AMA


locked Re: Question On Logging Config Items

HamApps Support (VK3AMA)
 

On 19/05/2021 3:37 am, n3ps via groups.io wrote:
Ham Radio Deluxe is recommending to use their UDP Broadcast set up (as opposed to TCP) to take in the QSO and let HRD Logbook do the address lookups.   If I were to follow their recommendations, what functionality would I be loosing within JT Alert?
--
Paul / N3PS

Paul,

see my response to your other thread --> https://hamapps.groups.io/g/Support/message/35124

de Laurie VK3AMA


locked Re: Potential For Lost JTAlert Functionality By Directly Updating HRD Logbook Via WSJTX ? #HRD

HamApps Support (VK3AMA)
 

On 20/05/2021 2:45 am, n3ps via groups.io wrote:
I am currently running the most current versions of WSJTX, JTAlert and HRD Logbook.

I initially installed JT Alert to support QSO logging from WSJTX to HRD Logbook (via the TCP/IP API).  However, HRD Logbook recently implemented support to allow QSOs to be logged directly from WSJTX (via UDP Broadcast) without the need to use JTAlert as the middleman.

I am trying to determine if I take advantage of the recently implemented support to allow WSJTX to update HRD Logbook directly (via UDP Broadcast), will I be loosing any other JT Alert functionality that is mission critical to my FT4/FT8 operations (e.g., Worked B4, Wanted Alerts, etc)?

--
Paul / N3PS

Paul,

I wouldn't categorize the use of the WSJT-X "Secondary UDP Server (depreciated)" by HRD to log QSOs as a recent implementation. That has been happening for quite some time and has been the cause of numerous duplicate logging complaints.

If you want to log QSOs directly into HRDLogbook without JTAlert you will need to turn off HRD logging in JTAlert to avoid duplicate log entries. Turning off logging in JTAlert has a number of consequences.
  • You loose the ability for accurate B4 reporting by JTAlert, especially if QSOs have been logged to HRDLogbook while JTAlert has not been running. In that situation JTAlert will never be aware of those new QSOs unless you take steps to perform manual adif imports into the JTAlert internal B4 database (which is used when logging is disabled).

  • The ability to automate the JTAlert Alert database rebuild with your needs for the many different Alert types is lost completely and all Alerts will need to be manually updated whenever you confirm entities via QSL card or Lotw/Eqsl confirmations. Two of the Alert types, Grids & Prefixes, cannot be manually updated and are only updated via the rebuild process which involves scanning the logbook, which cannot happen if logging is disabled.

  • The logging of xml lookup data of your QSO partner is lost with logging disabled.

  • The ability to pre-enter or modify QSO data prior to logging via the log fields area of JTAlert is lost with logging disabled.

Honestly, I don't see much value in running JTAlert with logging disabled which will need to happen if you wish to log directly from WSJT-X to HRDLogbook.

I don't see any downside in letting JTAlert perform the logging into HRD, except for one, HRDSupport have a dislike for JTAlert and tend to point the finger at JTAlert when a user tries to get a problem in HRD resolved. The mere mention of JTAlert is enough for some in HRDSupport to dismiss the complaint as a JTAlert issue without any attempt at resolution. This has happened numerous times, despite the problem having been clearly isolated to within the HRD suite. But that is not a technical issue that should influence the decision to  use WSJT-x -> JTAlert -> HRDLogbook  for logging.

de Laurie VK3AMA


locked Re: JTAlert talking to WSJT and JTDX

JoAnn Donaldson <joannplano2005@...>
 

You no longer need to use JTAlert to log to ACLog. In both JTDX and WSJTX just point the UDP to the ACLogger server address but use 2237 as the port.

JoAnn
AB8YZ

On Wednesday, May 19, 2021, 11:19:32 AM CDT, Dave Garber <ve3wej@...> wrote:


Aclog uses the api on port 1100.   And jtalert should be set to that port and correct log file..   I did try it using the multicast.    Cant remember if it worked

On Wed., May 19, 2021, 12:01 a.m. Bill Gillenwater, <k3sv@...> wrote:

Mike,

That seems to have fixed things. I will work a little more tonight to verify that it's working on both JTDX and WSJT, with my logger and with JTAlert running.

Help very much appreciated.

73 Bill K3SV

On 5/18/2021 11:22 PM, Michael Black via groups.io wrote:
It sounds like you have your logger listening on the same port as JTAlert.
So whichever starts first wins.

You probably want to set up JTAlert to forward the packets and set your logger to receive on port 2334 (the default you see below)

Inline image

Mike W9MDB



On Tuesday, May 18, 2021, 10:17:20 PM CDT, Bill Gillenwater <k3sv@...> wrote:


More info.
If I start WSJT and then JTAlert without starting a logging program, I get the JTAlert screen that alerts me to callers and needed calls, etc.

If I then start a logger and try to log a contact, it does not work.

If I start the logger first and then WSJT and JTAlert, I can do the logging with not problem, but I get messages that JTAlert is not talking to WSJT.

Need assist on this. It's probably simple, it's just eluding me.

73 Bill K3SV


locked Potential For Lost JTAlert Functionality By Directly Updating HRD Logbook Via WSJTX ? #HRD

Paul N3PS
 

I am currently running the most current versions of WSJTX, JTAlert and HRD Logbook.

I initially installed JT Alert to support QSO logging from WSJTX to HRD Logbook (via the TCP/IP API).  However, HRD Logbook recently implemented support to allow QSOs to be logged directly from WSJTX (via UDP Broadcast) without the need to use JTAlert as the middleman.

I am trying to determine if I take advantage of the recently implemented support to allow WSJTX to update HRD Logbook directly (via UDP Broadcast), will I be loosing any other JT Alert functionality that is mission critical to my FT4/FT8 operations (e.g., Worked B4, Wanted Alerts, etc)?

--
Paul / N3PS


locked Re: JTAlert talking to WSJT and JTDX

Dave Garber
 

Aclog uses the api on port 1100.   And jtalert should be set to that port and correct log file..   I did try it using the multicast.    Cant remember if it worked


On Wed., May 19, 2021, 12:01 a.m. Bill Gillenwater, <k3sv@...> wrote:

Mike,

That seems to have fixed things. I will work a little more tonight to verify that it's working on both JTDX and WSJT, with my logger and with JTAlert running.

Help very much appreciated.

73 Bill K3SV

On 5/18/2021 11:22 PM, Michael Black via groups.io wrote:
It sounds like you have your logger listening on the same port as JTAlert.
So whichever starts first wins.

You probably want to set up JTAlert to forward the packets and set your logger to receive on port 2334 (the default you see below)

Inline image

Mike W9MDB



On Tuesday, May 18, 2021, 10:17:20 PM CDT, Bill Gillenwater <k3sv@...> wrote:


More info.
If I start WSJT and then JTAlert without starting a logging program, I get the JTAlert screen that alerts me to callers and needed calls, etc.

If I then start a logger and try to log a contact, it does not work.

If I start the logger first and then WSJT and JTAlert, I can do the logging with not problem, but I get messages that JTAlert is not talking to WSJT.

Need assist on this. It's probably simple, it's just eluding me.

73 Bill K3SV


locked Re: JTAlert talking to WSJT and JTDX

Bill Gillenwater
 

Mike,

That seems to have fixed things. I will work a little more tonight to verify that it's working on both JTDX and WSJT, with my logger and with JTAlert running.

Help very much appreciated.

73 Bill K3SV

On 5/18/2021 11:22 PM, Michael Black via groups.io wrote:
It sounds like you have your logger listening on the same port as JTAlert.
So whichever starts first wins.

You probably want to set up JTAlert to forward the packets and set your logger to receive on port 2334 (the default you see below)



Mike W9MDB



On Tuesday, May 18, 2021, 10:17:20 PM CDT, Bill Gillenwater <k3sv@...> wrote:


More info.
If I start WSJT and then JTAlert without starting a logging program, I get the JTAlert screen that alerts me to callers and needed calls, etc.

If I then start a logger and try to log a contact, it does not work.

If I start the logger first and then WSJT and JTAlert, I can do the logging with not problem, but I get messages that JTAlert is not talking to WSJT.

Need assist on this. It's probably simple, it's just eluding me.

73 Bill K3SV


locked Re: JTAlert talking to WSJT and JTDX

Michael Black
 

It sounds like you have your logger listening on the same port as JTAlert.
So whichever starts first wins.

You probably want to set up JTAlert to forward the packets and set your logger to receive on port 2334 (the default you see below)

Inline image

Mike W9MDB



On Tuesday, May 18, 2021, 10:17:20 PM CDT, Bill Gillenwater <k3sv@...> wrote:


More info.
If I start WSJT and then JTAlert without starting a logging program, I get the JTAlert screen that alerts me to callers and needed calls, etc.

If I then start a logger and try to log a contact, it does not work.

If I start the logger first and then WSJT and JTAlert, I can do the logging with not problem, but I get messages that JTAlert is not talking to WSJT.

Need assist on this. It's probably simple, it's just eluding me.

73 Bill K3SV


locked Re: JTAlert talking to WSJT and JTDX

Bill Gillenwater
 

More info.
If I start WSJT and then JTAlert without starting a logging program, I get the JTAlert screen that alerts me to callers and needed calls, etc.

If I then start a logger and try to log a contact, it does not work.

If I start the logger first and then WSJT and JTAlert, I can do the logging with not problem, but I get messages that JTAlert is not talking to WSJT.

Need assist on this. It's probably simple, it's just eluding me.

73 Bill K3SV


locked JTAlert talking to WSJT and JTDX

Bill Gillenwater
 

I cannot get JTAlert to talk to either WSJT or JTDX.

I am using the 127.0.0.1     2237     UDP port to do logging in N3FJP logger.

How do I set up another avenue to talk to JTAlert?

Thanks,  73 Bill K3SV


locked Re: Question On Logging Config Items

Paul N3PS
 

Laurie,

Ham Radio Deluxe is recommending to use their UDP Broadcast set up (as opposed to TCP) to take in the QSO and let HRD Logbook do the address lookups.   If I were to follow their recommendations, what functionality would I be loosing within JT Alert?
--
Paul / N3PS


locked Re: Question On Logging Config Items

HamApps Support (VK3AMA)
 

On 18/05/2021 1:05 am, n3ps via groups.io wrote:
Within Logging settings, I am trying to understand the difference between two config items "Log Full QTH Returned From XML Lookups" and  "Log Address Returned From An XML Or Previous QSO Lookup".  It would seem they both control the same function.  Help me get my head around this . . .

--
Paul / N3PS

The QTH and Address are two different items in most logging programs, including the ADIF standard. The Address is typically the address to which QSLs are sent. Some users want that additional data recorded with each QSO, but many don't (myself included) so it is an option. The QTH logged can be either the full QTH returned from an XML data feed or a shortened version where JTAlert attempt to extract a Town/City name from the xml data which can often not contain a dedicated QTH field so the address field is used to try and get the QTH.

de Laurie VK3AMA


locked Re: JTAlert 2.50.1 running with WSJT-X v2.3.1 #FT8

Laurie, VK3AMA
 

On 18/05/2021 9:10 am, Grouch wrote:
Windows 10 Pro on ACPI x64-based desktop Intel Core 05-6400 @2.70GHz.  I downloaded and upgraded to JTAlert 2.50.1.  for use with WSJT-X v2.3.1 and JTDX v.2.2.156When I call the program the correct windows open and it interacts correctly and functions with WSJT-X showing the activity and filters.  However,  the main "Alerts Settings View Sound Help"  window just disappears within 2 minutes and the other windows freeze.  In Task Manager the following are listed "Audio & Visual Alerts for WSTX-32bit Decodes, JTAlert V2 Manager - GPU 0-3D.  When I check each is shown as "Disabled. This occurs each time the main drops from view on the screen and taskbar. This happens if it is running with HRD for rig control or independently.  The same same occurs with JTDX v2.2.156 with JTAlert for JTDX.  Each time the same Autoit Error appears "Line 10382 (file "C:\Program Files ((X86)HamApps\JTAlert\JTAlert.exe): Error: Variable used without being declared.  I have done clean re-installs of all these software packages and checked the "permissions" in the system. I have even run the install as Current User" I am the administrator and "run as Adminstrator." NOTE: I had no problem with the previous version 2.16.6   I am about to pull out what hair I have left.
OM (Name?, Callsign?)

I can understand JTAlert.exe showing as disabled if there has been an AutoIT error, but not JTAlertV2.Manager.exe. Sounds like your Protection software is interfering.

Another possibility is something unusual with your old version JTAlert config file, but that will not cause the Manager process to become disabled. Worth trying is starting JTAlert without a config file. Try shutting down JTAlert, deleting (or relocating) the config.sqlite file, then starting JTAlert without a config file (a new one will automatically be created). The config file, config.sqlite can be found at %localappdata%\HamApps\<YOUR_CALLSIGN>\config\JTAlertX\

Let me know your results.

de Laurie VK3AMA


locked JTAlert 2.50.1 running with WSJT-X v2.3.1 #FT8

Grouch
 

Windows 10 Pro on ACPI x64-based desktop Intel Core 05-6400 @2.70GHz.  I downloaded and upgraded to JTAlert 2.50.1.  for use with WSJT-X v2.3.1 and JTDX v.2.2.156When I call the program the correct windows open and it interacts correctly and functions with WSJT-X showing the activity and filters.  However,  the main "Alerts Settings View Sound Help"  window just disappears within 2 minutes and the other windows freeze.  In Task Manager the following are listed "Audio & Visual Alerts for WSTX-32bit Decodes, JTAlert V2 Manager - GPU 0-3D.  When I check each is shown as "Disabled. This occurs each time the main drops from view on the screen and taskbar. This happens if it is running with HRD for rig control or independently.  The same same occurs with JTDX v2.2.156 with JTAlert for JTDX.  Each time the same Autoit Error appears "Line 10382 (file "C:\Program Files ((X86)HamApps\JTAlert\JTAlert.exe): Error: Variable used without being declared.  I have done clean re-installs of all these software packages and checked the "permissions" in the system. I have even run the install as Current User" I am the administrator and "run as Adminstrator." NOTE: I had no problem with the previous version 2.16.6   I am about to pull out what hair I have left.


locked Re: Single/double click within callsigns window not working

Steve Masticola
 

> The WSJT-X API needs to be extended to set TX enabled on non-CQ decodes in response to a UDP Reply command (# 4) from external applications.

OK, in that case, would you mind filing either a bug fix or a feature request against WSJT-X? I could do it, but I know zero about the WSJT-X API.

73, -Steve WX2S


locked Re: How Does JT Alert Update HRD Logbook?

HamApps Support (VK3AMA)
 

On 18/05/2021 1:13 am, g4wjs wrote:
I believe mechanism for the current version of HRD is that JTAlert uses the HRD TCP/IP server API to enter QSOs. That means that the internal logic of HRD to derive fields is used. I also believe worked before queries are made by direct read-only access to the HRD logbook database tables, this probably because HRD logbook doesn't provide any mechanism to look up arbitrary QSO details.

Before the HRD logbook TCP/IP API worked properly (pre v6) I believe the only way for JTAlert to enter new QSOs was to directly insert records into he HRD logbook database tables.

-- 
73
Bill
G4WJS.

All that is correct. Tnx Bill.

de Laurie VK3AMA


locked Re: Single/double click within callsigns window not working

HamApps Support (VK3AMA)
 

On 18/05/2021 3:39 am, Michael Black via groups.io wrote:
I guess that got changed...good to know...


Not in my tests, WSJT-X (2.3.1) is not going into TX on non-CQ Callsigns clicked in JTAlert.

de Laurie VK3AMA


locked Re: Single/double click within callsigns window not working

HamApps Support (VK3AMA)
 

On 18/05/2021 3:34 am, Steve Masticola wrote:
Not correct. I just double-clicked a random station not calling CQ in WSJT-X and it enabled TX.

73, -Steve WX2S

That's because you double-clicked the decode in WSJT-X, NOT JTAlert. If you performed the click action on a non-CQ Callsign in JTAlert, WSJT-X does not got into TX. I just now repeated that test with WSJT-X 2.3.1

The decision to go into TX is controlled by WSJT-X, there is nothing in the command sent from JTAlert that can instruct WSJT-X to go into TX.

The WSJT-X API needs to be extended to set TX enabled on non-CQ decodes in response to a UDP Reply command
(# 4) from external applications.

de Laurie VK3AMA



2901 - 2920 of 37779