Date   

locked Re: Performance with big AC Log

HamApps Support (VK3AMA)
 

On 8/02/2020 8:38 am, Shel KF0UR wrote:
Are you referring to AC Log's List / Last xx setting?  if so, it's set to a few hundred, and doesn't seem to affect this issue (same time whether 50 or 500).

Tnx,

Shel KF0UR
Shei,

I was able to reproduce the significant delays in showing the filtering of the ACLog display based on the WSJT-X DX Call sent by JTAlert. For me it occurred when using a very large ACLog log file (57,000 QSOs) and I had ACLog set to display all entries. It didn't matter if the DXCall was for a recent call in the log, one of the first or if a Callsign known not to be in the log.

There is typically a few seconds (less than 3) delay after a DX Call change for JTAlert to gather data from the ACLog log and display in the Callsign QSO history and Confirmed/Worked display area. You can see this when JTAlert shows the Callsign (to the left of the log fields) and its Worked B4 or New Band or First QSO status below the Callsign. eg.


I was seeing ~ 40+ seconds delay before the Callsign showed in ACLog and it filtered its display despite JTAlert having much earlier displayed the Callsign data as retrieved directly from the ACLog log. ACLog is similarly very slow when clearing the DXCall, 40+ seconds to clear the Call and remove the display filter.

When I reran the tests with a 50 QSO limit on the ACLog display, again sending a Callsign known not to be in the Log, the Showing of the Callsign in ACLog took ~1 sec or less with a similar number for when the Callsign is cleared.

It looks to me like an ACLog display issue when showing a large number of entries (to be expected). It is not a JTAlert delay in sending the Call to ACLog and the return of lookup data to JTAlert from the direct queries directly against the ACLog log file is fast indicating it is unlikely a database indexing issue. or a full database scan.

de Laurie VK3AMA


locked Re: Audio Error?

Bill - AA4M
 

On 02/09/2020 15:13:49, HamApps Support (VK3AMA) wrote:
On 10/02/2020 8:55 am, Bill - AA4M wrote:
I think I don't understand how the "virtual cable" is actually supposed to work!

73, Bill� AA4M
You simply need to set JTAlert to use the virtual device or any device other than the one used by WSJT-X.
While JTAlert is assigned to use the same audio device as WSJT-X you will continue to get the audio devices match warning.

de Laurie VK3AMA


That worked, thanks Laurie!

73, Bill AA4M


locked Re: Alaska

Bill - AA4M
 

On 02/09/2020 14:52:56, Ron W3RJW via Groups.Io wrote:
Certain stations do not show as worked B4 in the latest version during a session. Laurie is working on it.  How about when you restart JTAlert ?
--
73
Ron, W3RJW
OK, I just worked a JA who was calling CQ.  My QSO was successfully logged into DXKeeper.  Then the same JA popped up again calling CQ and was NOT shown as B4.  I closed JTAlert and WSJT-X, restarted them, now the same JA is showing correctly as B4.

Is there a link to 2.15.8 which I can reinstall until this problem is resolved?

Thanks, Bill  AA4M


locked Re: Worked B4 with HRD

Gavin Bennett
 

Hi Laurie

 

Thanks, if I can be of any assistance with log files etc., please let me know, it is not a major issue as it self corrects on application restart.

 

I appreciate you providing this essential tool for WSJTx.

 

Regards

 

 

Gavin

ZL3GAV

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: Monday, 10 February 2020 11:58
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Worked B4 with HRD

 

On 10/02/2020 9:41 am, Gavin Bennett wrote:

Since Saturday I have been able to observe the behaviour further, with NEW QSO's no showing as B4 status worked in JT Alert.

There is no difference if the "Ignore Grid" option is selected or not. If I restart the WSJYx/JTAlert, and HRD logbook sessions, those stations in JTAlert are showing correctly with their B4 status.

Thanks

Gavin
de ZL3GAV


Gavin,

I can't confirm the defect yet, but there have been enough reports to indicate a problem.

I am working on it but am hampered by having to create a new VM working environment in order to run a trial copy of HRD to complete the testing. Time is a bit short at the moment.

de Laurie VK3AMA


locked Re: DT Alerts in 2.15.9

HamApps Support (VK3AMA)
 

