Date   

locked Re: JTAlert 2.16.7 is available

dk1wb@...
 

Laurie,
Windows Defender warned that Trojan:Win32/Azden.A!cl was found in
x86)\HamApps\JTAlert\plugins\JTAlertSettings.exe and deleted it.
Please confirm.
73,
Hans, DK1WB

Carlos Reboreda schrieb am 09.06.2020 10:18 (GMT +02:00):

Hi all,

 

My experience here is the same… when there are abt 100 Kb left to finish the download, the ESET (for the first time) cancels the download, because it has detected something dangerous on dnl.hamapps.com … I’m not saying that this is the real matter, I just describe what ESET is doing about this download. I’m user of this antivirus for more tan 15 years, every euro i pay every

year for it is worth it. I tried the download with Opera, Edge and Chrome, so I think it isn’t a matter of the web browser you use. Lets see if there any other members experimenting the same

problem or it happens to be a false detection.

 

73 to all!

 

Carlos R.

EA1DWI

 

Enviado desde Correo para Windows 10

 

De: chas cartmel
Enviado: martes, 9 de junio de 2020 9:50
Para: Support@hamapps.groups.io
Asunto: Re: [HamApps] JTAlert 2.16.7 is available

 

Jacques

08:48 BST – all OK here in the UK.
Have you tries a different browser? Occasionally this works for me if I have a ‘glitch’.

73 Charlie

G4EST

www.g4est.me.uk

 

 

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of Jacques Corbu
Sent: 09 June 2020 07:09
To: Support@HamApps.groups.io
Subject: [HamApps] JTAlert 2.16.7 is available

 

HI Laurie

cannot access new version the website is given as non accessible when I hit download ?  I have never had this issue and it has all the exception requires in avast etc  but this come up 

any idea would be welcomed 

stay safe Jacques F1VEV

 

This email has been scanned by BullGuard antivirus protection.

For more info visit www.bullguard.com

 

 


locked Re: JTAlert 2.16.7 is available

Carlos Reboreda
 

Hi all,

 

My experience here is the same… when there are abt 100 Kb left to finish the download, the ESET (for the first time) cancels the download, because it has detected something dangerous on dnl.hamapps.com … I’m not saying that this is the real matter, I just describe what ESET is doing about this download. I’m user of this antivirus for more tan 15 years, every euro i pay every

year for it is worth it. I tried the download with Opera, Edge and Chrome, so I think it isn’t a matter of the web browser you use. Lets see if there any other members experimenting the same

problem or it happens to be a false detection.

 

73 to all!

 

Carlos R.

EA1DWI

 

Enviado desde Correo para Windows 10

 

De: chas cartmel
Enviado: martes, 9 de junio de 2020 9:50
Para: Support@hamapps.groups.io
Asunto: Re: [HamApps] JTAlert 2.16.7 is available

 

Jacques

08:48 BST – all OK here in the UK.
Have you tries a different browser? Occasionally this works for me if I have a ‘glitch’.

73 Charlie

G4EST

www.g4est.me.uk

 

 

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of Jacques Corbu
Sent: 09 June 2020 07:09
To: Support@HamApps.groups.io
Subject: [HamApps] JTAlert 2.16.7 is available

 

HI Laurie

cannot access new version the website is given as non accessible when I hit download ?  I have never had this issue and it has all the exception requires in avast etc  but this come up 

any idea would be welcomed 

stay safe Jacques F1VEV

 

This email has been scanned by BullGuard antivirus protection.

For more info visit www.bullguard.com

 


locked Re: JTAlert 2.16.7 is available

chas cartmel
 

Jacques

08:48 BST – all OK here in the UK.
Have you tries a different browser? Occasionally this works for me if I have a ‘glitch’.


73 Charlie

G4EST

www.g4est.me.uk

 

 

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of Jacques Corbu
Sent: 09 June 2020 07:09
To: Support@HamApps.groups.io
Subject: [HamApps] JTAlert 2.16.7 is available

 

