Topics

FT-8 lag?


Richard Perry
 

Does anyone know what causes/how to fix a lag with Commander in FT-8 mode? Right now, I've got about a 2 - 2.5 second lag from the beginning of the cycle to the start of my FT-8 transmission. It stops on time (@13 sec), my time is right (exactly on nist time standard), I set it up via the wiki/instructions (here) and it doesn't happen when controlling my rig "natively". The only other thing running at the same time is JTAlert (in both cases.) Most modes I wouldn't care, but in FT-8 (or worse yet, FT-4) that's not gonna work.
 
Any thoughts?
 
Regards/73 de AJ0V/Richard


Dave AA6YQ
 

+ AA6YQ comments below

Does anyone know what causes/how to fix a lag with Commander in FT-8 mode? Right now, I've got about a 2 - 2.5 second lag from the beginning of the cycle to the start of my FT-8 transmission. It stops on time (@13 sec), my time is right (exactly on nist time standard), I set it up via the wiki/instructions (here) <https://www.dxlabsuite.com/dxlabwiki/GettingStartedwithK1JTModesWithJTAlert> and it doesn't happen when controlling my rig "natively". The only other thing running at the same time is JTAlert (in both cases.) Most modes I wouldn't care, but in FT-8 (or worse yet, FT-4) that's not gonna work.

+ What make and model transceiver are you using, Richard?

+ With your transceiver on a clear frequency, click the TX button in the PTT panel to the right of VFO panel on Commander's Main window, and then click the RX button; how long does it take for your transceiver to switch from RX to TX, and then from TX to RX?

+ Note: if you have Commander's Main window configured to display its memories, click the "Filters & Devices" button beneath the memories to make the PTT panel visible.

73,

Dave, AA6YQ


W7HPW Radio
 

I have noticed this as well, but I don’t think it has anything to do with commander, I don’t have WSJT-X controlling the rig PTT through commander,  done direct through  a MKIII. PTT closes right on time but the audio is delayed. A restart of WSJT-X fixes the delay.

 

So I have concluded that that the delay is in WSJT-X or in the way it handles the sound interface?

 

Mark

W7HPW

 

 

Real Radios Glow in the Dark

 

From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Richard Perry
Sent: Tuesday, April 21, 2020 3:43 PM
To: DXLab@groups.io
Subject: [DXLab] FT-8 lag?

 

Does anyone know what causes/how to fix a lag with Commander in FT-8 mode? Right now, I've got about a 2 - 2.5 second lag from the beginning of the cycle to the start of my FT-8 transmission. It stops on time (@13 sec), my time is right (exactly on nist time standard), I set it up via the wiki/instructions (here) and it doesn't happen when controlling my rig "natively". The only other thing running at the same time is JTAlert (in both cases.) Most modes I wouldn't care, but in FT-8 (or worse yet, FT-4) that's not gonna work.

 

Any thoughts?

 

Regards/73 de AJ0V/Richard


ve3ki
 

If WSJT-X's "Split Operation" setting is "Rig", try changing it to "Fake It". With my K3 and using Commander as the rig interface from WSJT-X, with the "Rig" setting I see similar delays. In my case, "Fake It" switches to transmit much more quickly than "Rig". This may be radio-dependent; if you are using "Fake It" and it is slow, try "Rig" to see if it is any better.

73,
Rich VE3KI


On Tue, Apr 21, 2020 at 06:07 PM, Richard Perry wrote:
Does anyone know what causes/how to fix a lag with Commander in FT-8 mode? Right now, I've got about a 2 - 2.5 second lag from the beginning of the cycle to the start of my FT-8 transmission. It stops on time (@13 sec), my time is right (exactly on nist time standard), I set it up via the wiki/instructions (here) and it doesn't happen when controlling my rig "natively". The only other thing running at the same time is JTAlert (in both cases.) Most modes I wouldn't care, but in FT-8 (or worse yet, FT-4) that's not gonna work.
 
Any thoughts?
 
Regards/73 de AJ0V/Richard


Jim AF5FH
 

My experience is the same as Rich. Using WSJT-X, an Icom 7200, and Commander, "Fake It" switches to transmit much more quickly than "Rig". The "Fake It" setting uses the same VFO for both transmit and receive and changes the frequency, while the "Rig" setting uses different VFO set to different frequency.

73,
Jim
AF5FH


Richard Perry
 


+ What make and model transceiver are you using, Richard?

Sorry, should have started with that. Elecraft K3.

+ With your transceiver on a clear frequency, click the TX button in the PTT panel to the right of VFO panel on Commander's Main window, and then click the RX button; how long does it take for your transceiver to switch from RX to TX, and then from TX to RX?

Maybe a touch of lag noted there, but if there is, it's short enough I couldn't measure it. Probably the time it takes for the T/R relay switchover is all.

Given the comment above about a software restart working on a K3, I went back and rebooted everything, then confirmed the problem. With Commander running, I'm still seeing about a 2 second lag from the "zero" point of the cycle to switching into TX mode, and an additional second (that I think is intentional in the software) before the audio tone starts. 