On 8/02/2020 11:20 pm, Ron W3RJW via Groups.Io wrote:
But that now works only in the decodes window ?   I thought it was a useful feature in the WSJT-X window.
--
73
Ron, W3RJW

True, it is only available in the Decodes window.

Highlighting DT values in WSJT-X was removed due to an impact it was having to the WSJT-X UI display not updating  (gave the impression of a hang) for a couple of seconds (I saw it reach 4 seconds into the new period before the display updated). This was most apparent when monitoring a busy band and the WSJT-X "Band Activity" display control of WSJT-X was full. The hang would go unnoticed (ie was very short) when the old decodes in WSJT-X were erased.

de Laurie VK3AMA


locked Re: Worked B4 with HRD

HamApps Support (VK3AMA)
 

On 10/02/2020 9:41 am, Gavin Bennett wrote:
Since Saturday I have been able to observe the behaviour further, with NEW QSO's no showing as B4 status worked in JT Alert.

There is no difference if the "Ignore Grid" option is selected or not. If I restart the WSJYx/JTAlert, and HRD logbook sessions, those stations in JTAlert are showing correctly with their B4 status.

Thanks

Gavin
de ZL3GAV

Gavin,

I can't confirm the defect yet, but there have been enough reports to indicate a problem.

I am working on it but am hampered by having to create a new VM working environment in order to run a trial copy of HRD to complete the testing. Time is a bit short at the moment.

de Laurie VK3AMA


locked Re: B4 bug or feature?

HamApps Support (VK3AMA)
 

On 9/02/2020 11:41 am, Marc VK3OHM wrote:
you now have inconsistent data - one window says B4, the other does not. This could be considered a bug. B4 is absolute, and independent of filters. It should be displayed independent of filters.

That inconsistency is due to the transitional nature of JTAlertV2. The Decodes window uses the code from the yet unreleased JTAlertV3. JTAlertV2 and JTAlertV3 are essentially incompatible resulting in the Decodes window using independent Filtering and settings from those of JTAlertV2.

B4s are NOT independent of the filters. The filters affect B4 display in both JTAlertV2 and the Decodes window.

If display of B4s is important for you, than don't filter them out, or alternatively leave the JTAlert V2 filters as is and set the Decodes to hide B4s.
Its not an onerous task to set 2 single click settings in JTAlertV2 and the Decodes window.
I am struggling to understand what the problem is.

de Laurie VK3AMA


locked Re: Decodes 2.15.9

HamApps Support (VK3AMA)
 

On 9/02/2020 1:47 pm, John wrote:
After updating, I find a box popped up with Decodes 2.15.9 and in this box there is a column labeled DXCC.
What is this really showing?  It is not there place in the DXCC Standings as I checked all of them on that.

Nice detailed box of information.

Thanks for any help

John W3ML
The DXCC value is the unique number assigned to each Country accepted by the DXCC award program. Country names are never used for alerting purposes as they are subject to change and spelling/localization errors. The number displayed is not related to any award standings it is simply the unique number representation of the Country Name, eg. 150 = Australia. The DXCC number display can be hidden and just have the Country Name displayed if you want.

de Laurie VK3AMA


locked Re: Sending spots to Spot Collector

Gregg Marco W6IZT
 

Misconfigured firewall, working now

 

73

Gregg W6IZT

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: Sunday, February 9, 2020 22:20
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Sending spots to Spot Collector

 

On 10/02/2020 8:19 am, Gregg Marco W6IZT wrote:

I press CRTL while clicking on the X in thew
filter panel. There are no spots being displayed.
 
73
Gregg W6IZT

If spots are not being displayed in SpotCollector despite having them enabled, the usual causes are Protection Software interference or a permissions mismatch between JTAlert and SpotCollector. If SpotCollector is running with elevated privileges Windows will prevent the DDE comms from JTAlert getting to SpotCollector.

Another possibility is that the "DXLab DDE" component of the JTAlertV2.Manager process is not initialized. What does the JTAlert "Help" (or "?") -> "About" menu show? Scroll down the window until you get to the Manager Status section and look for the "DXLab DDE" line.

de Laurie VK3AMA


locked Re: Worked B4 with HRD

Gavin Bennett
 

Hi Laurie

Since Saturday I have been able to observe the behaviour further, with NEW QSO's no showing as B4 status worked in JT Alert.

