|
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.
|
|
|
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.
FWIW,
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
|
|
|
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 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.
FWIW,
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
Hasan
|
|
|
Hasan,
You might look at the size of the spots database
...\SpotCollector\Spots.mdb. If its large then you may wish to
aggressively prune it size ( throw away non-recent spots ) .. Its
under spot collector> config>Spot Database tab.. Each
decode that JTAlert passes to dxlab results in a spot collector
lookup ( i think ). I have mine set to Prune entries older than
0.1 days and prune hourly..
FMMV
AL, K0VM
On 3/16/2020 5:26 PM, 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.
|
|
|
Hi Al, It works perfectly with SpotCollector and I prune like you do, so the file is very small. Good suggestion, though. No failures to decode now in hours of operation when X feeds SpotCollector directly.
It's a mystery to me.
Hasan,
You might look at the size of the spots database
...\SpotCollector\Spots.mdb. If its large then you may wish to
aggressively prune it size ( throw away non-recent spots ) .. Its
under spot collector> config>Spot Database tab.. Each
decode that JTAlert passes to dxlab results in a spot collector
lookup ( i think ). I have mine set to Prune entries older than
0.1 days and prune hourly..
FMMV
AL, K0VM
On 3/16/2020 5:26 PM, 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.
|
|
|
Bill Somerville
Hi Hasan,
can you try a test with WSJT-X/JTAlert
for me please. Go to "Settings->Reporting->UDP Server" and
uncheck "Accept UDP requests". Please report if that resolves the
issue?
Note I am not proposing this as a
solution as it will disable important features of the JTAlert
WSJT-X interoperation, but will be a useful data point.
73
Bill
G4WJS.
On 16/03/2020 23:54, Hasan Schiers N0AN
wrote:
toggle quoted message
Show quoted text
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 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.
FWIW,
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
Hasan
|
|
|
Sure, first thing in the morning. I assume you want me to have x feeding JTA and JTA rebroadcast feeding SpotCollector?
On Mon, Mar 16, 2020, 7:40 PM Bill Somerville < g4wjs@...> wrote:
Hi Hasan,
can you try a test with WSJT-X/JTAlert
for me please. Go to "Settings->Reporting->UDP Server" and
uncheck "Accept UDP requests". Please report if that resolves the
issue?
Note I am not proposing this as a
solution as it will disable important features of the JTAlert
WSJT-X interoperation, but will be a useful data point.
73
Bill
G4WJS.
On 16/03/2020 23:54, Hasan Schiers N0AN
wrote:
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 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.
FWIW,
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
Hasan
|
|
|
Bill Somerville
Hi Hasan,
yes I would like WSJT-X and JTAlert
running. I don't know what you mean by having JTAlert rebroadcast
feeding SpotCollector. AFAIK the way that JTAlert posts local
spots to SpotCollector is via a TCP/IP conversation, that is not a
rebroadcast in any sense of that term.
73
Bill
G4WJS.
On 17/03/2020 00:44, Hasan Schiers N0AN
wrote:
toggle quoted message
Show quoted text
Sure, first thing in the morning. I assume you
want me to have x feeding JTA and JTA rebroadcast feeding
SpotCollector?
On Mon, Mar 16, 2020, 7:40 PM
Bill Somerville < g4wjs@...> wrote:
Hi Hasan,
can you try a test with WSJT-X/JTAlert for me please.
Go to "Settings->Reporting->UDP Server" and uncheck
"Accept UDP requests". Please report if that resolves the
issue?
Note I am not proposing this as a solution as it will
disable important features of the JTAlert WSJT-X
interoperation, but will be a useful data point.
73
Bill
G4WJS.
On 16/03/2020 23:54, Hasan Schiers N0AN wrote:
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 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.
FWIW,
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
Hasan
|
|
|
Bill,
JTA looks at X via UDP port 2237, and is not configurable. So to get spotter info to SpotCollector it needs to come in from a UDP port that is not in use. We get that from JTA's ability to rebroadcast an incoming 2237 UDP packet on 2337 for example.
So the flow is
X > JTA 2237 JTA Rebroadcast > 2337 > SotCollector
This way JTA gets data directly from X and JTA provides Rebroadcast data on 2337 for SpotCollector Hasan
On Mon, Mar 16, 2020, 7:49 PM Bill Somerville < g4wjs@...> wrote:
Hi Hasan,
yes I would like WSJT-X and JTAlert
running. I don't know what you mean by having JTAlert rebroadcast
feeding SpotCollector. AFAIK the way that JTAlert posts local
spots to SpotCollector is via a TCP/IP conversation, that is not a
rebroadcast in any sense of that term.
73
Bill
G4WJS.
On 17/03/2020 00:44, Hasan Schiers N0AN
wrote:
Sure, first thing in the morning. I assume you
want me to have x feeding JTA and JTA rebroadcast feeding
SpotCollector?
On Mon, Mar 16, 2020, 7:40 PM
Bill Somerville < g4wjs@...> wrote:
Hi Hasan,
can you try a test with WSJT-X/JTAlert for me please.
Go to "Settings->Reporting->UDP Server" and uncheck
"Accept UDP requests". Please report if that resolves the
issue?
Note I am not proposing this as a solution as it will
disable important features of the JTAlert WSJT-X
interoperation, but will be a useful data point.
73
Bill
G4WJS.
On 16/03/2020 23:54, Hasan Schiers N0AN wrote:
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 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.
FWIW,
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
Hasan
|
|
|
Bill Somerville
Hasan,
none of that makes any sense to me, and
is mostly incorrect. What are you trying to achieve?
Some corrections to your comments:
1) JTAlert is a UDP server listening on
the port it thinks WSJT-X (the UDP client) is sending to. It
discovers the port it should listen on by directly reading the
WSJT-X settings file. This is not recommended as it makes it
impossible for JTAlert to run on a separate host from WSJT-X, but
since JTAlert works directly with the WSJT-X UI windows it
probably doesn't matter that it does that.
2) Local spot information is sent by
JTAlert to SpotCollector using a TCP/IP server built into
SpotCollector, that is nothing to do with UDP.
3) The UDP "rebroadcast" (WSJT-X UDP
does not use broadcast, it is a client server protocol) that can
be enabled in JTAlert is there to pass on WSJT-X UDP traffic to
applications that cannot share that data directly JTAlert because
JTAlert is unicast UDP server which means it consumes WSJT-X
traffic rather than sharing it with other interested servers. This
feed is really only intended to pass on logged QSO messages. It
sounds like you are attempting to do far more than that, which I
don't recommend.
4) SpotCollector is able to act as a
server for WSJT-X UDP traffic. You should not be attempting to
"patch over" the limitations of JTAlert and SpotCollector that
mean neither is able to act as the multicast UDP server preferred
by the WSJT-X UDP protocol.
5) Do not attempt to have two unicast
UDP servers interoperating with one or more WSJT-X clients for
anything more that QSO logging. That is not supported and can
never work as the server authors intended.
JTAlert has a fully supported mechanism
for passing logged QSO information from WSJT-X to DXKeeper. That
plus JTAert's facility to post local spots to SpotCollector are
all you should be using if you run both JTAlert and DX Lab Suite.
When doing that you should (must IMHO) disable SpotCollector's
direct interoperation with WSJT-X, whether it be via port 2237 (or
whatever port has been specified in WSJT-X and SpotCollector), or
via some unsupported lash up trying to utilize JTAlert's UDP
"rebroadcast" facility.
73
Bill
G4WJS.
On 17/03/2020 01:04, Hasan Schiers N0AN
wrote:
toggle quoted message
Show quoted text
Bill,
JTA looks at X via UDP port 2237, and is not
configurable. So to get spotter info to SpotCollector it needs
to come in from a UDP port that is not in use. We get that
from JTA's ability to rebroadcast an incoming 2237 UDP packet
on 2337 for example.
So the flow is
X > JTA 2237
JTA Rebroadcast > 2337 > SotCollector
This way JTA gets data directly from X and JTA
provides Rebroadcast data on 2337 for SpotCollector
Hasan
On Mon, Mar 16, 2020, 7:49 PM
Bill Somerville < g4wjs@...> wrote:
Hi Hasan,
yes I would like WSJT-X and JTAlert running. I don't
know what you mean by having JTAlert rebroadcast feeding
SpotCollector. AFAIK the way that JTAlert posts local
spots to SpotCollector is via a TCP/IP conversation, that
is not a rebroadcast in any sense of that term.
73
Bill
G4WJS.
On 17/03/2020 00:44, Hasan Schiers N0AN wrote:
Sure, first thing in the morning. I assume
you want me to have x feeding JTA and JTA rebroadcast
feeding SpotCollector?
On Mon, Mar 16, 2020,
7:40 PM Bill Somerville < g4wjs@...>
wrote:
Hi Hasan,
can you try a test with WSJT-X/JTAlert for me
please. Go to "Settings->Reporting->UDP
Server" and uncheck "Accept UDP requests". Please
report if that resolves the issue?
Note I am not proposing this as a solution as
it will disable important features of the JTAlert
WSJT-X interoperation, but will be a useful data
point.
73
Bill
G4WJS.
On 16/03/2020 23:54, Hasan Schiers N0AN wrote:
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 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.
FWIW,
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
Hasan
|
|
|
Ok, obviously I'm not on the same page with all of this.
What I'm trying to do:
SpotCollector needs to be provided data from WSJT X JTA needs that same data.
As far as I understand, X communicates to JTA on a UDP port That port has to be 2237 as JTA doesn't allow use of another port.
SpotCollector requires a spot source from WSJTX. That spot is a UDP port in SpotCollector config.
If either of these apps communicate with X in another way, I don't know what it is.
JTA and SpotCollector can't be configured to use that same port in wsjtx.
I'll read your prior post in the morning in addition to anything you might add in replying to this.
On Mon, Mar 16, 2020, 8:23 PM Bill Somerville < g4wjs@...> wrote:
Hasan,
none of that makes any sense to me, and
is mostly incorrect. What are you trying to achieve?
Some corrections to your comments:
1) JTAlert is a UDP server listening on
the port it thinks WSJT-X (the UDP client) is sending to. It
discovers the port it should listen on by directly reading the
WSJT-X settings file. This is not recommended as it makes it
impossible for JTAlert to run on a separate host from WSJT-X, but
since JTAlert works directly with the WSJT-X UI windows it
probably doesn't matter that it does that.
2) Local spot information is sent by
JTAlert to SpotCollector using a TCP/IP server built into
SpotCollector, that is nothing to do with UDP.
3) The UDP "rebroadcast" (WSJT-X UDP
does not use broadcast, it is a client server protocol) that can
be enabled in JTAlert is there to pass on WSJT-X UDP traffic to
applications that cannot share that data directly JTAlert because
JTAlert is unicast UDP server which means it consumes WSJT-X
traffic rather than sharing it with other interested servers. This
feed is really only intended to pass on logged QSO messages. It
sounds like you are attempting to do far more than that, which I
don't recommend.
4) SpotCollector is able to act as a
server for WSJT-X UDP traffic. You should not be attempting to
"patch over" the limitations of JTAlert and SpotCollector that
mean neither is able to act as the multicast UDP server preferred
by the WSJT-X UDP protocol.
5) Do not attempt to have two unicast
UDP servers interoperating with one or more WSJT-X clients for
anything more that QSO logging. That is not supported and can
never work as the server authors intended.
JTAlert has a fully supported mechanism
for passing logged QSO information from WSJT-X to DXKeeper. That
plus JTAert's facility to post local spots to SpotCollector are
all you should be using if you run both JTAlert and DX Lab Suite.
When doing that you should (must IMHO) disable SpotCollector's
direct interoperation with WSJT-X, whether it be via port 2237 (or
whatever port has been specified in WSJT-X and SpotCollector), or
via some unsupported lash up trying to utilize JTAlert's UDP
"rebroadcast" facility.
73
Bill
G4WJS.
On 17/03/2020 01:04, Hasan Schiers N0AN
wrote:
Bill,
JTA looks at X via UDP port 2237, and is not
configurable. So to get spotter info to SpotCollector it needs
to come in from a UDP port that is not in use. We get that
from JTA's ability to rebroadcast an incoming 2237 UDP packet
on 2337 for example.
So the flow is
X > JTA 2237
JTA Rebroadcast > 2337 > SotCollector
This way JTA gets data directly from X and JTA
provides Rebroadcast data on 2337 for SpotCollector
Hasan
On Mon, Mar 16, 2020, 7:49 PM
Bill Somerville < g4wjs@...> wrote:
Hi Hasan,
yes I would like WSJT-X and JTAlert running. I don't
know what you mean by having JTAlert rebroadcast feeding
SpotCollector. AFAIK the way that JTAlert posts local
spots to SpotCollector is via a TCP/IP conversation, that
is not a rebroadcast in any sense of that term.
73
Bill
G4WJS.
On 17/03/2020 00:44, Hasan Schiers N0AN wrote:
Sure, first thing in the morning. I assume
you want me to have x feeding JTA and JTA rebroadcast
feeding SpotCollector?
On Mon, Mar 16, 2020,
7:40 PM Bill Somerville < g4wjs@...>
wrote:
Hi Hasan,
can you try a test with WSJT-X/JTAlert for me
please. Go to "Settings->Reporting->UDP
Server" and uncheck "Accept UDP requests". Please
report if that resolves the issue?
Note I am not proposing this as a solution as
it will disable important features of the JTAlert
WSJT-X interoperation, but will be a useful data
point.
73
Bill
G4WJS.
On 16/03/2020 23:54, Hasan Schiers N0AN wrote:
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 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.
FWIW,
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
Hasan
|
|
|
I see a point of confusion. Why does SpotCollector config have an entry for X specifying a UDP port, if it already gets those decodes from a TCP port?
Further, why does SpotCollector's Status light for X not light up unless I enable wsjtx as a spot source in SpotCollector config file. Also, unless I do enable x with a UDP port in SpotCollector config, I see no spots in SpotCollector from X.
May5you can see why I'm so confused. Hasan
On Mon, Mar 16, 2020, 8:38 PM Hasan Schiers N0AN via Groups.Io <hbasri.schiers6= gmail.com@groups.io> wrote: Ok, obviously I'm not on the same page with all of this.
What I'm trying to do:
SpotCollector needs to be provided data from WSJT X JTA needs that same data.
As far as I understand, X communicates to JTA on a UDP port That port has to be 2237 as JTA doesn't allow use of another port.
SpotCollector requires a spot source from WSJTX. That spot is a UDP port in SpotCollector config.
If either of these apps communicate with X in another way, I don't know what it is.
JTA and SpotCollector can't be configured to use that same port in wsjtx.
I'll read your prior post in the morning in addition to anything you might add in replying to this.
On Mon, Mar 16, 2020, 8:23 PM Bill Somerville < g4wjs@...> wrote:
Hasan,
none of that makes any sense to me, and
is mostly incorrect. What are you trying to achieve?
Some corrections to your comments:
1) JTAlert is a UDP server listening on
the port it thinks WSJT-X (the UDP client) is sending to. It
discovers the port it should listen on by directly reading the
WSJT-X settings file. This is not recommended as it makes it
impossible for JTAlert to run on a separate host from WSJT-X, but
since JTAlert works directly with the WSJT-X UI windows it
probably doesn't matter that it does that.
2) Local spot information is sent by
JTAlert to SpotCollector using a TCP/IP server built into
SpotCollector, that is nothing to do with UDP.
3) The UDP "rebroadcast" (WSJT-X UDP
does not use broadcast, it is a client server protocol) that can
be enabled in JTAlert is there to pass on WSJT-X UDP traffic to
applications that cannot share that data directly JTAlert because
JTAlert is unicast UDP server which means it consumes WSJT-X
traffic rather than sharing it with other interested servers. This
feed is really only intended to pass on logged QSO messages. It
sounds like you are attempting to do far more than that, which I
don't recommend.
4) SpotCollector is able to act as a
server for WSJT-X UDP traffic. You should not be attempting to
"patch over" the limitations of JTAlert and SpotCollector that
mean neither is able to act as the multicast UDP server preferred
by the WSJT-X UDP protocol.
5) Do not attempt to have two unicast
UDP servers interoperating with one or more WSJT-X clients for
anything more that QSO logging. That is not supported and can
never work as the server authors intended.
JTAlert has a fully supported mechanism
for passing logged QSO information from WSJT-X to DXKeeper. That
plus JTAert's facility to post local spots to SpotCollector are
all you should be using if you run both JTAlert and DX Lab Suite.
When doing that you should (must IMHO) disable SpotCollector's
direct interoperation with WSJT-X, whether it be via port 2237 (or
whatever port has been specified in WSJT-X and SpotCollector), or
via some unsupported lash up trying to utilize JTAlert's UDP
"rebroadcast" facility.
73
Bill
G4WJS.
On 17/03/2020 01:04, Hasan Schiers N0AN
wrote:
Bill,
JTA looks at X via UDP port 2237, and is not
configurable. So to get spotter info to SpotCollector it needs
to come in from a UDP port that is not in use. We get that
from JTA's ability to rebroadcast an incoming 2237 UDP packet
on 2337 for example.
So the flow is
X > JTA 2237
JTA Rebroadcast > 2337 > SotCollector
This way JTA gets data directly from X and JTA
provides Rebroadcast data on 2337 for SpotCollector
Hasan
On Mon, Mar 16, 2020, 7:49 PM
Bill Somerville < g4wjs@...> wrote:
Hi Hasan,
yes I would like WSJT-X and JTAlert running. I don't
know what you mean by having JTAlert rebroadcast feeding
SpotCollector. AFAIK the way that JTAlert posts local
spots to SpotCollector is via a TCP/IP conversation, that
is not a rebroadcast in any sense of that term.
73
Bill
G4WJS.
On 17/03/2020 00:44, Hasan Schiers N0AN wrote:
Sure, first thing in the morning. I assume
you want me to have x feeding JTA and JTA rebroadcast
feeding SpotCollector?
On Mon, Mar 16, 2020,
7:40 PM Bill Somerville < g4wjs@...>
wrote:
Hi Hasan,
can you try a test with WSJT-X/JTAlert for me
please. Go to "Settings->Reporting->UDP
Server" and uncheck "Accept UDP requests". Please
report if that resolves the issue?
Note I am not proposing this as a solution as
it will disable important features of the JTAlert
WSJT-X interoperation, but will be a useful data
point.
73
Bill
G4WJS.
On 16/03/2020 23:54, Hasan Schiers N0AN wrote:
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 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.
FWIW,
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
Hasan
|
|
|
Bill Somerville
Hasan,
have you read this article:
which is about interoperation between
DX Lab Suite and WSJT-X. Note particularly the last section on
"Limitations" and also note JTAlert is not part of that as there
is duplication of functionality between DX Lab Suite's direct
interaction with WSJT-X compared with using JTAlert as an
intermediary between WSJT-X and DX Lab Suite.
You should also read this article:
which documents how to set up JTAlert
as an intermediary between WSJT-X and DX Lab Suite, taking account
of the limitations discussed above.
A key point you should understand is
that the two articles describe mutually exclusive functionality.
You seem to be trying to ignore that mutual exclusivity and build
a monster that tries to do more than is sensible, recommended, or
supported.
73
Bill
G4WJS.
On 17/03/2020 01:46, Hasan Schiers N0AN
wrote:
toggle quoted message
Show quoted text
I see a point of confusion. Why does SpotCollector
config have an entry for X specifying a UDP port, if it already
gets those decodes from a TCP port?
Further, why does SpotCollector's Status light
for X not light up unless I enable wsjtx as a spot source in
SpotCollector config file. Also, unless I do enable x with a
UDP port in SpotCollector config, I see no spots in
SpotCollector from X.
May5you can see why I'm so confused.
Hasan
On Mon, Mar 16, 2020, 8:38 PM
Hasan Schiers N0AN via Groups.Io <hbasri.schiers6= gmail.com@groups.io>
wrote:
Ok, obviously I'm not on the same page with
all of this.
What I'm trying to do:
SpotCollector needs to be provided data from
WSJT X
JTA needs that same data.
As far as I understand, X communicates to
JTA on a UDP port
That port has to be 2237 as JTA doesn't
allow use of another port.
SpotCollector requires a spot source from
WSJTX. That spot is a UDP port in SpotCollector config.
If either of these apps communicate with X
in another way, I don't know what it is.
JTA and SpotCollector can't be configured
to use that same port in wsjtx.
I'll read your prior post in the morning in
addition to anything you might add in replying to this.
On Mon, Mar 16, 2020, 8:23
PM Bill Somerville < g4wjs@...>
wrote:
Hasan,
none of that makes any sense to me, and is mostly
incorrect. What are you trying to achieve?
Some corrections to your comments:
1) JTAlert is a UDP server listening on the port it
thinks WSJT-X (the UDP client) is sending to. It
discovers the port it should listen on by directly
reading the WSJT-X settings file. This is not
recommended as it makes it impossible for JTAlert to
run on a separate host from WSJT-X, but since JTAlert
works directly with the WSJT-X UI windows it probably
doesn't matter that it does that.
2) Local spot information is sent by JTAlert to
SpotCollector using a TCP/IP server built into
SpotCollector, that is nothing to do with UDP.
3) The UDP "rebroadcast" (WSJT-X UDP does not use
broadcast, it is a client server protocol) that can be
enabled in JTAlert is there to pass on WSJT-X UDP
traffic to applications that cannot share that data
directly JTAlert because JTAlert is unicast UDP server
which means it consumes WSJT-X traffic rather than
sharing it with other interested servers. This feed is
really only intended to pass on logged QSO messages.
It sounds like you are attempting to do far more than
that, which I don't recommend.
4) SpotCollector is able to act as a server for
WSJT-X UDP traffic. You should not be attempting to
"patch over" the limitations of JTAlert and
SpotCollector that mean neither is able to act as the
multicast UDP server preferred by the WSJT-X UDP
protocol.
5) Do not attempt to have two unicast UDP servers
interoperating with one or more WSJT-X clients for
anything more that QSO logging. That is not supported
and can never work as the server authors intended.
JTAlert has a fully supported mechanism for passing
logged QSO information from WSJT-X to DXKeeper. That
plus JTAert's facility to post local spots to
SpotCollector are all you should be using if you run
both JTAlert and DX Lab Suite. When doing that you
should (must IMHO) disable SpotCollector's direct
interoperation with WSJT-X, whether it be via port
2237 (or whatever port has been specified in WSJT-X
and SpotCollector), or via some unsupported lash up
trying to utilize JTAlert's UDP "rebroadcast"
facility.
73
Bill
G4WJS.
On 17/03/2020 01:04, Hasan Schiers N0AN wrote:
Bill,
JTA looks at X via UDP port 2237,
and is not configurable. So to get spotter info to
SpotCollector it needs to come in from a UDP port
that is not in use. We get that from JTA's ability
to rebroadcast an incoming 2237 UDP packet on 2337
for example.
So the flow is
X > JTA 2237
JTA Rebroadcast > 2337 >
SotCollector
This way JTA gets data directly from
X and JTA provides Rebroadcast data on 2337 for
SpotCollector
Hasan
On Mon, Mar 16,
2020, 7:49 PM Bill Somerville < g4wjs@...>
wrote:
Hi Hasan,
yes I would like WSJT-X and JTAlert
running. I don't know what you mean by having
JTAlert rebroadcast feeding SpotCollector.
AFAIK the way that JTAlert posts local spots
to SpotCollector is via a TCP/IP conversation,
that is not a rebroadcast in any sense of that
term.
73
Bill
G4WJS.
On 17/03/2020 00:44, Hasan Schiers N0AN
wrote:
Sure, first thing in the
morning. I assume you want me to have x
feeding JTA and JTA rebroadcast feeding
SpotCollector?
On Mon,
Mar 16, 2020, 7:40 PM Bill Somerville < g4wjs@...>
wrote:
Hi Hasan,
can you try a test with
WSJT-X/JTAlert for me please. Go to
"Settings->Reporting->UDP
Server" and uncheck "Accept UDP
requests". Please report if that
resolves the issue?
Note I am not proposing this as a
solution as it will disable important
features of the JTAlert WSJT-X
interoperation, but will be a useful
data point.
73
Bill
G4WJS.
On 16/03/2020 23:54, Hasan Schiers
N0AN wrote:
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 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.
FWIW,
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
Hasan
|
|
|
I'll review the info again. I have read it more than once, but I'm obviously missing something.
I may just shelve JTA and leave things as they are with X and SpotCollector until I can get the UDP repeater program operational. (a separate program that is being developed by another programmer for a different purpose, but could solve this issue)
On Mon, Mar 16, 2020, 8:55 PM Bill Somerville < g4wjs@...> wrote:
Hasan,
have you read this article:
which is about interoperation between
DX Lab Suite and WSJT-X. Note particularly the last section on
"Limitations" and also note JTAlert is not part of that as there
is duplication of functionality between DX Lab Suite's direct
interaction with WSJT-X compared with using JTAlert as an
intermediary between WSJT-X and DX Lab Suite.
You should also read this article:
which documents how to set up JTAlert
as an intermediary between WSJT-X and DX Lab Suite, taking account
of the limitations discussed above.
A key point you should understand is
that the two articles describe mutually exclusive functionality.
You seem to be trying to ignore that mutual exclusivity and build
a monster that tries to do more than is sensible, recommended, or
supported.
73
Bill
G4WJS.
On 17/03/2020 01:46, Hasan Schiers N0AN
wrote:
I see a point of confusion. Why does SpotCollector
config have an entry for X specifying a UDP port, if it already
gets those decodes from a TCP port?
Further, why does SpotCollector's Status light
for X not light up unless I enable wsjtx as a spot source in
SpotCollector config file. Also, unless I do enable x with a
UDP port in SpotCollector config, I see no spots in
SpotCollector from X.
May5you can see why I'm so confused.
Hasan
On Mon, Mar 16, 2020, 8:38 PM
Hasan Schiers N0AN via Groups.Io <hbasri.schiers6= gmail.com@groups.io>
wrote:
Ok, obviously I'm not on the same page with
all of this.
What I'm trying to do:
SpotCollector needs to be provided data from
WSJT X
JTA needs that same data.
As far as I understand, X communicates to
JTA on a UDP port
That port has to be 2237 as JTA doesn't
allow use of another port.
SpotCollector requires a spot source from
WSJTX. That spot is a UDP port in SpotCollector config.
If either of these apps communicate with X
in another way, I don't know what it is.
JTA and SpotCollector can't be configured
to use that same port in wsjtx.
I'll read your prior post in the morning in
addition to anything you might add in replying to this.
On Mon, Mar 16, 2020, 8:23
PM Bill Somerville < g4wjs@...>
wrote:
Hasan,
none of that makes any sense to me, and is mostly
incorrect. What are you trying to achieve?
Some corrections to your comments:
1) JTAlert is a UDP server listening on the port it
thinks WSJT-X (the UDP client) is sending to. It
discovers the port it should listen on by directly
reading the WSJT-X settings file. This is not
recommended as it makes it impossible for JTAlert to
run on a separate host from WSJT-X, but since JTAlert
works directly with the WSJT-X UI windows it probably
doesn't matter that it does that.
2) Local spot information is sent by JTAlert to
SpotCollector using a TCP/IP server built into
SpotCollector, that is nothing to do with UDP.
3) The UDP "rebroadcast" (WSJT-X UDP does not use
broadcast, it is a client server protocol) that can be
enabled in JTAlert is there to pass on WSJT-X UDP
traffic to applications that cannot share that data
directly JTAlert because JTAlert is unicast UDP server
which means it consumes WSJT-X traffic rather than
sharing it with other interested servers. This feed is
really only intended to pass on logged QSO messages.
It sounds like you are attempting to do far more than
that, which I don't recommend.
4) SpotCollector is able to act as a server for
WSJT-X UDP traffic. You should not be attempting to
"patch over" the limitations of JTAlert and
SpotCollector that mean neither is able to act as the
multicast UDP server preferred by the WSJT-X UDP
protocol.
5) Do not attempt to have two unicast UDP servers
interoperating with one or more WSJT-X clients for
anything more that QSO logging. That is not supported
and can never work as the server authors intended.
JTAlert has a fully supported mechanism for passing
logged QSO information from WSJT-X to DXKeeper. That
plus JTAert's facility to post local spots to
SpotCollector are all you should be using if you run
both JTAlert and DX Lab Suite. When doing that you
should (must IMHO) disable SpotCollector's direct
interoperation with WSJT-X, whether it be via port
2237 (or whatever port has been specified in WSJT-X
and SpotCollector), or via some unsupported lash up
trying to utilize JTAlert's UDP "rebroadcast"
facility.
73
Bill
G4WJS.
On 17/03/2020 01:04, Hasan Schiers N0AN wrote:
Bill,
JTA looks at X via UDP port 2237,
and is not configurable. So to get spotter info to
SpotCollector it needs to come in from a UDP port
that is not in use. We get that from JTA's ability
to rebroadcast an incoming 2237 UDP packet on 2337
for example.
So the flow is
X > JTA 2237
JTA Rebroadcast > 2337 >
SotCollector
This way JTA gets data directly from
X and JTA provides Rebroadcast data on 2337 for
SpotCollector
Hasan
On Mon, Mar 16,
2020, 7:49 PM Bill Somerville < g4wjs@...>
wrote:
Hi Hasan,
yes I would like WSJT-X and JTAlert
running. I don't know what you mean by having
JTAlert rebroadcast feeding SpotCollector.
AFAIK the way that JTAlert posts local spots
to SpotCollector is via a TCP/IP conversation,
that is not a rebroadcast in any sense of that
term.
73
Bill
G4WJS.
On 17/03/2020 00:44, Hasan Schiers N0AN
wrote:
Sure, first thing in the
morning. I assume you want me to have x
feeding JTA and JTA rebroadcast feeding
SpotCollector?
On Mon,
Mar 16, 2020, 7:40 PM Bill Somerville < g4wjs@...>
wrote:
Hi Hasan,
can you try a test with
WSJT-X/JTAlert for me please. Go to
"Settings->Reporting->UDP
Server" and uncheck "Accept UDP
requests". Please report if that
resolves the issue?
Note I am not proposing this as a
solution as it will disable important
features of the JTAlert WSJT-X
interoperation, but will be a useful
data point.
73
Bill
G4WJS.
On 16/03/2020 23:54, Hasan Schiers
N0AN wrote:
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 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.
FWIW,
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
Hasan
|
|
|
Bill Somerville
Hasan,
unless the program being developed is
very smart it will not do what you seem to be aiming for. To work
correctly it would have to handle traffic from WSJT-X to two
different servers, and crtically reply traffic back to WSJT-X.
That last part is not straightforward as it would have to spoof
the IP address and port numbers of the servers when reply traffic
is routed to WSJT-X. Without that the protocol will not work.
WSJT-X will not be able to differentiate incoming traffic unless
it appears to be coming from the server it sent the original
messages to. Spoofing IP packet headers is not in the realm of
average system programmers and is very likely to be treated by AV
software and firewalls as malware.
73
Bill
G4WJS.
On 17/03/2020 02:13, Hasan Schiers N0AN
wrote:
toggle quoted message
Show quoted text
I'll review the info again. I have read it more
than once, but I'm obviously missing something.
I may just shelve JTA and leave things as they
are with X and SpotCollector until I can get the UDP repeater
program operational.
(a separate program that is being developed by
another programmer for a different purpose, but could solve
this issue)
On Mon, Mar 16, 2020, 8:55 PM
Bill Somerville < g4wjs@...> wrote:
Hasan,
have you read this article:
which is about interoperation between DX Lab Suite and
WSJT-X. Note particularly the last section on
"Limitations" and also note JTAlert is not part of that as
there is duplication of functionality between DX Lab
Suite's direct interaction with WSJT-X compared with using
JTAlert as an intermediary between WSJT-X and DX Lab
Suite.
You should also read this article:
which documents how to set up JTAlert as an
intermediary between WSJT-X and DX Lab Suite, taking
account of the limitations discussed above.
A key point you should understand is that the two
articles describe mutually exclusive functionality. You
seem to be trying to ignore that mutual exclusivity and
build a monster that tries to do more than is sensible,
recommended, or supported.
73
Bill
G4WJS.
On 17/03/2020 01:46, Hasan Schiers N0AN wrote:
I see a point of confusion. Why does
SpotCollector config have an entry for X specifying a
UDP port, if it already gets those decodes from a TCP
port?
Further, why does SpotCollector's Status
light for X not light up unless I enable wsjtx as a
spot source in SpotCollector config file. Also,
unless I do enable x with a UDP port in SpotCollector
config, I see no spots in SpotCollector from X.
May5you can see why I'm so confused.
Hasan
On Mon, Mar 16, 2020,
8:38 PM Hasan Schiers N0AN via Groups.Io
<hbasri.schiers6= gmail.com@groups.io>
wrote:
Ok, obviously I'm not on the same page
with all of this.
What I'm trying to do:
SpotCollector needs to be provided
data from WSJT X
JTA needs that same data.
As far as I understand, X
communicates to JTA on a UDP port
That port has to be 2237 as JTA
doesn't allow use of another port.
SpotCollector requires a spot source
from WSJTX. That spot is a UDP port in
SpotCollector config.
If either of these apps communicate
with X in another way, I don't know what it is.
JTA and SpotCollector can't be
configured to use that same port in wsjtx.
I'll read your prior post in the
morning in addition to anything you might add in
replying to this.
On Mon, Mar 16,
2020, 8:23 PM Bill Somerville < g4wjs@...>
wrote:
Hasan,
none of that makes any sense to me, and is
mostly incorrect. What are you trying to
achieve?
Some corrections to your comments:
1) JTAlert is a UDP server listening on the
port it thinks WSJT-X (the UDP client) is
sending to. It discovers the port it should
listen on by directly reading the WSJT-X
settings file. This is not recommended as it
makes it impossible for JTAlert to run on a
separate host from WSJT-X, but since JTAlert
works directly with the WSJT-X UI windows it
probably doesn't matter that it does that.
2) Local spot information is sent by
JTAlert to SpotCollector using a TCP/IP server
built into SpotCollector, that is nothing to
do with UDP.
3) The UDP "rebroadcast" (WSJT-X UDP does
not use broadcast, it is a client server
protocol) that can be enabled in JTAlert is
there to pass on WSJT-X UDP traffic to
applications that cannot share that data
directly JTAlert because JTAlert is unicast
UDP server which means it consumes WSJT-X
traffic rather than sharing it with other
interested servers. This feed is really only
intended to pass on logged QSO messages. It
sounds like you are attempting to do far more
than that, which I don't recommend.
4) SpotCollector is able to act as a server
for WSJT-X UDP traffic. You should not be
attempting to "patch over" the limitations of
JTAlert and SpotCollector that mean neither is
able to act as the multicast UDP server
preferred by the WSJT-X UDP protocol.
5) Do not attempt to have two unicast UDP
servers interoperating with one or more WSJT-X
clients for anything more that QSO logging.
That is not supported and can never work as
the server authors intended.
JTAlert has a fully supported mechanism for
passing logged QSO information from WSJT-X to
DXKeeper. That plus JTAert's facility to post
local spots to SpotCollector are all you
should be using if you run both JTAlert and DX
Lab Suite. When doing that you should (must
IMHO) disable SpotCollector's direct
interoperation with WSJT-X, whether it be via
port 2237 (or whatever port has been specified
in WSJT-X and SpotCollector), or via some
unsupported lash up trying to utilize
JTAlert's UDP "rebroadcast" facility.
73
Bill
G4WJS.
On 17/03/2020 01:04, Hasan Schiers N0AN
wrote:
Bill,
JTA looks at X via UDP port
2237, and is not configurable. So to get
spotter info to SpotCollector it needs to
come in from a UDP port that is not in
use. We get that from JTA's ability to
rebroadcast an incoming 2237 UDP packet on
2337 for example.
So the flow is
X > JTA 2237
JTA Rebroadcast > 2337
> SotCollector
This way JTA gets data
directly from X and JTA provides
Rebroadcast data on 2337 for
SpotCollector
Hasan
On Mon,
Mar 16, 2020, 7:49 PM Bill Somerville < g4wjs@...>
wrote:
Hi Hasan,
yes I would like WSJT-X and JTAlert
running. I don't know what you mean by
having JTAlert rebroadcast feeding
SpotCollector. AFAIK the way that
JTAlert posts local spots to
SpotCollector is via a TCP/IP
conversation, that is not a
rebroadcast in any sense of that term.
73
Bill
G4WJS.
On 17/03/2020 00:44, Hasan Schiers
N0AN wrote:
Sure, first thing in
the morning. I assume you want me to
have x feeding JTA and JTA
rebroadcast feeding SpotCollector?
On
Mon, Mar 16, 2020, 7:40 PM Bill
Somerville < g4wjs@...>
wrote:
Hi Hasan,
can you try a test with
WSJT-X/JTAlert for me please.
Go to
"Settings->Reporting->UDP
Server" and uncheck "Accept
UDP requests". Please report
if that resolves the issue?
Note I am not proposing
this as a solution as it will
disable important features of
the JTAlert WSJT-X
interoperation, but will be a
useful data point.
73
Bill
G4WJS.
On 16/03/2020 23:54, Hasan
Schiers N0AN wrote:
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 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.
FWIW,
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
Hasan
|
|
|
I've noticed this for a long time. Can tell when the other
station is using WSJT-X same thing
Rick W3BI
On 3/16/2020 6:26 PM, 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.
--
Only losers need rally caps.
|
|
|
Bill, I'm only looking for the decoded calls from X to show up in JTA. I don't need jta to send anything back to x.
I have it writing it's own log so it keeps track of alerts and worked b4. It is not integrated with dxkeeper logging.
Jta is being used in my situation as nothing more than a monitor.
I want it to listen to x decodes and display them. I don't want or need jta to let me click on a call sign and control x, or pass any info to X at all.
That was the goal. Maybe that can't be done. 73, Hasan
I've noticed this for a long time. Can tell when the other
station is using WSJT-X same thing
Rick W3BI
On 3/16/2020 6:26 PM, 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.
--
Only losers need rally caps.
|
|
|
I'm one of these with problems. But I'm don't use JTAlert, but DXlab with Spotcollecter and DXKeeper. The Spotcollector also communicate with WSJT, like JTAlert.
I think this problem is caused by exhausted Windows resources. If I move a window, decodes are often skipped. Sometimes Windows is doing something cpu intensive in the background (look at the processlist), and decodes are skipped. Or some other software is updating in background, like the antivirus program.
I have given up and accept some missed decodes. Maybe if I had a faster PC, the problem would be solved. I don't know.
|
|
|
Hi Markku and all
I am among those who pointed out to this issue few months back. And i also got the resources thing as an explanation, however, i am using an i7 cpu with 32gb ram dedicated, and the pc is exclusively used for dxlab and wsjtx jta. Also ssdhd 1t. I guess it is something in the wsjtx anf jta handshake.
Regards from beirut Please all stay safe.stay at home.
Ghassan Od5ya
Sent from Samsung tablet.
-------- Original message -------- From: Markku SM5FLM <marsip@...> Date: 17/03/2020 09:51 (GMT+02:00) To: WSJTX@groups.io Subject: Re: [WSJTX] Seeing a Lot of Skipping Decodes Every Other Sequence FT8
[Edited Message Follows]
I'm one of these with problems. But I'm don't use JTAlert, but DXlab with Spotcollecter and DXKeeper. The Spotcollector also communicate with WSJT, like JTAlert. I think this problem is caused by exhausted Windows resources. If I move a window, decodes are often skipped. Sometimes Windows is doing something cpu intensive in the background (look at the processlist), and decodes are skipped. Or some other software is updating in background, like the antivirus program. I have given up and accept some missed decodes. Maybe if I had a faster PC, the problem would be solved. I don't know.
|
|
|
Bill, I have read again the two sections you mentioned and I don't think I can get where I want to go.
While I can have the repeater program pick off a mirror of 2237 UDP, some additional work would be required to prevent JTA from trying to talk back to WSJT-X (and messing things up)
I want JTA to be a passive monitor and do nothing else, except to write to its own adif log the completed qsos. (thus keeping it in sync with DXKeeper's WSJT-X qsos)
It looks to me like this situation is one of "you can't get there from here". The only apparent solution is to abandon JTA, unless and until the programmer's other project turns up something that allows us to trick JTA into becoming a passive "display only" program that does not have to sit between WSJT-X and SpotCollector.
Thanks for your help. In the mean time I'll just run X > SpotCollector. No issues with X not decoding every other seq in that config.
73, N0AN
Let me know if you want me to try some other configuration in WSJT-X like we talked about yesterday. I just want to make sure if I'm going to run a test for you, that I'm properly configured ...which is what started this whole series of back and forths last night .
On Mon, Mar 16, 2020 at 9:20 PM Bill Somerville < g4wjs@...> wrote:
Hasan,
unless the program being developed is
very smart it will not do what you seem to be aiming for. To work
correctly it would have to handle traffic from WSJT-X to two
different servers, and crtically reply traffic back to WSJT-X.
That last part is not straightforward as it would have to spoof
the IP address and port numbers of the servers when reply traffic
is routed to WSJT-X. Without that the protocol will not work.
WSJT-X will not be able to differentiate incoming traffic unless
it appears to be coming from the server it sent the original
messages to. Spoofing IP packet headers is not in the realm of
average system programmers and is very likely to be treated by AV
software and firewalls as malware.
73
Bill
G4WJS.
On 17/03/2020 02:13, Hasan Schiers N0AN
wrote:
I'll review the info again. I have read it more
than once, but I'm obviously missing something.
I may just shelve JTA and leave things as they
are with X and SpotCollector until I can get the UDP repeater
program operational.
(a separate program that is being developed by
another programmer for a different purpose, but could solve
this issue)
On Mon, Mar 16, 2020, 8:55 PM
Bill Somerville < g4wjs@...> wrote:
Hasan,
have you read this article:
which is about interoperation between DX Lab Suite and
WSJT-X. Note particularly the last section on
"Limitations" and also note JTAlert is not part of that as
there is duplication of functionality between DX Lab
Suite's direct interaction with WSJT-X compared with using
JTAlert as an intermediary between WSJT-X and DX Lab
Suite.
You should also read this article:
which documents how to set up JTAlert as an
intermediary between WSJT-X and DX Lab Suite, taking
account of the limitations discussed above.
A key point you should understand is that the two
articles describe mutually exclusive functionality. You
seem to be trying to ignore that mutual exclusivity and
build a monster that tries to do more than is sensible,
recommended, or supported.
73
Bill
G4WJS.
On 17/03/2020 01:46, Hasan Schiers N0AN wrote:
I see a point of confusion. Why does
SpotCollector config have an entry for X specifying a
UDP port, if it already gets those decodes from a TCP
port?
Further, why does SpotCollector's Status
light for X not light up unless I enable wsjtx as a
spot source in SpotCollector config file. Also,
unless I do enable x with a UDP port in SpotCollector
config, I see no spots in SpotCollector from X.
May5you can see why I'm so confused.
Hasan
On Mon, Mar 16, 2020,
8:38 PM Hasan Schiers N0AN via Groups.Io
<hbasri.schiers6= gmail.com@groups.io>
wrote:
Ok, obviously I'm not on the same page
with all of this.
What I'm trying to do:
SpotCollector needs to be provided
data from WSJT X
JTA needs that same data.
As far as I understand, X
communicates to JTA on a UDP port
That port has to be 2237 as JTA
doesn't allow use of another port.
SpotCollector requires a spot source
from WSJTX. That spot is a UDP port in
SpotCollector config.
If either of these apps communicate
with X in another way, I don't know what it is.
JTA and SpotCollector can't be
configured to use that same port in wsjtx.
I'll read your prior post in the
morning in addition to anything you might add in
replying to this.
On Mon, Mar 16,
2020, 8:23 PM Bill Somerville < g4wjs@...>
wrote:
Hasan,
none of that makes any sense to me, and is
mostly incorrect. What are you trying to
achieve?
Some corrections to your comments:
1) JTAlert is a UDP server listening on the
port it thinks WSJT-X (the UDP client) is
sending to. It discovers the port it should
listen on by directly reading the WSJT-X
settings file. This is not recommended as it
makes it impossible for JTAlert to run on a
separate host from WSJT-X, but since JTAlert
works directly with the WSJT-X UI windows it
probably doesn't matter that it does that.
2) Local spot information is sent by
JTAlert to SpotCollector using a TCP/IP server
built into SpotCollector, that is nothing to
do with UDP.
3) The UDP "rebroadcast" (WSJT-X UDP does
not use broadcast, it is a client server
protocol) that can be enabled in JTAlert is
there to pass on WSJT-X UDP traffic to
applications that cannot share that data
directly JTAlert because JTAlert is unicast
UDP server which means it consumes WSJT-X
traffic rather than sharing it with other
interested servers. This feed is really only
intended to pass on logged QSO messages. It
sounds like you are attempting to do far more
than that, which I don't recommend.
4) SpotCollector is able to act as a server
for WSJT-X UDP traffic. You should not be
attempting to "patch over" the limitations of
JTAlert and SpotCollector that mean neither is
able to act as the multicast UDP server
preferred by the WSJT-X UDP protocol.
5) Do not attempt to have two unicast UDP
servers interoperating with one or more WSJT-X
clients for anything more that QSO logging.
That is not supported and can never work as
the server authors intended.
JTAlert has a fully supported mechanism for
passing logged QSO information from WSJT-X to
DXKeeper. That plus JTAert's facility to post
local spots to SpotCollector are all you
should be using if you run both JTAlert and DX
Lab Suite. When doing that you should (must
IMHO) disable SpotCollector's direct
interoperation with WSJT-X, whether it be via
port 2237 (or whatever port has been specified
in WSJT-X and SpotCollector), or via some
unsupported lash up trying to utilize
JTAlert's UDP "rebroadcast" facility.
73
Bill
G4WJS.
On 17/03/2020 01:04, Hasan Schiers N0AN
wrote:
Bill,
JTA looks at X via UDP port
2237, and is not configurable. So to get
spotter info to SpotCollector it needs to
come in from a UDP port that is not in
use. We get that from JTA's ability to
rebroadcast an incoming 2237 UDP packet on
2337 for example.
So the flow is
X > JTA 2237
JTA Rebroadcast > 2337
> SotCollector
This way JTA gets data
directly from X and JTA provides
Rebroadcast data on 2337 for
SpotCollector
Hasan
On Mon,
Mar 16, 2020, 7:49 PM Bill Somerville < g4wjs@...>
wrote:
Hi Hasan,
yes I would like WSJT-X and JTAlert
running. I don't know what you mean by
having JTAlert rebroadcast feeding
SpotCollector. AFAIK the way that
JTAlert posts local spots to
SpotCollector is via a TCP/IP
conversation, that is not a
rebroadcast in any sense of that term.
73
Bill
G4WJS.
On 17/03/2020 00:44, Hasan Schiers
N0AN wrote:
Sure, first thing in
the morning. I assume you want me to
have x feeding JTA and JTA
rebroadcast feeding SpotCollector?
On
Mon, Mar 16, 2020, 7:40 PM Bill
Somerville < g4wjs@...>
wrote:
Hi Hasan,
can you try a test with
WSJT-X/JTAlert for me please.
Go to
"Settings->Reporting->UDP
Server" and uncheck "Accept
UDP requests". Please report
if that resolves the issue?
Note I am not proposing
this as a solution as it will
disable important features of
the JTAlert WSJT-X
interoperation, but will be a
useful data point.
73
Bill
G4WJS.
On 16/03/2020 23:54, Hasan
Schiers N0AN wrote:
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 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.
FWIW,
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
Hasan
|
|
|
