Date   

locked Re: Off topic? - Does anyone have JTAlert working with GridTracker?

Tom Melvin
 

Set WSJT-X to use Multi-cast address  (e.g. 239.255.0.0), JTA will pick that up automatically, set GT to use same address 

That’s it - all will just work.

Tom

--
73

Tom
GM8MJV (IO85)





On 16 Sep 2020, at 14:39, cqk2rma@... wrote:

If so, can you provide the necessary configuration settings to JTA and GridTracker?

For what it's worth, this is the first time I am trying out GridTracker. I love JTA, but want to see if running both programs brings me any more joy.

Roy K2RMA


locked Off topic? - Does anyone have JTAlert working with GridTracker?

cqk2rma@...
 

If so, can you provide the necessary configuration settings to JTA and GridTracker?

For what it's worth, this is the first time I am trying out GridTracker. I love JTA, but want to see if running both programs brings me any more joy.

Roy K2RMA


locked Re: subscribe

Tim
 

Welcome Susan. Lots of good stuff here. Very educational and a great group of people on this Groups I.O . Enjoy!

Tim - N8NEU
FN00ah



-------- Original message --------
From: AI4VV <sseaford@...>
Date: 9/14/20 15:55 (GMT-05:00)
To: Support@HamApps.groups.io
Subject: [HamApps] subscribe

I would like to subscribe to the group.

Susan


locked Re: System monitor tray icon

ROBERT NORRIS
 

Try System Explorer. Not sure it is what you are looking for but it does show you what is going on with your system and its memory.

 

Bob  AK5U

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of Marion D. Kitchens
Sent: Tuesday, September 15, 2020 7:43 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] System monitor tray icon

 

Look for something called TrayStatus  -- I think.  That is what it is called after installation on my computer.

 

On Tue, 15 Sep 2020 17:03:57 -0700 "Mike N8FRI" <mmhorn@...> writes:

Not too long ago someone in this group suggested a freeware system resource monitor that included a tray icon to track program memory usage.
I lost that program and cannot remember its name.  Can anyone refresh my memory?
Mike N8FRI

 


locked Re: System monitor tray icon

Marion D. Kitchens
 


Look for something called TrayStatus  -- I think.  That is what it is called after installation on my computer.
 
On Tue, 15 Sep 2020 17:03:57 -0700 "Mike N8FRI" <mmhorn@...> writes:

Not too long ago someone in this group suggested a freeware system resource monitor that included a tray icon to track program memory usage.
I lost that program and cannot remember its name.  Can anyone refresh my memory?
Mike N8FRI
 


locked System monitor tray icon

Mike N8FRI
 

Not too long ago someone in this group suggested a freeware system resource monitor that included a tray icon to track program memory usage.
I lost that program and cannot remember its name.  Can anyone refresh my memory?
Mike N8FRI


locked Re: Lost bottom half of JTALert

JoAnn Donaldson
 

thank you. I don't know how I unchecked that but again Thank you.

JoAnn Donaldson - AB8YZ

On Monday, September 14, 2020, 9:28:02 PM CDT, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 15/09/2020 12:22 pm, JoAnn Donaldson via groups.io wrote:
All of a sudden the bottom half of my JTALert disappeared.


JTAlert menu, "View -> Show Log Fields".



locked Re: Decodes window and chrome remote desktop

Michael Black
 

Laurie,
My LOTWQSL application started getting this error not too long ago.  

A couple of solutions are here

Mike






On Monday, September 14, 2020, 10:21:22 PM CDT, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 14/09/2020 11:47 pm, rogich via groups.io wrote:
Anywhere on decode window crashes it.

I also restart jtalert every time it crashes just decode window.

Thanks for posting the actual error, that helped isolate the problem.

A google search confirms this common problem with Chrome and other VNC type apps.

I have modified the code to capture the error and perform a retry when pasting the decodes callsign onto the clipboard. Check your email (in about an hour) I will send a new JTAlert build to test.

Also, when this happens, there is no need to restart JTAlert. The Decodes window is a standalone executable so you only need to reopen it from JTAlert.

de Laurie VK3AMA


locked Re: Decodes window and chrome remote desktop

HamApps Support (VK3AMA)
 

On 14/09/2020 11:47 pm, rogich via groups.io wrote:
Anywhere on decode window crashes it.