There is no difference if the "Ignore Grid" option is selected or not. If I restart the WSJYx/JTAlert, and HRD logbook sessions, those stations in JTAlert are showing correctly with their B4 status.

Thanks

Gavin
de ZL3GAV



locked Re: QSO Not Logged

HamApps Support (VK3AMA)
 

On 10/02/2020 3:55 am, Ernex de la Ossa wrote:
Good afternoon, I'm addressing you because I update LOG4OM and I can't upload my contacts from WSJT-X to the LOG4OM guard book, I use LOG4 = M 2.3.0.0, WSJT-X 2.1.2 and JTAlert 2.15.9, the routes of SQLite, both in LOG40M and JTAlert are identical, the "logging time" I tried 5 secs and 8secs and I don't get it, it always comes out "Failure: QSO not Logged, ERROR Message: LOG4OM V2 SQLite: Unable to confirm QSO Logged, NOTE : The QSO is still saved to the WSJT-X Log File. "

5 & 8 seconds for the QSO check time is too short for Log4OM V2. It is much slower in logging QSOs compared to V1.

If the QSOs are getting logged to Log4OM V2 successfully despite the warning message from JTAlert you can try increasing the time, say 15 secs (which many have reported is what they need with Log4OM V2).

Alternatively, i
f your happy that JTAlert is successfully logging the QSOs you can turn off the Log Check performed by JTAlert which avoids the JTAlert hang at the end of logging, because it is a single threaded executable, as it waits for the timeout before rechecking the log. Logging Section of the Settings, very last option checkbox (scroll down). This option will allow JTAlert to return immediately to processing decodes after sending the logging instruction to Log4OM, within milliseconds of the WSJT-X logging event.
   

de Laurie VK3AMA


locked Re: removing jtalert

HamApps Support (VK3AMA)
 

On 10/02/2020 4:55 am, Daniel Curry wrote:
How do I remove all the jtalerts apps in windows 10?

Use Windows Control Panel to uninstall JTAlert. Then use Windows File Explorer to remove the old JTAlert install directory as there will likely be old files and folders that the uninstall didn't remove.

If you don't intend to use JTAlert in the future, you will need to remove your old config and session files as these are never removed during a JTAlert install/upgrade or uninstall. Use Windows File Explorer to remove the "HamApps" directory under your %localappdata% directory.

de Laurie VK3AMA


locked Re: JTAlert causing DX Keeper to filter Log on Startup #DXLAB

HamApps Support (VK3AMA)
 

On 9/02/2020 8:01 pm, Stewart Wilkinson via Groups.Io wrote:
When my last attempt at a QSO in WSJT-X was incomplete and the Tx1 to Tx5 message boxes still have a callsign and report details that it was last trying to send when JTAlert starts it causes DX Keeper to filter the Log to show just the list of any contacts with the station I last tried to work, the only way to clear this appears to be to click the 'X' in DX Keeper to clear the filter. Starting 2 or more copies of WSJT-X and JTAlert causes the filter to change from one callsign to the next as each copy starts to work. 

Is there a way that I've missed to clear the incomplete QSO data from WSJT-X or from JTAlert to stop this happening ?

If you don't want JTAlert performing a DXKeeper lookup (along with DXK filtering) on startup make sure the "DX Call" field in WSJT-X is empty. JTAlert has no way of knowing if that DX Call is a new entry or an old entry from a previous session.

de Laurie VK3AMA


locked Re: Sending spots to Spot Collector

Dave AA6YQ
 

Thanks for the errorlog, Gregg. It shows that SpotCollector did not receive any directives from JTAlert. Possible reasons;

1. JTAlert not properly configured to send decoded callsigns to SpotCollector as local spots

2. Windows is not allowing JTAlert to communicate with SpotCollector because one of the two apps is being started with
Administrative privileges and the other isn't; Windows only allows two apps to communicate if neither or both have Administrative
privileges

3. A misconfigured (or malfunctioning) firewall or anti-malware application is preventing JTAlert from interoperating with
SpotCollector

73,

Dave, AA6YQ

-----Original Message-----
From: gregg.w6izt@... [mailto:gregg.w6izt@...]
Sent: Sunday, February 09, 2020 5:14 PM
To: @AA6YQ
Subject: RE: [HamApps] Sending spots to Spot Collector

As requested

-----Original Message-----
From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of Dave AA6YQ
Sent: Sunday, February 9, 2020 22:07
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Sending spots to Spot Collector