I also tried using the PTT test button within WSJT-X. I do see some lag there, but the same as the PTT test in Commander....a bit, but too fast to measure.

Because you got me curious, I pulled out my older IC-7300 and tried that. No lag noted there, in any configuration ("native" control or via Commander). This whateveritis appears to be K3 only.

+ Note: if you have Commander's Main window configured to display its memories, click the "Filters & Devices" button beneath the memories to make the PTT panel visible.  

No worries. About the only other software config thing I could think of is/was JTAlert, so I tried the same thing with JTAlert both running and not....no difference noted.

Hope that helps!

--
Regards -
 
Richard T Perry


g4wjs
 

On 22/04/2020 16:49, Richard Perry wrote:
+ What make and model transceiver are you using, Richard?

Sorry, should have started with that. Elecraft K3.

Hi Richard,

there is an ongoing issue with the Elecraft K3 series when controlled by WSJT-X via Commander. You should be able to mitigate most of the delay by choosing the WSJT-X option "Settings->Radio->Mode->None". You will then have to remember to set the rig to DATA A mode manually, for both VFOs if you are using "Settings->Radio->Split Operating->Rig".

73
Bill
G4WJS.


--
73

Bill

G4WJS.


Dave AA6YQ
 

+ AA6YQ comments below

there is an ongoing issue with the Elecraft K3 series when controlled by WSJT-X via Commander. You should be able to mitigate most of the delay by choosing the WSJT-X option "Settings->Radio->Mode->None". You will then have to remember to set the rig to DATA A mode manually, for both VFOs if you are using "Settings->Radio->Split Operating->Rig".

+ I hope you will address this in the next version of WSJT-X, Bill. I'm ready to help if needed.

73,

Dave, AA6YQ


Buck
 

I control my K3S through Dx Lab. In the WSJT Settings Tab, I have selected
Rig DX Lab Suite Commander
PTT Method = CAT
Mode = None
Split = Fake it

I have no lag.

k4ia, Buck
K3s# 11497
Honor Roll 8B DXCC
EasyWayHamBooks.com

On 4/22/2020 2:23 PM, Dave AA6YQ wrote:
+ AA6YQ comments below
there is an ongoing issue with the Elecraft K3 series when controlled by WSJT-X via Commander. You should be able to mitigate most of the delay by choosing the WSJT-X option "Settings->Radio->Mode->None". You will then have to remember to set the rig to DATA A mode manually, for both VFOs if you are using "Settings->Radio->Split Operating->Rig".
+ I hope you will address this in the next version of WSJT-X, Bill. I'm ready to help if needed.
73,
Dave, AA6YQ


Tapio OH3HN
 

I can see the same behavior as Mark W7HPW. My WSJT-X is keying the rig directly. PTT closes always right on time. Audio is NOT delayed if WSJT-X is started recently, but after half an hour or so the audio starts to be delayed. A restart of WSJT-X fixes the delay, so I'm not blaming malware protection etc. I'm also not able to test this in "safe mode with networking" because my sound interface (Microham MKII) is not working in that mode.

The audio can be delayed several seconds and I can also see the decodes lagging when the audio starts lagging more and more over time.

I'm not 100% sure, but I think this started at the time when I reconfigured my setup to use direct interoperation between DXLab and WSJT-X (ie. without JTAlert). This means that WSJT-X is sending spots to Spotcollector and Spotcollector is sending coloring requests to WSJT-X. Could this interface cause the lagging (in my case)?

I'll do some more testing, eg. try to disable the "Accept UDP requests" setting in WSJT-X and see what happens.


73 de Tapio at station OH3HN


Dave AA6YQ
 

+ AA6YQ comments below

On Wed, Apr 22, 2020 at 10:58 PM, Tapio OH3HN wrote:

I'm not 100% sure, but I think this started at the time when I reconfigured my setup to use direct interoperation between DXLab and WSJT-X (ie. without JTAlert). This means that WSJT-X is sending spots to Spotcollector and Spotcollector is sending coloring requests to WSJT-X. Could this interface cause the lagging (in my case)?

+ No. WSJT-X uses Commander for transceiver control in the same way, whether JT-Alert is in use or not.

+ The problem is caused by timing requirements imposed by the K3 family combined with a conservative approach taken by WSJT-X in the directives it sends to Commander.

    73,

            Dave, AA6YQ


Tapio OH3HN
 
Edited

+ No. WSJT-X uses Commander for transceiver control in the same way, whether JT-Alert is in use or not.

+ The problem is caused by timing requirements imposed by the K3 family combined with a conservative approach taken by WSJT-X in the directives it sends to Commander.

    73,

            Dave, AA6YQ


I'm sorry I didn't specify what rig I'm using. I'm using a TS-2000. With "My WSJT-X is keying the rig directly" I meant that Commander is not in the loop.