I also restart jtalert every time it crashes just decode window.

Thanks for posting the actual error, that helped isolate the problem.

A google search confirms this common problem with Chrome and other VNC type apps.

I have modified the code to capture the error and perform a retry when pasting the decodes callsign onto the clipboard. Check your email (in about an hour) I will send a new JTAlert build to test.

Also, when this happens, there is no need to restart JTAlert. The Decodes window is a standalone executable so you only need to reopen it from JTAlert.

de Laurie VK3AMA


locked Re: JtAlert call sign colors

HamApps Support (VK3AMA)
 

On 15/09/2020 2:49 am, Gerald Klotz wrote:
Laurie before I go and mess anything else up, do I delete that via the software or is it a file I need to located in a folder?
You have to manually delete the config file after first stopping JTAlert.

Refer to my original post https://hamapps.groups.io/g/Support/message/31591
The help file topic referenced in that post tells you where your config file is located.

de Laurie VK3AMA


locked Re: Lost bottom half of JTALert

HamApps Support (VK3AMA)
 

On 15/09/2020 12:22 pm, JoAnn Donaldson via groups.io wrote:
All of a sudden the bottom half of my JTALert disappeared.


JTAlert menu, "View -> Show Log Fields".



locked Lost bottom half of JTALert

JoAnn Donaldson
 

Inline image

All of a sudden the bottom half of my JTALert disappeared.

JoAnn Donaldson - AB8YZ


locked Re: Timing Adjustment.

JoAnn Donaldson
 

This is my last entry on this. Under Misc Alerts, I unclicked  "Remove spaces from "Callsign - B4" hyphen separator. JTAlert no longer reported Calls -B4 in the Alert box and I no longer got the message from ACLog.

As far as I am concern this message thread is no dead. I no longer have a problem logging FT8/FT4 contacts from WSIT-X.  Please Moderators shut down this thread.

JoAnn Donaldson - AB8YZ

On Monday, September 14, 2020, 3:14:45 PM CDT, Laurie, VK3AMA <hamapps.support@...> wrote:




On 15/09/2020 3:52 am, JoAnn Donaldson via groups.io wrote:
> I turned OFF CHECK BEFORE and now it logs successfully.

How are you turning off the B4 check in JTAlert?
It is not possible, it is permanently enabled, there is not setting for
turning B4 checks off.

What did you change that made logging work?

de Laurie VK3AMA





locked Re: Timing Adjustment.

Laurie, VK3AMA
 

On 15/09/2020 3:52 am, JoAnn Donaldson via groups.io wrote:
I turned OFF CHECK BEFORE and now it logs successfully.
How are you turning off the B4 check in JTAlert?
It is not possible, it is permanently enabled, there is not setting for turning B4 checks off.

What did you change that made logging work?

de Laurie VK3AMA


locked Re: Timing Adjustment.

HamApps Support (VK3AMA)
 

On 15/09/2020 5:48 am, Michael Black via groups.io wrote:
If I'm not mistaken you don't get very good caching on a remote network file by default.

Mike

Which is why JTAlert is optimized to minimize direct access to Log files, either locally or remotely.

JTAlert will only perform a direct access of a log file in the following circumstances...
  1. When a callsign is FIRST decoded to perform a B4 check for the current Band/Mode.

  2. When confirming a QSO was logged by reading the log. Past bad experiences with other loggers has shown that the status reported by the logger (via its api) after logging may not be correct and cannot be relied upon. HRD was notorious for reporting logging success when the QSO was never logged. Direct reading of the log avoids that.

  3. When performing the Alert database rebuild.

de Laurie VK3AMA


locked subscribe

AI4VV
 

I would like to subscribe to the group.

Susan


locked Re: Timing Adjustment.

Michael Black
 

On Monday, September 14, 2020, 02:40:55 PM CDT, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 15/09/2020 3:52 am, JoAnn Donaldson via groups.io wrote:
Besides I have already figured out how to solve my problem with JTALert NOT logging to ACLog. It seems that when JTALert does the check for Worked Before that is when ACLog pops the error message and the Log entry is deleted. I turned OFF CHECK BEFORE and now it logs successfully. I never understand why JTALert needed to remind you that you have already worked a station before when WSIT-X already does by turning the contact GREEN.
   I suspect the timing issue is ONLY with the Before Check. I am running ACLog on a separate computer thus have to use the Manual Mode to access ACLog. Also do not understand why JTALert needs a PHYSICAL Path to the database when the N3FJP API gives the Client all the access it needs.