HI Laurie

cannot access new version the website is given as non accessible when I hit download ?  I have never had this issue and it has all the exception requires in avast etc  but this come up 

any idea would be welcomed 

stay safe Jacques F1VEV


This email has been scanned by BullGuard antivirus protection.
For more info visit www.bullguard.com


locked JTAlert 2.16.7 is available. WSJT-X 2.2.x fix + new features. #NewRelease #Announcement

HamApps Support (VK3AMA)
 

The latest JTAlert version 2.16.7 is now available @ https://hamapps.com/JTAlert/
 

Please see the release notes below.

de Laurie VK3AMA

Release Notes:

2.16.7 (09-Jun-2020)

  *** Includes Callsign database file version 2020-06-08 (2020-Jun-08)

  New Features:

    - 4m Band Alerting: All the Wanted Alerts, Scan Log, QSO History & Bands
       Confirmed display now support the 4m band.

    - Multiple Grids per QSO Logs: Logs that support recording multiple grids
       (1,2 or 4) are now supported by the Scan Log & Rebuild operation for
       updating the internal "Wanted Grid" lists and the Worked B4 checks.
       Currently only DXKeeper and standard ADIF logs are supported.

    - WSJT-X decode highlighting: The grid in a decode is now only colored if
       a Wanted Grid Alert is generated using the Grid Alert colors.

  Changes:

    - WSJT-X decode highlighting: Only the "CQ Callsign" in a CQ decode is
       colored, previously the entire decode "CQ Callsign Grid" was colored.

    - WSJT-X decode highlighting: For non-CQ decodes, only the DX Callsign is
       Coloured, previously the exchange part of the decode (eg, report, grid,
       RR73, etc) was also colored.

  Fixes:

    - WSJT-X 2.2.x FT8: Random loss of some early first-pass FT8 decodes received
       at the 11 second point of the Rx period.



locked Re: needed grids not updating once needed one worked

Jim Cary
 

Thanks.
73, Jim


locked Re: needed grids not updating once needed one worked

Larry Banks
 

Hi Jim,
 
Same as DXCC or WAS, the scan is required.

73 -- Larry -- W1DYJ

 

From: Jim Cary
Sent: Monday, June 08, 2020 13:27
Subject: [HamApps] needed grids not updating once needed one worked
 
When I work a needed grid, the needed list is not being updated and the grid still shows as needed.  The only way I can get it to update is to do a complete log scan.  What am I doing wrong?

Jim
W2SM


locked needed grids not updating once needed one worked

Jim Cary
 

When I work a needed grid, the needed list is not being updated and the grid still shows as needed.  The only way I can get it to update is to do a complete log scan.  What am I doing wrong?

Jim
W2SM


locked Re: Using WSJT-X, JTAlert and MacLoggerDX together nicely

Jay
 

That was the work around.  I keep changing the entry in "Logging" for retransmission and the evidently only works on 127.0.0.1.  Never saw the WSJT-X/JTDX entry.

Thanks

jb  N4NQY


locked Re: JTAlert stops updating for about 2 minutes

Michael Black
 

What antivirus are you using?  

Mike W9MDB




On Monday, June 8, 2020, 10:26:38 AM CDT, John Singler <jes148@...> wrote:


