Date   

locked JTAlert 2.16.5 working with WSJT-X 2.2.0.rc1

Jim AF5FH
 

Downloaded WSJT-X 2.2.0.rc1 and installed. So far have made multiple contacts using FT8 on several bands. No issues with JTAlert. Contacts are being logged to DXKeeper and uploaded to eQSL and LoTW.

Thanks!

73,
Jim AF5FH


locked JTDX AND JTALERT

F6HRP Alain <f6hrp@...>
 

hello I use JTDX and JTALert and I have a question:
in the window of jtalert when i click on a callsign how done so that enabletx of jtdx not in red (TX)
73 de alain F6HRP/TM22P
 
What do you want to do ?
New mailCopy
 
What do you want to do ?
New mailCopy


locked Re: Zones Problem

Jim N6VH
 


On 5/10/2020 6:20 PM, WB8ASI Herb wrote:
...and Log4OM also has the correct zones in its Main UI window, however something goes wrong upon the logging of the QSO.  It happens over and over again.  Guess we need more chatter on the Log4OM forum to get some attention.  Jim, I switched to HamQTH per your suggestion.  73 Herb WB8ASI

Herb,

Testing with the call N3BNA, Log4OM has the zones as CQ 5 and ITU 6, and it gets logged that way. ITU should be 8. This happens whether I have Log4OM set to do no lookups, lookups from QRZ, or from HamQTH. It seems that if Log4OM doesn't know the correct zone, it enters either a "5" or "0" for the CQ zone and "6" for ITU. The odd thingis, HamQTH does have the correct zones, but they apparently weren't used, even when I had lookups set for HamQTH.

You're right - we should put this discussion on the Log4OM forum, since the problem is clearly not on the JTAlert end, and there is really nothing that can be done about it in JTAlert.

73,

Jim N6VH


locked Re: Losing connection to 2.2.0-rc1

WB5JJJ - George
 

Similar events here as posted below.
--
73's
George - WB5JJJ


locked Losing connection to 2.2.0-rc1

Jon KM8V
 

I seems like 2.16.5 is losing it's connection to WSJT-X 2.2.0-rc1. After a few minutes, it stops highlighting, logging, etc and needs to be restarted to establish the connection. 


locked Failure to log to HRD LB after updates

WB5JJJ - George
 

I updated to 2.16.5 a few days ago and all was good with WSJTx v2.1.2 configurations.  

Today I updated to WSJTx v2.2.0-rc1 today and noticed that some contacts were not displayed in the JTA grid and if worked, ultimately not logged to HRD LB.  However, if the call was displayed, it logged.   Rolled back to WSJTx v2.1.2 and all returned to normal display and logging.  
--
73's
George - WB5JJJ


locked Re: Logging failures do not update worked before information

Michael Black
 

Bill...how many QSOs do you have and how big is your database?

I ran into a couple of users there their mdb file had grown way too big and we had to backup/restore/compact and their update rates improved considerably.
There's a 2GB limit on MDB files too.

de Mike W9MDB




On Monday, May 11, 2020, 06:37:38 AM CDT, g4wjs <bill.8@...> wrote:


On 10/05/2020 23:22, HamApps Support (VK3AMA) wrote:
On 10/05/2020 6:22 am, g4wjs wrote:
Hi Laurie,

it seems that when JTAlert cannot confirm logging of a QSO in the configured logging application it does not update its internal worked before database. Often these logging failures are due to slow updates to the logging application even though the log is eventually updated. Restarting JTAlert does sort it out but until then it is easy to mistakenly work the same station twice.



-- 
73
Bill
G4WJS.
Hi Bill,

Your correct, the internal B4 cache (held in memory) does not get updated if JTAlert is unable to confirm a QSO was logged.

What Logger are you using that is experiencing the delays?

If your logger is consistently slow in writing the QSO to the log file/database and your happy that QSOs are reliably getting logged, there is the option is to turn on the "Do not check or report logging success/failure" serring, under the Logging section of the Settings (scroll the checkbox display down). With that set, JTAlert will set the B4 status regardless and not perform any code-blocking checks.