+ AA6YQ comments below

Thank for your prompt reply. I press CRTL while clicking on the X in thew filter panel. There are no spots being displayed.

+ OK. Please do the following:

1. on the General tab of SpotCollector's Configuration window, check the "Log debugging info" box

2. wait for WSJT-X to decode several callsigns that JTAlert should forward to SpotCollector as local spots

3. on the General tab of SpotCollector's Configuration window, uncheck the "Log debugging info" box

4. attach the errorlog.txt file from your SpotCollector folder to an email message, and send the email message to me via

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ






--
This email has been checked for viruses by AVG.
https://www.avg.com


locked Re: Sending spots to Spot Collector

HamApps Support (VK3AMA)
 

On 10/02/2020 8:19 am, Gregg Marco W6IZT wrote:
I press CRTL while clicking on the X in thew
filter panel. There are no spots being displayed.

73
Gregg W6IZT
If spots are not being displayed in SpotCollector despite having them enabled, the usual causes are Protection Software interference or a permissions mismatch between JTAlert and SpotCollector. If SpotCollector is running with elevated privileges Windows will prevent the DDE comms from JTAlert getting to SpotCollector.

Another possibility is that the "DXLab DDE" component of the JTAlertV2.Manager process is not initialized. What does the JTAlert "Help" (or "?") -> "About" menu show? Scroll down the window until you get to the Manager Status section and look for the "DXLab DDE" line.

de Laurie VK3AMA


locked Re: Alaska

Bill - AA4M
 

On 02/09/2020 15:11:38, HamApps Support (VK3AMA) wrote:
On 10/02/2020 8:33 am, Bill - AA4M wrote:
I just worked 2 different Alaskan stations on 17M FT8, but they continue to be displayed in my NOT "Worked-B4" color scheme.� All others on the band seem to be identified OK by JTAlert.� What does the program have against our 49th state?� :)

73, Bill� AA4M
All B4 checks are done against the logger enabled in JTAlert.
What logger are you using? Is it HRD? If so what log type MSAccess, MSSQL or MySQL?

de Laurie VK3AMA


DXLab's DXKeeper is my logger.  JTAlert successfully sent both Alaska QSO's to my logger.

73, Bill


locked Re: Audio Error?

HamApps Support (VK3AMA)
 

On 10/02/2020 8:55 am, Bill - AA4M wrote:
I think I don't understand how the "virtual cable" is actually supposed to work!

73, Bill  AA4M
You simply need to set JTAlert to use the virtual device or any device other than the one used by WSJT-X.
While JTAlert is assigned to use the same audio device as WSJT-X you will continue to get the audio devices match warning.

de Laurie VK3AMA


locked Re: Alaska

HamApps Support (VK3AMA)
 

On 10/02/2020 8:33 am, Bill - AA4M wrote:
I just worked 2 different Alaskan stations on 17M FT8, but they continue to be displayed in my NOT "Worked-B4" color scheme.  All others on the band seem to be identified OK by JTAlert.  What does the program have against our 49th state?  :)

73, Bill  AA4M
All B4 checks are done against the logger enabled in JTAlert.
What logger are you using? Is it HRD? If so what log type MSAccess, MSSQL or MySQL?

de Laurie VK3AMA


locked Re: Alaska

Bill - AA4M
 

I neglected to mention that I had just installed 2.15.9.  So after reading Ron's message, I rebooted but both Alaskans had left the band.

73, Bill


On 02/09/2020 14:52:56, Ron W3RJW via Groups.Io wrote:
Certain stations do not show as worked B4 in the latest version during a session. Laurie is working on it.  How about when you restart JTAlert ?
--
73
Ron, W3RJW


locked Re: Sending spots to Spot Collector

Dave AA6YQ
 

+ AA6YQ comments below

Thank for your prompt reply. I press CRTL while clicking on the X in thew filter panel. There are no spots being displayed.

+ OK. Please do the following:

1. on the General tab of SpotCollector's Configuration window, check the "Log debugging info" box

2. wait for WSJT-X to decode several callsigns that JTAlert should forward to SpotCollector as local spots

3. on the General tab of SpotCollector's Configuration window, uncheck the "Log debugging info" box

4. attach the errorlog.txt file from your SpotCollector folder to an email message, and send the email message to me via

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