I've been trying to solve this for a couple of months and run out of ideas. JTAlert runs fine for minutes to hours and then stops updating call signs. If I mouse over the form, I get an hourglass. The form shrinks a bit (but not the displayed call signs) and the top margin text gets pale. After about 90 seconds the top margin text gets dark again, usually with a Not Responding message,  and after about 2 minutes most or all the call signs decoded while the display is off get written. While all this is annoying, the thing that will eventually bite me is that if I log a QSO while JTAlert is stopped, when it comes back I  get a QSO not logged message - QSO and DX Call call signs don't match.
First thing I did was follow Mike Black's guidance and put the program and data directories for WSJT-X, JTAlert and HRD5 (my logger) on the Windows Defender exception list. JTAlert stops even it it has been minutes to hours since my last transmission and WSJT-X and CAT control are not impacted so I don't see how it can be RFI (but I did put an RFI suppression kit on anyway). . I've checked the CPU load with Performance Monitor and it is 12% to 25%. There was often a spike in HDD activity just before JTAlert stopped but not while it is stopped and that was usually WSJT-X writing a .wav file. WSJT-X doesn't do that any more and JTAlert still stops. I saw message 29770 about a potential fix but missed it the first time and now I get a page not found error for the beta.
I am using Windows 10, ver 1903, WSJT-X 2.2.0, and JTAlert 2.16.6
Any ideas? Thanks
John, KA5BJC


locked JTAlert stops updating for about 2 minutes

John Singler
 

I've been trying to solve this for a couple of months and run out of ideas. JTAlert runs fine for minutes to hours and then stops updating call signs. If I mouse over the form, I get an hourglass. The form shrinks a bit (but not the displayed call signs) and the top margin text gets pale. After about 90 seconds the top margin text gets dark again, usually with a Not Responding message,  and after about 2 minutes most or all the call signs decoded while the display is off get written. While all this is annoying, the thing that will eventually bite me is that if I log a QSO while JTAlert is stopped, when it comes back I  get a QSO not logged message - QSO and DX Call call signs don't match.
First thing I did was follow Mike Black's guidance and put the program and data directories for WSJT-X, JTAlert and HRD5 (my logger) on the Windows Defender exception list. JTAlert stops even it it has been minutes to hours since my last transmission and WSJT-X and CAT control are not impacted so I don't see how it can be RFI (but I did put an RFI suppression kit on anyway). . I've checked the CPU load with Performance Monitor and it is 12% to 25%. There was often a spike in HDD activity just before JTAlert stopped but not while it is stopped and that was usually WSJT-X writing a .wav file. WSJT-X doesn't do that any more and JTAlert still stops. I saw message 29770 about a potential fix but missed it the first time and now I get a page not found error for the beta.
I am using Windows 10, ver 1903, WSJT-X 2.2.0, and JTAlert 2.16.6
Any ideas? Thanks
John, KA5BJC


locked Wider window would be nice

Mark
 

JTAlert is Great, but I would like to have more information available horizontally.  I have JTAlert's display placed above the WSJT-X display and have room to expand JTAlert's information by four more display fields on each of the three existing rows.

Merk, K6FG


locked Re: Special callsigns

WB5JJJ - George
 

My solution is, and has always been right in front of my face. 

I just watch the WSJTx Band Activity window and let JTA do what it does the best, the voice announcements to get my attention for anything I might overlook, like a new DXCC.  1x1's and other special calls jump out at me all the time, even if they are color-coded as having been worked before for some previous special event. 

I spend most of my time watching the BA window as it's easier to scan with everything in a single row, whereas the JTA has things in a horizontal AND vertical plane per entry.  I can scan the BA window in half the time it takes me to scan the JTA grid.  I have B4 ignore turned on, CQ only unchecked and using the 8x3 display.  This setup still gets a bit overwhelming to decipher in less than 15s. 

Don't get me wrong, but the JTA announcements and grid display are a vital part of my operation.  And yes, I do scan it frequently, but as a backup to WSJTx which is a much faster visual scan for these older eyes and slower reaction times. 
--
73's
George - WB5JJJ


locked Re: Special callsigns

Tom Melvin
 

Morning

One issue, this would have to be under a UI - some users, shall we say, by their nature are nervous around computers, letting them loose with a text editor - I can imaging the traffic here. The file will as you point out will be OK for US users but as Laurie commented   'Any coded solution I develop is guaranteed to be incorrect for some users 5 minutes after a public release.

Just playing devil’s advocate here as 1x1 US calls don’t affect me in the slightest.

The saying 'Can of Worms' comes to mind.