There is the option to increase the QSO check time, but that can be problematic, especially with the short period FT4, as the delay QSO check delay, which is blocking the UI thread, can extend into the new decode period and JTAlert may miss the period. The main JTAlert code is single-threaded and synchronous (no async functionality) so any additional delay added to the QSO logged check function blocks there entire code.

Rather than restarting JTAlert you can use the "Alerts -> Clear B4 cache" menu (2nd from the top).

de Laurie VK3AMA

Hi Laurie,

I am using DXKeeper for logging. My delay before checking is set to 8 seconds which is perfectly adequate 99% or more of the time, but occasionally when my machine is particularly busy it trips up. Thanks for the tip on clearing the B4 cache. How about my suggestion of a "Retry" button alongside the "Ok" button on the error message about not confirming the logging success, in my case that would cover all the cases as far as I know, assuming a successful retry that finds the logged QSO goes on to update the worked B4 cache in JTAlert.

73
Bill
G4WJS.


--
73
Bill
G4WJS.


locked Re: Logging failures do not update worked before information

g4wjs
 

On 10/05/2020 23:22, HamApps Support (VK3AMA) wrote:
On 10/05/2020 6:22 am, g4wjs wrote:
Hi Laurie,

it seems that when JTAlert cannot confirm logging of a QSO in the configured logging application it does not update its internal worked before database. Often these logging failures are due to slow updates to the logging application even though the log is eventually updated. Restarting JTAlert does sort it out but until then it is easy to mistakenly work the same station twice.



-- 
73
Bill
G4WJS.
Hi Bill,

Your correct, the internal B4 cache (held in memory) does not get updated if JTAlert is unable to confirm a QSO was logged.

What Logger are you using that is experiencing the delays?

If your logger is consistently slow in writing the QSO to the log file/database and your happy that QSOs are reliably getting logged, there is the option is to turn on the "Do not check or report logging success/failure" serring, under the Logging section of the Settings (scroll the checkbox display down). With that set, JTAlert will set the B4 status regardless and not perform any code-blocking checks.

There is the option to increase the QSO check time, but that can be problematic, especially with the short period FT4, as the delay QSO check delay, which is blocking the UI thread, can extend into the new decode period and JTAlert may miss the period. The main JTAlert code is single-threaded and synchronous (no async functionality) so any additional delay added to the QSO logged check function blocks there entire code.

Rather than restarting JTAlert you can use the "Alerts -> Clear B4 cache" menu (2nd from the top).

de Laurie VK3AMA

Hi Laurie,

I am using DXKeeper for logging. My delay before checking is set to 8 seconds which is perfectly adequate 99% or more of the time, but occasionally when my machine is particularly busy it trips up. Thanks for the tip on clearing the B4 cache. How about my suggestion of a "Retry" button alongside the "Ok" button on the error message about not confirming the logging success, in my case that would cover all the cases as far as I know, assuming a successful retry that finds the logged QSO goes on to update the worked B4 cache in JTAlert.

73
Bill
G4WJS.


--
73
Bill
G4WJS.


locked Re: I miss the old layout

Uwe, DG2YCB
 

Hi Laurie,

Thank you for your answer. Yes, I understand your point of view. However, allow me to suggest another solution that could meet both aspects:

At the "B" versions of my wsjt-x clones I placed a small switchable object in the top left corner to toggle Controls on/off without interfering the scale of teh Wide Graph window. Works well. Couldn't that be a solution for JTAlert too?

I don't know what it's for, but sometimes I see at the JTAlert window a small triangle/arrow. Couldn't that be used to toogle menu on/off? See screenshot below including an idea how it could look like when menus are disabled: 



73 de Uwe, DG2YCB


locked Re: JTAlert 2.16.5 Download

chas cartmel
 

Not had an issue with this version or any others with any of the AV software I have used in the past.

 

 

