Topics

Issue after band change


Uwe, DG2YCB
 

Hi Laurie,

With JTAlert 2.16.14 and WSJT-X v2.3.0-rc1 the old issue is back, that SOMETIMES after a band change JTAlert recognizes late decodes coming from the past cycle as if they were coming from the new cycle (= new band). I don't know if you remember we had this a few years ago but luckily you were able to fix it. I've seen it a few times again now. Each time I changed the band exactly at the end of a cycle. JTAlert identified the band change correctly, but nevertheless a couple of times then it displayed late deodes coming from WSJT-X falsly as if they were already coming from the new band. (Usually after a band change one cycle is skipped.) As said, this is a new behavior which was not there with WSJT-X v2.2.2 together with the earlier versions of JTAlert I had in use.
I remember that you changed something a couple of weeks ago regarding some deatails of the timing, is that right? Might that have caused this? Let me know if you want me to do some more tests (e.g. with a beta version of JTAlert).

73 de Uwe, DG2YCB


Dave Garber
 

before band changing on ft8 or ft4, i always click on monitor (in wsjt)to disable it, before i change
Dave Garber
VE3WEJ / VE3IE


On Sat, Oct 17, 2020 at 12:02 PM Uwe, DG2YCB <DG2YCB@...> wrote:
Hi Laurie,

With JTAlert 2.16.14 and WSJT-X v2.3.0-rc1 the old issue is back, that SOMETIMES after a band change JTAlert recognizes late decodes coming from the past cycle as if they were coming from the new cycle (= new band). I don't know if you remember we had this a few years ago but luckily you were able to fix it. I've seen it a few times again now. Each time I changed the band exactly at the end of a cycle. JTAlert identified the band change correctly, but nevertheless a couple of times then it displayed late deodes coming from WSJT-X falsly as if they were already coming from the new band. (Usually after a band change one cycle is skipped.) As said, this is a new behavior which was not there with WSJT-X v2.2.2 together with the earlier versions of JTAlert I had in use.
I remember that you changed something a couple of weeks ago regarding some deatails of the timing, is that right? Might that have caused this? Let me know if you want me to do some more tests (e.g. with a beta version of JTAlert).

73 de Uwe, DG2YCB


Uwe, DG2YCB
 

Laurie,

FYI: In the meantime I've changed WSJT-X's source code and caught/fixed the error there. Now at least my wsjt-x_improved versions should not generate any more false spots when a band change was performed.

73 de Uwe, DG2YCB


TomK
 

Might that also fix the ghost signal reports in WSJT?  Or has that been fixed already?

I note it here since JT Alert reports then as well and I was about to note it here.

I then realized it was the same way in WSJT so JTA simply picks it up as is.

Let me detail the problem here, just this once, since it affects both programs.

 

The “ghost” case is of no signal on waterfall but a malformed message is decoded

Thought it was JTA but then saw it was simply passed from WSJT’s decode.

It does not happen very often. Perhaps 1-2/month for me running 16/7.

Found an example …

 

WSJT’s decodes. Note: “CQ F/MM FK16” at bottom

Shows strong -3 signal. But waterfall below shows absolutely no signal.

Waterfall is using my custom low-signal very-high-amplification palette.

For ref, signal to right at 902 is -13 so ghost’s -03 should appear WICKED bright!

But there is no discernable signal whatsoever.

A commonality of these ”ghosts” is there usually is no call sign in the message.

Just thought I’d mention the small nagging issue of little import.

 

TomK 73

 

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of Uwe, DG2YCB
Sent: Sunday, October 18, 2020 7:34 AM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Issue after band change

 

Laurie,

FYI: In the meantime I've changed WSJT-X's source code and caught/fixed the error there. Now at least my wsjt-x_improved versions should not generate any more false spots when a band change was performed.

73 de Uwe, DG2YCB


Laurie, VK3AMA
 

On 19/10/2020 8:05 am, TomK wrote:
But waterfall below shows absolutely no signal.
Are you sure?
F/MM was decoded at 2389Hz, but your waterfall image is limited to 1500Hz.

de Laurie VK3AMA


Laurie, VK3AMA
 

On 18/10/2020 10:33 pm, Uwe, DG2YCB wrote:
FYI: In the meantime I've changed WSJT-X's source code and caught/fixed the error there. Now at least my wsjt-x_improved versions should not generate any more false spots when a band change was performed.

73 de Uwe, DG2YCB
I strongly suggest you submit a patch to the WSJTX dev team for this fix.

de Laurie VK3AMA


neil_zampella
 

Have you submitted that to the WSJT-X group for inclusion in the main branch of the code?

Neil, KN3ILZ


TomK
 

Blush! I inserted the wrong capture - then misread it, oy!

But, YES, the symptom I noted has no waterfall trace at all.
I've experienced it at least 10 times over the last 6 months.
Each time I double checked the screens and waterfall. Zilch.

It's a minor but weird issue. Unlike the wrong capture I inserted,
almost all of the ghosts are for calls from wanted areas like Chine, India,
etc.
Made me think someone was hacking the msg format to trigger the effect.

Let me see if I can find a relevant capture. Hopefully still have one.
Apologies for wasting time, Laurie.
TomK 73

-----Original Message-----
From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of
Laurie, VK3AMA
Sent: Sunday, October 18, 2020 5:23 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Issue after band change



On 19/10/2020 8:05 am, TomK wrote:
But waterfall below shows absolutely no signal.
Are you sure?
F/MM was decoded at 2389Hz, but your waterfall image is limited to 1500Hz.

de Laurie VK3AMA


TomK
 

On a 2nd note, Laurie, did you see my msg about a JTA error popup and also
not sending to QRZ even though it is enabled?
Had also asked how to reset JTA config or how to do a complete folder level
uninstall (what folders that is to delete)
If you get a chance, scan for my msg from 1-2 days ago. Has more detail.
Thanks for your time and great coding!
TomK 73

-----Original Message-----
From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of
Laurie, VK3AMA
Sent: Sunday, October 18, 2020 5:23 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Issue after band change



On 19/10/2020 8:05 am, TomK wrote:
But waterfall below shows absolutely no signal.
Are you sure?
F/MM was decoded at 2389Hz, but your waterfall image is limited to 1500Hz.

de Laurie VK3AMA


Michael Black
 

The folder to delete is

\Users\[username]\AppData\Local\HamApps

Mike W9MDB




On Monday, October 19, 2020, 07:41:16 AM CDT, TomK <qso@...> wrote:


On a 2nd note, Laurie, did you see my msg about a JTA error popup and also
not sending to QRZ even though it is enabled?
Had also asked how to reset JTA config or how to do a complete folder level
uninstall (what folders that is to delete)
If you get a chance, scan for my msg from 1-2 days ago. Has more detail.
Thanks for your time and great coding!
TomK 73


-----Original Message-----
From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of
Laurie, VK3AMA
Sent: Sunday, October 18, 2020 5:23 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Issue after band change



On 19/10/2020 8:05 am, TomK wrote:
> But waterfall below shows absolutely no signal.
Are you sure?
F/MM was decoded at 2389Hz, but your waterfall image is limited to 1500Hz.

de Laurie VK3AMA














Uwe, DG2YCB
 

I am already in contact with Bill, G4WJS. I shared with him details about the issue on band change and how I fixed it.

@ TomK: I don't think the problem you mentioned is caused by the same inconsistencies in the code. However, as far as I can remember, some other inconsistencies have already been identified that should be addressed for the GA release. So let's see what gets fixed and what doesn't.

73 de Uwe, DG2YCB