Tom
--
73

Tom
GM8MJV (IO85)





On 8 Jun 2020, at 05:00, Michael Black via groups.io <mdblack98@...> wrote:

Come to think of it though, the grid alert could be very annoying for a lot of ops alerting every decode cycle on all the non-special calls.

The wanted callsign would alert you when they call, and then you'd leave it for working multiple bands, but then get a new alert every time it showed up again in the same band.

Neither is a robust solution.

Perhaps a special callsign file that gets referred to for the 1x1 pattern and has an expiration date of 15 days?

That file could then have foreign special calls added too of course.

Starter file

Mike

On Sunday, June 7, 2020, 10:32:20 PM CDT, Black Michael <mdblack98@...> wrote:


Actually there is a clearly defined answer in the U.S.


The grid alert solution should work as long as they provide a grid.

Mike




On Sunday, June 7, 2020, 05:17:19 PM CDT, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 8/06/2020 3:52 am, Michael Black via groups.io wrote:
There are 750 special event callsigns in U.S.  I haven't looked up foreign ones.

The point here to get JTAlert to recognize these as need-to-be-worked since they expire so quickly.

A regular expression detects them.

"[WKN][0-9][A-WYZ]"

And this to detect one with a suffix.
"[WKN][0-9][A-WYZ]/"

Mike W9MDB

Any coded solution has to be flexible enough to take into account the fundamental question "what is a special event Callsign? There is no clearly defined answer, is is subject to the whims of a user. A 1x1 callsign is may be a special event call to a US based Ham, but not so for many others. Here in VK 1x1 callsigns are not permitted or available . What is a special event callsign is no different from what is a DX callsign, there is no right or wrong answer.

Any coded solution I develop is guaranteed to be incorrect for some users 5 minutes after a public release.

My preferred option is to allow the user to decide what is a special event callsign and adjust their alerting as need.

Using the current JTAlert framework there are a number of ways to tackle the "avoid reporting B4 for special event Callsigns".
  • With the 1x1 callsigns, changing hands every week or so, they will likely be operating from different locations, so setting the B4 alert to consider the on-air Grid will allow for Alerting when the Callsign is reassigned and they start CQing from a new Grid. This also works for roving stations that may operated from a number of Grids iover a short period of time (hours, days, weeks, etc).

  • Add the special event Callsign(s) as a Wanted Callsign and enable the "ignore B4" option for that Alert. Either a list of callsigns can be imported for the Wanted Callsign Alert or add the Callsigns as needed via the right-click context menu of the alerted Callsign.

de Laurie VK3AMA



locked Re: JTAlerts Error Message When Starting WSJT-X With Slicemaster

pfullmer
 

Laurie,

    Bottom line up front, I got it sorted out.  You were correct that the error message I posted was for an earlier version of JTAlerts.  While I was trying to troubleshoot the issue, I uninstalled 2.16.6 and put on an older version to see if I could get it to work.  It was throwing the same error message though for 2.16.6, just the line number and the name of the executable was different.
    As for what Slicemaster does, it automatically configures and starts many 3rd party applications for the Flex Radio, aggregates spots and pushes them onto the screen, and lots more goodies.  And in regards to how does JTAlerts work with it, it doesn't interface with it at all.  When you start Slicemaster up, it sees what mode you're in then will automatically fire up the software corresponding to the mode. In digi it'll fire up WSJT-X, HRD or FLDIGI, if you're in CW it'll start the CW Skimmer etc.  If you switch modes on the fly, it handles all the shutting down and starting up of the application you need.  Very slick.
    The fix as provided by the application developer, was to delete the folder that contained all the configurations that it makes, and restart Slicemaster.  He stated that it was probably a corrupt configuration file.   I suppose that it was starting up WSJT-X in a way that was not allowing JTAlerts to start/communicate with WSJT-X.  
    Thanks for responding to my question.  You've got a great application.

Pete Fullmer  KE7W
    