Charlie

G4EST

www.g4est.me.uk

 

 

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of Jim N6VH
Sent: 10 May 2020 23:05
To: Support@HamApps.groups.io
Subject: Re: [HamApps] JTAlert 2.16.5 Download

 

On 5/10/2020 10:15 AM, Robert T wrote:

 

Has anyone been able to download and successfully install ver 2.16.5 without their virus scan deleting the install saying it has a virus?

 

Bob, K2RET


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


locked New Marathon visual alert fault \ It's about priority

asobel@...
 

The problem was solved by increasing the priority of marathon. It is
apparent that verbal alerts enjoy different priority then visual alerts.

Amos 4X4MF

============
I am using the CQ Marathon alert on JTAlert 2.16.5 and earlier. The CQ
Marathon is producing a lot of verbal alerts but most of the time the visual
alert on both the WSJT-X and JTAlert displays are missing which makes the
alert quite useless.

For your information, I am using 4 instances of WSJT-X and JTAlert.

Please fix it ASAP.

Amos Sobel 4X4MF


locked Re: The call database shows that I operate from MN, I have never had an address there #FT8

John
 

QRZ.com has you in OR, that is where the info came from probably, change it at
QRZ.com.

John
VE3KKQ

---------- Original Message ----------
From: aa7g.gert@gmail.com
Date: May 10, 2020 at 11:16 PM


The JTAlert Call database shows that I operate from MN but the thing is I have
never had an address in that state. I don´t know why I have been associated
with that state in the call database. There are no official sources that lists
me in MN whatsoever and there never have been. Someone must have added AA7G in
MN to the call database so can that someone please correct my call to show ME
instead since I do all my FT8 operating from Maine. Thank you in advance,

Gert, AA7G with FCC address in Oregon but operating from Maine



locked The call database shows that I operate from MN, I have never had an address there #FT8

aa7g.gert@...
 

The JTAlert Call database shows that I operate from MN but the thing is I have never had an address in that state. I don´t know why I have been associated with that state in the call database. There are no official sources that lists me in MN whatsoever and there never have been. Someone must have added AA7G in MN to the call database so can that someone please correct my call to show ME instead since I do all my FT8 operating from Maine. Thank you in advance,

Gert, AA7G with FCC address in Oregon but operating from Maine


locked Re: JTAlert 2.16.5 Download

Kent Olsen
 

I did have a problem "downloading" it. I am using Windows Defender. I went into Windows settings under Update and Security. Windows Security, Virus & Threat Protection then Protection History where it showed "Threat blocked". I was able to restore the downloaded file from there.

Thanks
73
Kent
N6WT


On Sun, May 10, 2020 at 7:46 PM neil_zampella <neilz@...> wrote:

Yep .. I've never had a problem with AVG Internet Security.

Neil, KN3ILZ

On Sun, May 10, 2020 at 01:15 PM, Robert T wrote:

Has anyone been able to download and successfully install ver 2.16.5 without their virus scan deleting the install saying it has a virus?
 
Bob, K2RET


locked Re: JTAlert 2.16.5 Download

neil_zampella
 

Yep .. I've never had a problem with AVG Internet Security.

Neil, KN3ILZ


On Sun, May 10, 2020 at 01:15 PM, Robert T wrote:

Has anyone been able to download and successfully install ver 2.16.5 without their virus scan deleting the install saying it has a virus?
 
Bob, K2RET


locked Re: JTAlert 2.16.5 not highlighting Wanted Callsigns consistently?

Jim Reisert AD1C
 

Thanks Laurie. I did not know about the priorities. I assumed a
Wanted Callsign would always be the highest priority. I don't know
why anyone would not want it this way. Presumably, you added it
because you NEED to see that call highlighted for some reason.

73 - Jim

On Sun, May 10, 2020 at 4:23 PM HamApps Support (VK3AMA) via groups.io
<vk3ama.ham.apps=gmail.com@groups.io> wrote:

On 11/05/2020 3:10 am, Jim Reisert AD1C wrote:

Laurie, thanks for updating JTAlert in anticipation of the new RC of WSJT-X.

It seems that 2.16.5 may not be highlighting Wanted Callsigns
consistently. Example: KM4MQC is calling CQ on 10 meter FT8. I
right-clicked and added the call to my Wanted Callsigns list. The
next time he called CQ, JTAlert still showed a light-blue background
instead of a purple background.

Earlier to test this, I reverted to 2.16.4, and I did the same thing
for K1DG when he was calling CQ on 17m. His Wanted Callsign
highlighted as expected.

Has anyone else noticed this?

--
Jim Reisert AD1C


Jim,

This is not a defect, but expected behavior when a Wanted Callsign is generating other Alerts.

A Wanted Callsign alert is, by default, lower in priority than all the other Wanted Alerts.
Any higher priority triggered Alerts will influence how the Callsign is colored overriding any potential Wanted Call coloring.

If you had added a Callsign that was not generating any Alerts as a Wanted Callsign then when next decoded the Callsign would have been colored with the Wanted Alert colors.

You can adjust the Alert priorities under the "Alerts->Alerts Priority" section of the Settings window.

de Laurie VK3AMA



--
Jim Reisert AD1C, <jjreisert@alum.mit.edu>, http://www.ad1c.us


locked Re: Zones Problem

WB8ASI Herb
 

...and Log4OM also has the correct zones in its Main UI window, however something goes wrong upon the logging of the QSO.  It happens over and over again.  Guess we need more chatter on the Log4OM forum to get some attention.  Jim, I switched to HamQTH per your suggestion.  73 Herb WB8ASI

On May 10, 2020 at 9:07 PM Jim N6VH <N6VH@...> wrote:

Dave,

That isn't true. Log4OM does receive the correct zones from JTAlert, unless JTAlert doesn't have a zone to send (very rare). The problem is what Log4OM does with the info. As I already said in an earlier post, if Log4OM is set to do lookups, it will overwrite the info that is sent to it from JTAlert. If it doesn't get the ifo from QRZ (or wherever) it puts in either a "0" or a zone number that might not be correct. In the case of a station in the US, that will be "5" for the CQ zone. As I said in an earlier post, I tested this both with and without using lookups in Log4OM. If I didn't have Log4OM do lookups, it used the zones sent to it from JTAlert. If I had Log4OM do lookups from QRZ, using a call that QRZ didn't have zones for, then it used arbitrary zone numbers rather than the zones from JTAlert. So, yes, Log4OM does get the zones from JTAlert. The problem is what it does with them.

73,

Jim N6VH

On 5/10/2020 4:03 PM, Dave Garber wrote:
That's what I was trying to say.  Log4om is not receiving any correct info on itu and cq zones from j talert.  

sent by my LG phone

On Sun, May 10, 2020, 6:21 PM HamApps Support (VK3AMA), < vk3ama.ham.apps@...> wrote:
On 10/05/2020 12:58 pm, Dave Garber wrote:
> I suspect an issue with adi from jtalert

It is not a JTAlert problem. If JTAlert shows zones in the log fields
area, that is what gets sent in the ADIF packet to Log4OM.

If a zone is unknown than there will be no zone data in the adif packet
sent. JTAlert deliberately does not send any Zone numbers if the value
is NOT greater than zero. Similarly any data fields that are empty the
corresponding adif field is simply not included in the adif packet. That
is JTAlert only includes adif fields for non-empty and non-zero (> 1)
data fields.

The problem is clearly with Log4OM V2.

de Laurie VK3AMA





 


locked Re: Zones Problem

Jim N6VH
 

Dave,

