locked Re: Seeing a Lot of Skipping Decodes Every Other Sequence FT8

Hasan Schiers N0AN

I have no idea if it's the cause, Laurie. I will stop using it simply because when it runs in my system, X misbehaves. I can't exactly stop using X.

We pursued all sorts of diagnostics in X and learned absolutely nothing.

I really don't know a darn thing, so absent anything concrete,  all I can do is eliminate what I can,  one thing at a time and see what happens.

That's what I'm stuck with, which is very disappointing because JTA is one of my favorite programs.

Maybe some day someone will stumble on to the cure for this particular problem.  There have been plenty of other reports of missing decode sequences where JTA is not being used.

Something isn't right. Maybe more than one thing.

73, N0AN 

On Mon, Mar 16, 2020, 6:11 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
On 17/03/2020 9:26 am, Hasan Schiers N0AN wrote:
On a busy FT8 Band like 20m, I'm seeing more and more tendencies to skip an entire sequence following a decoded sequence.

I'm on 20m FT8 now and it is happening nearly every other sequence, or it will decode 2 seq in a row and then start skipping again, without any intervention on my part.

Then it will start decoding again, do several sequences in a row (with me not transmitting, just monitoring), and then skip another sequence. I just watched it do it again while typing.

I have stopped interacting with the program, I am just letting it run with no intervention, receiving:

Two more in a row of > 20 stations
Then skipped an entire sequence
Full seq of decodes > 20
Skipped the next sequence
Full seq of decodes > 20 stations
Skipped the next seq
Full seq of decodes > 20 stations
Skipped the next seq: no decodes
Full seq of decodes > 20 stations
Skipped the next seq: no decodes
Full seq of decodes > 20 stations
Skipped the next seq.

The computer running the X software is not being touched. I'm typing on a different machine.

WSJT-X 2.12, Win10 Pro, Core I5 3.2 GHz,  8 gB of RAM (Win10 Pro is fully up to date)

While receiving CPU is about 6 %
While decoding at end of seq: 30-50%
When it skips a cycle, CPU does not go nearly as high, perhaps 25% max

UDP > JTAlert
JTAlert Rebroadcast UDP > DXLab SpotCollector

I have WSTX folder excluded from virus check
I have the WSJTX appdata folder excluded.

I just stopped JTAlert and am now having WSJT-X talk UDP directly to SpotCollector.

Every sequence is decoding > 20 stations, No Skips
CPU Utilization is 30 to 50 % as before at the decode
It's been about 20 minutes with absolutely perfect decoding of > 20 stations every sequence. I only made one change.

Last decode seq, the CPU went as high as 66% ...still got perfect decodes.

I have no explanation or theories to offer, but if I want consistent decodes I can't run JTAlert ...and I love JTAlert, but I'm tired of fighting this.



The only direct interaction JTAlert has with WSJT-X is when it either sends an instruction that a Callsign has been clicked or when painting the decodes with Alert coloring, both of which occur AFTER WSJT-X has produced its decodes. Unless decodes are excessively delayed such that JTAlert is sending coloring instructions to WSJT-X long after a new period has started, there is nothing that JTAlert is doing that would interfere with WSJT-X decoding. try turning the Decodes coloring off in JTAlert.

If your not happy with JTAlert and believe it is the true cause of random WSJT-X decode failings, the answer is simple, don't use it!

de Laurie VK3AMA


Join main@WSJTX.groups.io to automatically receive all group messages.