locked Re: Special callsigns

Michael Black
 

Come to think of it though, the grid alert could be very annoying for a lot of ops alerting every decode cycle on all the non-special calls.

The wanted callsign would alert you when they call, and then you'd leave it for working multiple bands, but then get a new alert every time it showed up again in the same band.

Neither is a robust solution.

Perhaps a special callsign file that gets referred to for the 1x1 pattern and has an expiration date of 15 days?

That file could then have foreign special calls added too of course.

Starter file

Mike

On Sunday, June 7, 2020, 10:32:20 PM CDT, Black Michael <mdblack98@...> wrote:


Actually there is a clearly defined answer in the U.S.


The grid alert solution should work as long as they provide a grid.

Mike




On Sunday, June 7, 2020, 05:17:19 PM CDT, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 8/06/2020 3:52 am, Michael Black via groups.io wrote:
There are 750 special event callsigns in U.S.  I haven't looked up foreign ones.

The point here to get JTAlert to recognize these as need-to-be-worked since they expire so quickly.

A regular expression detects them.

"[WKN][0-9][A-WYZ]"

And this to detect one with a suffix.
"[WKN][0-9][A-WYZ]/"

Mike W9MDB

Any coded solution has to be flexible enough to take into account the fundamental question "what is a special event Callsign? There is no clearly defined answer, is is subject to the whims of a user. A 1x1 callsign is may be a special event call to a US based Ham, but not so for many others. Here in VK 1x1 callsigns are not permitted or available . What is a special event callsign is no different from what is a DX callsign, there is no right or wrong answer.

Any coded solution I develop is guaranteed to be incorrect for some users 5 minutes after a public release.

My preferred option is to allow the user to decide what is a special event callsign and adjust their alerting as need.

Using the current JTAlert framework there are a number of ways to tackle the "avoid reporting B4 for special event Callsigns".
  • With the 1x1 callsigns, changing hands every week or so, they will likely be operating from different locations, so setting the B4 alert to consider the on-air Grid will allow for Alerting when the Callsign is reassigned and they start CQing from a new Grid. This also works for roving stations that may operated from a number of Grids iover a short period of time (hours, days, weeks, etc).

  • Add the special event Callsign(s) as a Wanted Callsign and enable the "ignore B4" option for that Alert. Either a list of callsigns can be imported for the Wanted Callsign Alert or add the Callsigns as needed via the right-click context menu of the alerted Callsign.

de Laurie VK3AMA


locked Re: Special callsigns

Michael Black
 

Actually there is a clearly defined answer in the U.S.


The grid alert solution should work as long as they provide a grid.

Mike




On Sunday, June 7, 2020, 05:17:19 PM CDT, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 8/06/2020 3:52 am, Michael Black via groups.io wrote:
There are 750 special event callsigns in U.S.  I haven't looked up foreign ones.

The point here to get JTAlert to recognize these as need-to-be-worked since they expire so quickly.

A regular expression detects them.

"[WKN][0-9][A-WYZ]"

And this to detect one with a suffix.
"[WKN][0-9][A-WYZ]/"

Mike W9MDB

Any coded solution has to be flexible enough to take into account the fundamental question "what is a special event Callsign? There is no clearly defined answer, is is subject to the whims of a user. A 1x1 callsign is may be a special event call to a US based Ham, but not so for many others. Here in VK 1x1 callsigns are not permitted or available . What is a special event callsign is no different from what is a DX callsign, there is no right or wrong answer.

Any coded solution I develop is guaranteed to be incorrect for some users 5 minutes after a public release.

My preferred option is to allow the user to decide what is a special event callsign and adjust their alerting as need.