That isn't true. Log4OM does receive the correct zones from JTAlert, unless JTAlert doesn't have a zone to send (very rare). The problem is what Log4OM does with the info. As I already said in an earlier post, if Log4OM is set to do lookups, it will overwrite the info that is sent to it from JTAlert. If it doesn't get the ifo from QRZ (or wherever) it puts in either a "0" or a zone number that might not be correct. In the case of a station in the US, that will be "5" for the CQ zone. As I said in an earlier post, I tested this both with and without using lookups in Log4OM. If I didn't have Log4OM do lookups, it used the zones sent to it from JTAlert. If I had Log4OM do lookups from QRZ, using a call that QRZ didn't have zones for, then it used arbitrary zone numbers rather than the zones from JTAlert. So, yes, Log4OM does get the zones from JTAlert. The problem is what it does with them.

73,

Jim N6VH

On 5/10/2020 4:03 PM, Dave Garber wrote:
That's what I was trying to say.  Log4om is not receiving any correct info on itu and cq zones from j talert.  

sent by my LG phone

On Sun, May 10, 2020, 6:21 PM HamApps Support (VK3AMA), <vk3ama.ham.apps@...> wrote:
On 10/05/2020 12:58 pm, Dave Garber wrote:
> I suspect an issue with adi from jtalert

It is not a JTAlert problem. If JTAlert shows zones in the log fields
area, that is what gets sent in the ADIF packet to Log4OM.

If a zone is unknown than there will be no zone data in the adif packet
sent. JTAlert deliberately does not send any Zone numbers if the value
is NOT greater than zero. Similarly any data fields that are empty the
corresponding adif field is simply not included in the adif packet. That
is JTAlert only includes adif fields for non-empty and non-zero (> 1)
data fields.

The problem is clearly with Log4OM V2.

de Laurie VK3AMA





locked Re: Zones Problem

Dave Garber
 

That's what I was trying to say.  Log4om is not receiving any correct info on itu and cq zones from j talert.  

sent by my LG phone

On Sun, May 10, 2020, 6:21 PM HamApps Support (VK3AMA), <vk3ama.ham.apps@...> wrote:
On 10/05/2020 12:58 pm, Dave Garber wrote:
> I suspect an issue with adi from jtalert

It is not a JTAlert problem. If JTAlert shows zones in the log fields
area, that is what gets sent in the ADIF packet to Log4OM.

If a zone is unknown than there will be no zone data in the adif packet
sent. JTAlert deliberately does not send any Zone numbers if the value
is NOT greater than zero. Similarly any data fields that are empty the
corresponding adif field is simply not included in the adif packet. That
is JTAlert only includes adif fields for non-empty and non-zero (> 1)
data fields.

The problem is clearly with Log4OM V2.

de Laurie VK3AMA





locked Re: JTAlert 2.16.5 not highlighting Wanted Callsigns consistently?

HamApps Support (VK3AMA)
 

On 11/05/2020 3:10 am, Jim Reisert AD1C wrote:
Laurie, thanks for updating JTAlert in anticipation of the new RC of WSJT-X.

It seems that 2.16.5 may not be highlighting Wanted Callsigns
consistently.  Example:  KM4MQC is calling CQ on 10 meter FT8.  I
right-clicked and added the call to my Wanted Callsigns list.  The
next time he called CQ, JTAlert still showed a light-blue background
instead of a purple background.

Earlier to test this, I reverted to 2.16.4, and I did the same thing
for K1DG when he was calling CQ on 17m.  His Wanted Callsign
highlighted as expected.

Has anyone else noticed this?

-- Jim Reisert AD1C

Jim,

This is not a defect, but expected behavior when a Wanted Callsign is generating other Alerts.

A Wanted Callsign alert is, by default, lower in priority than all the other Wanted Alerts.
Any higher priority triggered Alerts will influence how the Callsign is colored overriding any potential Wanted Call coloring.

If you had added a Callsign that was not generating any Alerts as a Wanted Callsign then when next decoded the Callsign would have been colored with the Wanted Alert colors.

You can adjust the Alert priorities under the "Alerts->Alerts Priority" section of the Settings window.

de Laurie VK3AMA

4941 - 4960 of 34378