So put this thread asleep. I have found a flaw in how the BeFor Check is done when ACLog is on a separate computer. I found a work around for the flaw. If the Developer wants to correct this, I am more than willing to tests an update.

JoAnn Donaldson - AB8YZ 

Sorry, buy your wrong on so many fronts.
  • First, there is nothing to fix, there is no B4 flaw to correct.
  • What is this error message that ACLog is showing? Post an image of this ACLog generated message.
  • WSJT-X reporting of B4 is independent of your ACLog log file and can be grossly out-of-sync with ACLog. JTAlert does its B4 checks against your primary log, ACLog, not the WSJTX log file which at any time could be empty, truncated or missing.

  • The Timing adjustments your referring to have NOTHING to do with B4 checks. It used used purely for the QSO logged success checks. This is why the settings entry is under the "Logging" section (funny that).

  • The ACLog API is very inefficient when performing many Callsign lookups (for the B4 checks) at the end of a busy FT8 period where there may be 20, 30, 40 or more callsigns to check. Direct querying of the Log file is the quickest technique.

  • The ACLog API doesn't allow for custom sql queries that JTAlert uses, so direct log access is needed. This applies to all the supported loggers, not just ACLog.

  • You have slowed things down further by having the ACLog file on a different PC than JTAlert so network latency is introduced further slowing log file reads.  JTAlert does cache (in memory) the results of the slow disk file lookups, but there will always be at least one physical log lookup when a callsign is first decoded.

  • The Alert database (used to determine what alerts a callsigns/decode generates) requires direct access to the Log file in order to run the many hundreds of sql queries needed  to rebuild the database. The Alert database is used for high-speed determination of what alerts are triggered, it is impractical to run multiple queries (if even possible) via the ACLog API to check if a Callsign is a needed DXCC, State, Grid, Prefix, etc, at the end of a FT8 period. This in-memory database is used.

de Laurie VK3AMA


locked Re: Timing Adjustment.

HamApps Support (VK3AMA)
 

On 15/09/2020 3:52 am, JoAnn Donaldson via groups.io wrote:
Besides I have already figured out how to solve my problem with JTALert NOT logging to ACLog. It seems that when JTALert does the check for Worked Before that is when ACLog pops the error message and the Log entry is deleted. I turned OFF CHECK BEFORE and now it logs successfully. I never understand why JTALert needed to remind you that you have already worked a station before when WSIT-X already does by turning the contact GREEN.
   I suspect the timing issue is ONLY with the Before Check. I am running ACLog on a separate computer thus have to use the Manual Mode to access ACLog. Also do not understand why JTALert needs a PHYSICAL Path to the database when the N3FJP API gives the Client all the access it needs.

So put this thread asleep. I have found a flaw in how the BeFor Check is done when ACLog is on a separate computer. I found a work around for the flaw. If the Developer wants to correct this, I am more than willing to tests an update.

JoAnn Donaldson - AB8YZ 

Sorry, buy your wrong on so many fronts.
  • First, there is nothing to fix, there is no B4 flaw to correct.
  • What is this error message that ACLog is showing? Post an image of this ACLog generated message.
  • WSJT-X reporting of B4 is independent of your ACLog log file and can be grossly out-of-sync with ACLog. JTAlert does its B4 checks against your primary log, ACLog, not the WSJTX log file which at any time could be empty, truncated or missing.

  • The Timing adjustments your referring to have NOTHING to do with B4 checks. It used used purely for the QSO logged success checks. This is why the settings entry is under the "Logging" section (funny that).

  • The ACLog API is very inefficient when performing many Callsign lookups (for the B4 checks) at the end of a busy FT8 period where there may be 20, 30, 40 or more callsigns to check. Direct querying of the Log file is the quickest technique.

  • The ACLog API doesn't allow for custom sql queries that JTAlert uses, so direct log access is needed. This applies to all the supported loggers, not just ACLog.

  • You have slowed things down further by having the ACLog file on a different PC than JTAlert so network latency is introduced further slowing log file reads.  JTAlert does cache (in memory) the results of the slow disk file lookups, but there will always be at least one physical log lookup when a callsign is first decoded.

  • The Alert database (used to determine what alerts a callsigns/decode generates) requires direct access to the Log file in order to run the many hundreds of sql queries needed  to rebuild the database. The Alert database is used for high-speed determination of what alerts are triggered, it is impractical to run multiple queries (if even possible) via the ACLog API to check if a Callsign is a needed DXCC, State, Grid, Prefix, etc, at the end of a FT8 period. This in-memory database is used.