Using the current JTAlert framework there are a number of ways to tackle the "avoid reporting B4 for special event Callsigns".
  • With the 1x1 callsigns, changing hands every week or so, they will likely be operating from different locations, so setting the B4 alert to consider the on-air Grid will allow for Alerting when the Callsign is reassigned and they start CQing from a new Grid. This also works for roving stations that may operated from a number of Grids iover a short period of time (hours, days, weeks, etc).

  • Add the special event Callsign(s) as a Wanted Callsign and enable the "ignore B4" option for that Alert. Either a list of callsigns can be imported for the Wanted Callsign Alert or add the Callsigns as needed via the right-click context menu of the alerted Callsign.

de Laurie VK3AMA


locked Re: User Defined Alter Test Button

Michael Black
 

And with my script it shows

2020-06-06 16:54:52.5217 | Debug | Init "{"LogDir":"C:\\Users\\mdbla\\AppData\\Local\\HamApps\\W9MDB\\session\\JTAlertX\\","FileName":"UserAlert.txt","Executable":"C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe","Parameters":"-ExecutionPolicy Bypass -File C:\\Users\\mdbla\\Dropbox\\Ham\\JTAlert\\jtalertemail.ps1","Timeout":"15",}" |
2020-06-06 16:54:52.5217 | Debug | LogDir     : "C:\Users\mdbla\AppData\Local\HamApps\W9MDB\session\JTAlertX\" |
2020-06-06 16:54:52.5217 | Debug | FileName   : "UserAlert.txt" |
2020-06-06 16:54:52.5217 | Debug | Executable : "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" |
2020-06-06 16:54:52.5217 | Debug | Parameters : "-ExecutionPolicy Bypass -File C:\Users\mdbla\Dropbox\Ham\JTAlert\jtalertemail.ps1" |
2020-06-06 16:54:52.5217 | Debug | Timeout    : 15 |
2020-06-06 16:54:52.5217 | Debug | ShowWindow : false |
2020-06-06 16:54:52.6947 | Debug | Initialized : YES |





On Sunday, June 7, 2020, 06:14:36 PM CDT, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 8/06/2020 6:31 am, Dan Osborne wrote:
My issue is that I can NOT get ANY script to execute when called from JT Alert - either via a JT Alert
trigger or the TEST button. The command prompt window never pops up.

Ideas ???

Dan

JTAlert, by design, will not show any console window or similar associated with your script. The output is redirected and recorded in a log file. A planned option to disable that non-display when running the script from within JTAlert for test purposes has not been implemented.

To avoid blocking the main JTAlert process with a user-supplied script, JTAlert itself does not execute the script, but offloads the command to the JTAlertV2.Manager.exe process which will try and execute it in a dedicate thread. Check that the "User Alert" module of the the Manager process is initialized via the JTAlert Help->About menu. It should be similar to this...

================================
JTAlertV2.Manager status
(2020-06-06 22:00:53 utc)
-----------------------------------
Audio          : Initialized : YES
BandData       : Initialized : YES
HamSpots       : Initialized : YES
Text Msgs      : Initialized : YES
QRZ Xml        : Initialized : YES
HamQth Xml     : Initialized : YES
QRZ Log        : Initialized : YES
HamQth Log     : Initialized : YES
ClubLog Log    : Initialized : YES
Eqsl Log       : Initialized : YES
HrdLog Log     : Initialized : YES
DXLab DDE      : Initialized : YES
User Alert     : Initialized : YES
Updates Chk    : Initialized : YES
Maintenance    : Initialized : YES

If the Manager status looks good, then the next step is to check the log files for the "User Alert"
Using Windows File explorer, navigate to %localappdata%\HamApps\<YOUR_CALL>\session\JTAlertX\1\
Look for the files names starting with "JTAlertV2.Manager.Alert.User.log". File names with a 8 character date are archived files, look for files without the date as they are the current live log files.

If there is a
JTAlertV2.Manager.Alert.User.log.error file that should be examined. Any error trying to execute your script should be recorded there.