My problem is probably not caused by DXLab unless Spotcollector is somehow overly bombarding WSJT-X with the coloring requests :-)


73 de Tapio at station OH3HN


g4wjs
 

On 23/04/2020 06:58, Tapio OH3HN wrote:
I'll do some more testing, eg. try to disable the "Accept UDP requests" setting in WSJT-X and see what happens.


73 de Tapio at station OH3HN
Hi Tapio,

please report back on whether disabling incoming UDP requests to WSJT-X does improve the issues you have with WSJT-X performance please.



--
73

Bill

G4WJS.


Tapio OH3HN
 

Thanks Bill, I'll test that during the weekend and report back.

73 de Tapio at station OH3HN


Matt Foster
 

I'm having the same issue with my IC-7300 using Split mode in WSJT-X. Also getting about a 2-3s delay switching to transmit. I'm using the "Fake It" option in WSJT-X for now.

I can provide a debug log from Commander, if that would help.

73, Matt, N0EYE


Dave AA6YQ
 

+ AA6YQ comments below

I'm having the same issue with my IC-7300 using Split mode in WSJT-X. Also getting about a 2-3s delay switching to transmit. I'm using the "Fake It" option in WSJT-X for now.

I can provide a debug log from Commander, if that would help.

+ Unless there is lag when you use the TX and RX buttons in the PTT panel on Commander's Configuration window's General tab, the root cause of the problem is not Commander; the problem is the conservative approach that WSJT-X takes in sending directives to Commander. Bill G4WJS has stated that he will address this in WSJT-X; I will help if requested.

73,

Dave, AA6YQ


Matt Foster
 

Thanks for the quick reply Dave. There is no delay when using the TX/RX buttons in the Config dialog of Commander with Split enabled.

I will post this to the WSJT-X forum.

--
73, Matt, N0EYE


Tapio OH3HN
 

In my case, disabling incoming UDP requests to WSJT-X does improve the issues I have with WSJT-X performance. I have configured my computer to use the direct interoperation between DXLab and WSJT-X (ie. without JTAlert). The problem is that FT8 audio is sometimes delayed after the  PTT activates.

According to Bill G4WJS, who sent me direct email about this, a temporary solution is to erase the "Band Activity" window in WSJT-X periodically, unfortunately this will not completely resolve the issue and restarting WSJT-X occasionally will be necessary to maintain optimum performance.

--
73 de Tapio at station OH3HN


Dave AA6YQ
 

+ AA6YQ comments below

On Mon, Apr 27, 2020 at 01:00 PM, Tapio OH3HN wrote:

In my case, disabling incoming UDP requests to WSJT-X does improve the issues I have with WSJT-X performance. I have configured my computer to use the direct interoperation between DXLab and WSJT-X (ie. without JTAlert). The problem is that FT8 audio is sometimes delayed after the  PTT activates.

According to Bill G4WJS, who sent me direct email about this, a temporary solution is to erase the "Band Activity" window in WSJT-X periodically, unfortunately this will not completely resolve the issue and restarting WSJT-X occasionally will be necessary to maintain optimum performance.

+ WSJT-X accepts a UDP directive to specify the font and background color of a particular callsign displayed in its "Band Activity" window. When configured to interoperate with directly with WSJT-X by considering it a spot source, SpotCollector uses this capability to color a callsign's letters based on "need" for the awards you are pursuing, and its background based on participation in eQSL and LoTW. WSJT-X can optionally apply this font and background coloring on all subsequent occurrences of the callsign until directed to use different colors for that callsign (e.g. if working the callsign changes its award status from "unworked" to "unconfirmed"); the SpotCollector-WSJT-X interoperation depends on this option to provide rapid coloring of previously-decoded callsigns.

+ Recently, Bill G4WJS informed me that the WSJT-X mechanism that does this callsign coloring is consuming excessive CPU time when having to remember the colors of hundreds of callsigns, possibly impacting decoding performance. I've suggested replacing the current WSJT-X mechanism with a cache that consumes less CPU time, but Bill's plan for the next version of WSJT-X is to limit the existing mechanism to storin colors for the first 100 decoded callsigns only. That will break the interoperation with SpotCollector.

+ I am modifying the next version of SpotCollector to no longer depend on WSJT-X remembering the coloring of decoded callsigns by incorporating a callsign color cache that quickly responds to each "decoded callsign" report from WSJT-X by sending a "highlight color" report to WSJT-X without having to wait to query the Spot Database for "need" and eQSL/LOTW participation; if the Spot Database query reveals a change in "need", both the cache and WSJT-X will be updated.

    73,

                Dave, AA6YQ

 


Tapio OH3HN
 

I upgraded to the new Spotcollector 8.6.9 and now I don't have the issues I had with WSJT-X performance after I configured my computer to use the direct interoperation between DXLab and WSJT-X (ie. without JTAlert).

Thanks Dave for the SC_WSJTX.exe bridge application!

--
73 de Tapio at station OH3HN