de Laurie VK3AMA


locked Re: Timing Adjustment.

JoAnn Donaldson
 

I think I finally figured out what you all are saying. In the pictures you all show it shows the screen as being in

Logging
    Standard ADIF File

because in YOUR IMAGE the Standard ADIF File is highlighted Blue which indicates that you have that Sub menu selected. Besides I have already figured out how to solve my problem with JTALert NOT logging to ACLog. It seems that when JTALert does the check for Worked Before that is when ACLog pops the error message and the Log entry is deleted. I turned OFF CHECK BEFORE and now it logs successfully. I never understand why JTALert needed to remind you that you have already worked a station before when WSIT-X already does by turning the contact GREEN.
   I suspect the timing issue is ONLY with the Before Check. I am running ACLog on a separate computer thus have to use the Manual Mode to access ACLog. Also do not understand why JTALert needs a PHYSICAL Path to the database when the N3FJP API gives the Client all the access it needs.

So put this thread asleep. I have found a flaw in how the BeFor Check is done when ACLog is on a separate computer. I found a work around for the flaw. If the Developer wants to correct this, I am more than willing to tests an update.

JoAnn Donaldson - AB8YZ 

On Monday, September 14, 2020, 12:27:43 PM CDT, Michael Black via groups.io <mdblack98@...> wrote:


It's not that you have ADIF selected for logging.

It's that you have the ADIF menu selected instead of the Logging menu.


Inline image

Mike W9MDB




On Monday, September 14, 2020, 12:22:23 PM CDT, JoAnn Donaldson via groups.io <joannplano2005@...> wrote:


How does my image DO NOT Show I have NOT selected Logging then Standard ADIF File"?????????

JoAnn - AB8YZ

On Sunday, September 13, 2020, 7:13:18 PM CDT, JoAnn Donaldson <joannplano2005@...> wrote:


I hate to say this but that menu does not exist on my JTALert. Here is what it says on mine.Inline image


On Sunday, September 13, 2020, 4:03:09 PM CDT, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 14/09/2020 6:17 am, JoAnn Donaldson via groups.io wrote:
I do not see any entry for Asjustment under Logging or under Miscellaneous.
Under Miscellaneous I see
        Hot Keys

Thats it. No Entry to adjust the Timing. Under Logging I see
          Last QSO API
          Last B4 Database
          Standard ADIF File
        + DXLAb DXkeeper
        HDR V5/V6
        Log4OM V1
        Log4OM V2
      +ACLog

Click the "Logging" entry in the left tree-view display.
   

de Laurie VK3AMA


locked Re: Timing Adjustment.

Michael Black
 

It's not that you have ADIF selected for logging.

It's that you have the ADIF menu selected instead of the Logging menu.


Inline image

Mike W9MDB




On Monday, September 14, 2020, 12:22:23 PM CDT, JoAnn Donaldson via groups.io <joannplano2005@...> wrote:


How does my image DO NOT Show I have NOT selected Logging then Standard ADIF File"?????????

JoAnn - AB8YZ

On Sunday, September 13, 2020, 7:13:18 PM CDT, JoAnn Donaldson <joannplano2005@...> wrote:


I hate to say this but that menu does not exist on my JTALert. Here is what it says on mine.Inline image


On Sunday, September 13, 2020, 4:03:09 PM CDT, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 14/09/2020 6:17 am, JoAnn Donaldson via groups.io wrote:
I do not see any entry for Asjustment under Logging or under Miscellaneous.
Under Miscellaneous I see
        Hot Keys

Thats it. No Entry to adjust the Timing. Under Logging I see
          Last QSO API
          Last B4 Database
          Standard ADIF File
        + DXLAb DXkeeper
        HDR V5/V6
        Log4OM V1
        Log4OM V2
      +ACLog

Click the "Logging" entry in the left tree-view display.
   

de Laurie VK3AMA