The
JTAlertV2.Manager.Alert.User.log.debug file records a dump of the command data sent from JTAlert to the Manager process. eg...
2020-06-07 22:46:03.9268 | Debug | [{"Call":"VK3AMA","Band":"6m","Mode":"FT8","Decode":"CQ VK3AMA QF22","AlertNo":"99","AlertType":"Alert Type","AlertTrig":"Alert Trigger","Date":"2020-06-07","Time":"22:46","QRG":"50313","DF":"2134","DB":"-10","Dxcc":"150","Country":"Australia","MthonCountry":"Australia","CQZone":"30","Continent":"OC","State":"","Grid":"QF22","Prefix":"VK3","Bearing":"45","Distance":"12345","Eqsl":"Yes","Lotw":"Yes","LotwDate":"2019-10-28",}] |
2020-06-07 22:46:09.3263 | Debug | Init "{"LogDir":"C:\\Users\\LGC\\AppData\\Local\\HamApps\\VK3AMA\\session\\JTAlertX\\","FileName":"UserAlert.txt","Executable":"E:\\Temp\\UserAlertTest.bat","Parameters":"","Timeout":"15",}" |
2020-06-07 22:46:09.3263 | Debug | LogDir     : "C:\Users\LGC\AppData\Local\HamApps\VK3AMA\session\JTAlertX\" |
2020-06-07 22:46:09.3263 | Debug | FileName   : "UserAlert.txt" |
2020-06-07 22:46:09.3263 | Debug | Executable : "E:\Temp\UserAlertTest.bat" |
2020-06-07 22:46:09.3263 | Debug | Parameters : "" |
2020-06-07 22:46:09.3263 | Debug | Timeout    : 15 |
2020-06-07 22:46:09.3263 | Debug | ShowWindow : false |

The JTAlertV2.Manager.Alert.User.log.info file may show the console output of your script (not guaranteed depending on script). My test script produces the following...
2020-06-07 22:46:05.0231 |  Info | ------------------------------------------------- |
2020-06-07 22:46:05.0231 |  Info | Blat v3.2.22 (build : Jul 19 2019 23:25:36) |
2020-06-07 22:46:05.0231 |  Info | 32-bit Windows, Full, Unicode |
2020-06-07 22:46:05.0231 |  Info | ErrorLevel returned from Blat == 0 |
2020-06-07 22:46:05.0231 |  Info | FINISHED |
2020-06-07 22:46:06.1086 |  Info | Exit time    : "2020-06-07 22:46:06" |
2020-06-07 22:46:06.1086 |  Info | Exit code    : 0 |
2020-06-07 22:46:06.1086 |  Info | Elapsed time : 1961.8679 ms |
2020-06-07 22:46:06.1086 |  Info | Number of passed arguments: 0 |
2020-06-07 22:46:06.1086 |  Info | ------------------------------------------------- |
2020-06-07 22:46:06.1086 |  Info | JTAlert set environment variables |
2020-06-07 22:46:06.1086 |  Info |      %JTAlert_AlertNo% : 99 |
2020-06-07 22:46:06.1086 |  Info |    %JTAlert_AlertType% : Alert Type |
2020-06-07 22:46:06.1086 |  Info | %JTAlert_AlertTrigger% : Alert Trigger |
2020-06-07 22:46:06.1086 |  Info |       %JTAlert_Decode% : CQ VK3AMA QF22 |
2020-06-07 22:46:06.1086 |  Info |         %JTAlert_Call% : VK3AMA |
2020-06-07 22:46:06.1086 |  Info |         %JTAlert_Date% : 2020-06-07 |
2020-06-07 22:46:06.1086 |  Info |         %JTAlert_Time% : 22:46 |
2020-06-07 22:46:06.1086 |  Info |         %JTAlert_Band% : 6m |
2020-06-07 22:46:06.1086 |  Info |         %JTAlert_Mode% : FT8 |
2020-06-07 22:46:06.1086 |  Info |          %JTAlert_QRG% : 50313 |
2020-06-07 22:46:06.1086 |  Info |           %JTAlert_DF% : 2134 |
2020-06-07 22:46:06.1086 |  Info |           %JTAlert_DB% : -10 |
2020-06-07 22:46:06.1086 |  Info |         %JTAlert_Dxcc% : 150 |
2020-06-07 22:46:06.1086 |  Info |      %JTAlert_Country% : Australia |
2020-06-07 22:46:06.1086 |  Info | %JTAlert_MthonCountry% : Australia |
2020-06-07 22:46:06.1135 |  Info |       %JTAlert_CQZone% : 30 |
2020-06-07 22:46:06.1135 |  Info |    %JTAlert_Continent% : OC |
2020-06-07 22:46:06.1135 |  Info |        %JTAlert_State% :  |
2020-06-07 22:46:06.1135 |  Info |         %JTAlert_Grid% : QF22 |
2020-06-07 22:46:06.1135 |  Info |       %JTAlert_Prefix% : VK3 |
2020-06-07 22:46:06.1135 |  Info |      %JTAlert_Bearing% : 45 |
2020-06-07 22:46:06.1135 |  Info |     %JTAlert_Distance% : 12345 |
2020-06-07 22:46:06.1135 |  Info |         %JTAlert_Eqsl% : Yes |
2020-06-07 22:46:06.1135 |  Info |         %JTAlert_Lotw% : Yes |
2020-06-07 22:46:06.1135 |  Info |     %JTAlert_LotwDate% : 2019-10-28 |

