Slow to log from WSJTX to DXK ?


Andrew OBrien
 

I just set up DXK and SC for logging from WSJTX.  I have done this for several years without issues but today was configuring a new rig and related software (Slicemaster6000 and SmartSDR) . All is working but very slow . It takes about three minutes from when the "Log QSO" in WSJTX is clicked upon until the confirmation is received that is has passed to DXK.  When working several in quick succession , 5 minutes passed without any QSOs appearing in DXK and then four arrived all at same time.  Applications in use all seem to be working at normal speed but SC has some latency .  If I click on a check-box of modes to filter, it takes about 5 seconds for the check box to appear on screen.  There are no recent entries in SC's error log . Any thoughts ?  CPU seems to run around 50% . 

Processor Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 1800 Mhz, 4 Core(s), 8 Logical Processor(s)
Installed Physical Memory (RAM) 16.0 GB
Available Physical Memory 8.74 GB
System Type x64-based PC
Win 10


Andy  K3UK
 
 


Dave AA6YQ
 

+ AA6YQ comments below

I just set up DXK and SC for logging from WSJTX. I have done this for several years without issues but today was configuring a new rig and related software (Slicemaster6000 and SmartSDR) . All is working but very slow . It takes about three minutes from when the "Log QSO" in WSJTX is clicked upon until the confirmation is received that is has passed to DXK. When working several in quick succession , 5 minutes passed without any QSOs appearing in DXK and then four arrived all at same time. Applications in use all seem to be working at normal speed but SC has some latency . If I click on a check-box of modes to filter, it takes about 5 seconds for the check box to appear on screen. There are no recent entries in SC's error log . Any thoughts ? CPU seems to run around 50% .

+ That's too complex a configuration to run with Windows booted into "Safe Mode with Networking" to confirm my suspicion, which is that an application automatically started by Windows is interfering with your DXLab applications. Anti-malware is the usual culprit, but other applications are also known to interfere. See

https://www.dxlabsuite.com/dxlabwiki/ApplicationInteference

73,

Dave, AA6YQ


Andrew OBrien
 

Thanks Dave, I have not read that item in the Wiki.  I will do so this evening.
Andy K3UK


Andrew OBrien
 

I did not investigate this issue over the weekend.  Tonight, I worked a few FT8 stations using WSJTX Spotcollector and DXK, also Slicemaster 6000.   This is a message I received after waiting a few minutes between logging a QSO and it actually showing up in DXK (yes, it did show up after about 10 minutes !)
----

Unable to log QSO with W3FAY on 80m in FT8: DXKeeper did not accept the Log directive.
 
If DXKeeper is executing another function, wait for that function to complete, and then try logging the QSO again.

-----

Intriguing.  DX Keeper did not appear to be busy, but I need to look further.  I wonder if it is related to uploads to LoTW which were uploaded after each QSO.  I'll change that and see if it improves

Andy K3UK


Dave AA6YQ
 

I did not investigate this issue over the weekend. Tonight, I worked a few FT8 stations using WSJTX Spotcollector and DXK, also Slicemaster 6000. This is a message I received after waiting a few minutes between logging a QSO and it actually showing up in DXK (yes, it did show up after about 10 minutes !)


Unable to log QSO with W3FAY on 80m in FT8: DXKeeper did not accept the Log directive.

If DXKeeper is executing another function, wait for that function to complete, and then try logging the QSO again.


Intriguing. DX Keeper did not appear to be busy, but I need to look further. I wonder if it is related to uploads to LoTW which were uploaded after each QSO. I'll change that and see if it improves

+ Does this behavior occur if you're not running Slicemaster?

73,

Dave, AA6YQ


Andrew OBrien
 

Dave, I waited for 10-15 minutes for 4 QSOs to land in DXK from WSJTX.  Suddenly I saw a message saying that it was waiting to for TQSL to finish processing and then all 4 QSOs landed in DXK at once.  I checked my settings and I do NOT have upload to LoTW after each QSO st   So, not sure what is invoking LoTW activity. I'll look further in the morning
73 de K3UK


Andrew OBrien
 

Oh, and it happens with or without Slicemaster.
Andy 


Dave AA6YQ
 

+ AA6YQ comments below

Dave, I waited for 10-15 minutes for 4 QSOs to land in DXK from WSJTX. Suddenly I saw a message saying that it was waiting to for TQSL to finish processing and then all 4 QSOs landed in DXK at once. I checked my settings and I do NOT have upload to LoTW after each QSO st

So, not sure what is invoking LoTW activity. I'll look further in the morning

+ If you're using the direct interoperation between WSJT-X and DXLab, then whether or not a QSO logged from WSJT-X is submitted to LoTW is governed by the LoTW checkbox in the WSJT-X panel on the "Spot Sources" tab of SpotCollector's Configuration window.

+ If TQSL is that slow, I suspect that it's being impeded by your anti-malware.

73,

Dave, AA6YQ


Joe Subich, W4TV
 

On 2022-06-01 1:38 AM, Dave AA6YQ wrote:

+ If TQSL is that slow, I suspect that it's being impeded by your anti-malware.
I have, on occasion, seen WSJTX/JTAlert/DXKeeper/tQSL show the delay.
This issue has always been due to a slow "ack" from LoTW. In other
words, tQSL is waiting on a "received" confirmation from LotW.

73,

... Joe, W4TV


On 2022-06-01 1:38 AM, Dave AA6YQ wrote:
+ AA6YQ comments below
Dave, I waited for 10-15 minutes for 4 QSOs to land in DXK from WSJTX. Suddenly I saw a message saying that it was waiting to for TQSL to finish processing and then all 4 QSOs landed in DXK at once. I checked my settings and I do NOT have upload to LoTW after each QSO st
So, not sure what is invoking LoTW activity. I'll look further in the morning
+ If you're using the direct interoperation between WSJT-X and DXLab, then whether or not a QSO logged from WSJT-X is submitted to LoTW is governed by the LoTW checkbox in the WSJT-X panel on the "Spot Sources" tab of SpotCollector's Configuration window.
+ If TQSL is that slow, I suspect that it's being impeded by your anti-malware.
73,
Dave, AA6YQ


Dave AA6YQ
 

+ AA6YQ comments below

+ If TQSL is that slow, I suspect that it's being impeded by your anti-malware.
I have, on occasion, seen WSJTX/JTAlert/DXKeeper/tQSL show the delay.
This issue has always been due to a slow "ack" from LoTW. In other
words, tQSL is waiting on a "received" confirmation from LotW.

+ If that's the case, disabling automatic uploading to LoTW as each QSO is logged and instead uploading at the end of each operating system would be the recommended solution; on the Main window's QSL tab,

1. set the "QSL Via" panel to LoTW

2. click "Add Requested" to populate the QSL Queue with all QSOs not already uploaded to LOTW

3. click "Upload to LotW"

        73,

             Dave, AA6YQ

 

 

 


Andrew OBrien
 

Thanks Dave, I am just reading your recommendations and will test tonight.  However, I have determined that this issue only happens when WSJTX is involved , DXK logs fine for CW , Phone and other non-JT QSOs.  Late last night I discovered that there was a second check-box for uploading afrer each QSO to LoTW.  One in DXK and one in SC .  I was convinced that after unchecking BOTH, I would have solved the problem, I was wrong and went to bed ! I';; try your three steps tonight.
Andy K3UK


Andrew OBrien
 

A bit of progress , maybe last night I had the WSJST check box in SC not enabled when I tested things after turned OFF to settings relating to LoT W after each QSO.  Tonight, there is about a 20 second delay between logging in WSJTX and arrival in DXK's log.  That is much better.  I assume it is some Windows issue involving the SC_WSJTX widget .
Andy K3UK


Dave AA6YQ
 

+ AA6YQ comments below

A bit of progress , maybe last night I had the WSJST check box in SC not enabled when I tested things after turned OFF to settings relating to LoT W after each QSO. Tonight, there is about a 20 second delay between logging in WSJTX and arrival in DXK's log. That is much better. I assume it is some Windows issue involving the SC_WSJTX widget .

+ SC_WSJTX is an application, not a "widget". When the ability to remember callsign colors was retracted from WSJT-X, I developed SC_WSJTX to provide that capability, which is exploited by the direct interaction between WSJT-X and DXLab.

+ The most likely cause of the delay you are experiencing is interference from another application, typically your anti-malware. See

https://www.dxlabsuite.com/dxlabwiki/ApplicationInteference

73,

Dave, AA6YQ


Andrew OBrien
 

I’ve known you so long that as I typed the word “widget” I hesitated and thought I might get a comment on that . 
A few more WSJT QSOs tonight and the delays were very long again . So tomorrow I’ll do more investigation of malware possibilities .
Thanks
Andy K3UK 

On Wed, Jun 1, 2022 at 9:57 PM Dave AA6YQ <aa6yq@...> wrote:
+ AA6YQ comments below

A bit of progress , maybe last night I had the WSJST check box in SC not enabled when I tested things after turned OFF to settings relating to LoT W after each QSO.  Tonight, there is about a 20 second delay between logging in WSJTX and arrival in DXK's log.  That is much better.  I assume it is some Windows issue involving the SC_WSJTX widget .

+ SC_WSJTX is an application, not a "widget". When the ability to remember callsign colors was retracted from WSJT-X, I developed SC_WSJTX to provide that capability, which is exploited by the direct interaction between WSJT-X and DXLab.

+ The most likely cause of the delay you are experiencing is interference from another application, typically your anti-malware. See

https://www.dxlabsuite.com/dxlabwiki/ApplicationInteference

        73,

                Dave, AA6YQ








Dave AA6YQ
 

+ AA6YQ comments below

A few more WSJT QSOs tonight and the delays were very long again . So tomorrow I’ll do more investigation of malware possibilities .

+ The acid test for interference is to boot Windows into "Safe Mode with Networking", start your DXLab applications, and see if the misbehavior is still present.

73,

Dave, AA6YQ