Date   

locked Re: PTT issue

OGANE YOSHIAKI
 
Edited

Thank you, Bill, for your comments and advise. It seems I have to live with it. 

Yes,  I am using Commander for rig control, which works just great.


With CAT selected as PTT method, keying my K3 is not steady. Sometimes K3 is keyed immediately when clicking Tune. Other times taking long time or even not. It might be because I am controlling K3 remotely with Remote Rig RRC 1258 setup. For some reasons, VOX does not work properly either. Currently I am PTTing manually in accordance with the TX of WSJTX. Really need some methods to key K3 steadily. 


JL1CNY/ND1Y Sam


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

Hasan Schiers N0AN
 

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


On Mon, Mar 16, 2020, 9:27 PM Rick <polarmail@...> wrote:

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.

Hasan


    
--


Only losers need rally caps.


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

Rick
 

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.

Hasan


    
--


Only losers need rally caps.


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

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:

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)


Hasan

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. 



Hasan

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?
73, N0AN 

Hasan

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

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

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

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

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

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

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

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

UDP > JTAlert
JTAlert Rebroadcast UDP > DXLab SpotCollector


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

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

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

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

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

Hasan


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




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

Hasan Schiers N0AN
 

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)


Hasan

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. 



Hasan

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?
73, N0AN 

Hasan

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

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

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

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

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

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

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

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

UDP > JTAlert
JTAlert Rebroadcast UDP > DXLab SpotCollector


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

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

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

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

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

Hasan


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




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

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:

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. 



Hasan

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?
73, N0AN 

Hasan

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

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

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

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

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

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

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

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

UDP > JTAlert
JTAlert Rebroadcast UDP > DXLab SpotCollector


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

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

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

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

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

Hasan


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



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

Hasan Schiers N0AN
 

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. 



Hasan

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?
73, N0AN 

Hasan

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

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

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

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

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

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

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

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

UDP > JTAlert
JTAlert Rebroadcast UDP > DXLab SpotCollector


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

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

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

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

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

Hasan


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





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

Hasan Schiers N0AN
 

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. 



Hasan


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?
73, N0AN 

Hasan

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

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

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

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

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

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

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

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

UDP > JTAlert
JTAlert Rebroadcast UDP > DXLab SpotCollector


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

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

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

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

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

Hasan


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




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

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:

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?
73, N0AN 

Hasan

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

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

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

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

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

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

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

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

UDP > JTAlert
JTAlert Rebroadcast UDP > DXLab SpotCollector


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

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

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

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

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

Hasan


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



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

Hasan Schiers N0AN
 

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?
73, N0AN 

Hasan

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

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

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

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

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

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

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

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

UDP > JTAlert
JTAlert Rebroadcast UDP > DXLab SpotCollector


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

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

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

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

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

Hasan


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




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

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:

Sure, first thing in the morning. I assume you want me to have x feeding JTA and JTA rebroadcast feeding SpotCollector?
73, N0AN 

Hasan

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

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

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

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

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

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

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

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

UDP > JTAlert
JTAlert Rebroadcast UDP > DXLab SpotCollector


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

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

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

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

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

Hasan


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



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

Hasan Schiers N0AN
 

Sure, first thing in the morning. I assume you want me to have x feeding JTA and JTA rebroadcast feeding SpotCollector?
73, N0AN 

Hasan


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

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

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

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

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

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

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

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

UDP > JTAlert
JTAlert Rebroadcast UDP > DXLab SpotCollector


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

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

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

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

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

Hasan


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




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

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:

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

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

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

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

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

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

73, N0AN 

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

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

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

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

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

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

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

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

UDP > JTAlert
JTAlert Rebroadcast UDP > DXLab SpotCollector


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

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

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

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

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

Hasan


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



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

Hasan Schiers N0AN
 

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.

73, N0AN
Hasan


On Mon, Mar 16, 2020, 7:01 PM Al Groff via Groups.Io <al.k0vm=yahoo.com@groups.io> wrote:
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.

Hasan


    



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

Al Groff
 

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.

Hasan


    


locked Re: WSJT not driving 7610

Bill Somerville
 

On 16/03/2020 23:43, eam1212003 via Groups.Io wrote:
So I just upgraded to 1.20 from 1.06. No prob with radio in cw or ssb. WSJT gives me no power out. CAT is fine, audio is fine, codec...in fact all my settings in WSJT are as they were before upgrade...any suggestions what to look at...

Tnx Eli, N6PF
Hi Eli,

what did you upgrade? I don't recognize those version numbers.

73
Bill
G4WJS.


locked Re: WSJT not driving 7610

Lawrence (VA3IQ)
 

Menu->Set->Connectors->USB AF/IF Output->Output Select AF and AF Output Level 30%

Hit the USB key on the transmit side of the touch screen.
Hit the Data key on the mode select that pops up.

Should toggle to USB-D2.

Hope this helps.

Lawrence



On Mon, Mar 16, 2020 at 7:49 PM eam1212003 via Groups.Io <eam1212003=yahoo.com@groups.io> wrote:
Indeed I am in “regular” usb...how do I get to D-2.  Sorry, newbie here


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

Hasan Schiers N0AN
 

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

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

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

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

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

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

73, N0AN 

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

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

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

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

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

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

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

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

UDP > JTAlert
JTAlert Rebroadcast UDP > DXLab SpotCollector


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

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

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

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

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

Hasan


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


locked Re: CAT issue with FTDX1200 / 3000 #Cat_RigControl

Jim Brown
 

On 3/16/2020 7:47 AM, Kai-KE4PT wrote:
I've been running the Yaesu FT-817 on SSB to unsolicited rave reviews on the audio quality. Also no complaints on CW, RTTY (via sound card),
The problem with these cheap rigs aren't heard by the stations you're working, but by those on adjacent frequencies. I suggest that you look at it on a spectrum display with waterfall while TX SSB -- what I've repeatedly seen are pronounced widening of the signal on voice peaks on both sides of the 2.8 kHz bandwidth, and if the amplitude display is set for averaging or to accumulate peaks, I often see that the splatter is less than 20 dB below the 2.8 kHz envelope.

Same for the clicks. Here are reports I put together several years ago. The first is all ARRL Lab data which they sent me electronically, the second is all my own work.

http://k9yc.com/TXNoise.pdf

http://k9yc.com/P3_Spectrum_Measurements.pdf

I should put together another report with plots of clean and dirty rigs. A group of west coast contesters hangs out on LSB just above the FT8 watering hole on 160M. Most of the guys have a nice clean envelope, while a few splatter like mad, down into the top of the FT8 bandpass!

A great place to see this is on 40M.

W4TV, a retired broadcast engineer, looked into the this and chased down the reasons.

73, Jim K9YC


locked Re: WSJT not driving 7610

eam1212003
 

Found D2 but still no power out...power slider all the way up...