Let me know what you find.

de Laurie VK3AMA



locked Re: JTalert Ver. 2.16.4 is not logging the seconds

Elie Kadi <eliekadi@...>
 

Thank you Joe,

73, OD5KU Elie

On Sun, Jun 7, 2020 at 11:51 PM Joe Subich, W4TV <lists@...> wrote:

 > How can I have the JTalert log the time with the seconds.

Read the documentation!

Manage Settings -> Logging -> Logging Options

scroll down to ""Log seconds in time_on and time_off values"

Check the box.


73,

    ... Joe, W4TV


On 2020-06-07 3:47 PM, Elie Kadi wrote:
> Hello Group,
>
> How can I have the JTalert log the time with the seconds.
> This as in HRD logbook it is only showing 00 after the hour and the minute
> Thank you and 73 de Elie OD5KU
>





locked Re: African Italy, European Turkey and ITU Vienna. #FT8

HamApps Support (VK3AMA)
 

On 7/06/2020 7:32 am, asobel@... wrote:

I can make it easier for you. Please let me know which DXCC code is used for each  of the WAE entities as you see below:

There are no dxcc codes for WAE countries. The WAE country is determined by examining the structure of the Callsign and looking for any specific callsign overrides in the cty.dat file.

If you want me to look into what WAE callsigns JTAlert is finding during the Scan you will need to send me an ADIF export of your Log.

de Laurie VK3AMA


locked Re: JTAlert stops reporting decodes and logging to HRD sporadically #HRD

HamApps Support (VK3AMA)
 

On 7/06/2020 9:22 pm, Michael, DJ2VA wrote:
I was using several previous versions of JTAlert, WSJT-X and Hamradio Deluxe. Reporting Alerts and logging to HRD 6.7.0.xxx worked fine until I upgraded to JTAlert 2.16.6 and WSJT-X 2.2.0 RC3.
Now happens again and again, that JTAlert stops reporting decodes after a random period of time (several minutes). At the same time QSOs are no longer logged to HRD. Leaving everything on its own it takes again several minutes and suddenyl reporting starts again, also logging to HRD works again.

I could also force JTAlert to start reporting / logging, by closing and restarting JTAlert.
Does anybody else recognize that? Any ideas how to solve that problem?

73,
Michael

Make sure your not running WSJT-X with elevated privileges (set to run as Administrator).
Also try the latest builds of JTAlert and WSJT-X.
WSJT-X is now at 2.2.1 and the latest JTAlert build can be found in this post... https://hamapps.groups.io/g/Support/message/30164

de Laurie VK3AMA