Date   

Re: DXLab Commander connection to HF-AUTO SW

Norm - KC1BMD
 

Jon, perhaps you have the HFAUTO SW already and understand it's usage but, just to be clear, a serial cable from the PC will not do anything without the HFAUTO SW.
--
73, Norm/KC1BMD


Re: DXKeeper - LotW Sync QSO and QSLs - Not Responding

Jon Gefaell
 

On Sat, Feb 27, 2021 at 07:10 PM, Dave AA6YQ wrote:
I, w6de, run an i7 6-core system, NVME SSD, 16 GB memory and I almost never see 40% CPU utilization. I see peaks of CPU use only when running WSJTX at its end of receive decoding. My quote of Jon in item two clearly points to a software conflict or undetected malware infestation.

Actively consuming CPU at the time were HDSDR (1.66Mhz spread, tuned to 3885), JTalert & WSJT-X (actively decoding on 7,074kHz), Chrome (viewing local 2K video stream rendered with Plex media server), a background file-sharing application, and perhaps others. 40% was the peak utilization noted observing for a minute or two.

However, my CPU consumption isn't implicated as the cause of the reported issue, however. And my system runs very pleasingly fast in all aspects. Nothing 'crawls'.  It does all these things at once with ease. I built it to use it. :) 


Re: DXKeeper - LotW Sync QSO and QSLs - Not Responding

Dave AA6YQ
 

+ AA6YQ comments below

There is something clearly wrong in Jon’s software configuration given the following information Jon Getfall has provided:

Item one: “I run an eight-core i7 with 64GB of RAM and have over 1GB of free space on my NVME SSD's. Resource monitoring shows vast amounts of headroom in terms of processor, network bandwidth, and memory utilization. I have no issues with my system and the many things it does. So, it's elusive. I'm going with a latent defect in Windows, but what is triggering it is... inexplicable.”


Item two: “Memory is 41% utilized, CPU is 40%, Disk and Network are 0%, and GPU is 8%. I don't have the skills to look into the number of open file handles, etc. But there are no other evident issues with closing, opening, and using numerous applications that would consume additional resources, open file handles and network connections, allocating memory, etc.”

Item three: “I never, ever run anti-malware software. They're the main source of problems. IMO, but YMMV, of course. I do run regular standalone scans and always come up clean. The built-in Windows 10 firewall does its thing, and my Unifi Software Defined Network's firewall is doing a lovely job as well. But agreed, what's in place is in place when it works and when it doesn't.”


I, w6de, run an i7 6-core system, NVME SSD, 16 GB memory and I almost never see 40% CPU utilization. I see peaks of CPU use only when running WSJTX at its end of receive decoding. My quote of Jon in item two clearly points to a software conflict or undetected malware infestation.

+ Excellent point, Dave! The 40% CPU consumption is a definitely red flag. The Windows Task Manager should reveal the source of this.

73,

Dave, AA6YQ


Re: DXLab Commander connection to HF-AUTO SW

Jon Gefaell
 

Oh, I get it. For some reason, I thought it had something to do with connecting to the HF-Auto. This connects Commander to the HF-Auto SW. So, I'll use a USB serial adapter to connect the tuner. Thank you! 


On Sat, Feb 27, 2021 at 06:07 PM, Dave AA6YQ wrote:
+ If you're asking how to configure Commander's UDP Network Service, see "Commander: Network Service" in


Re: Lat & Long

Curt Bowles
 

[45 48' 45" N  63 52' 30" W] for both
--
Curt Bowles
VE3ZN


Re: DXKeeper - LotW Sync QSO and QSLs - Not Responding

w6de
 

There is something clearly wrong in Jon’s software configuration given the following information Jon Getfall has provided:

Item one: “I run an eight-core i7 with 64GB of RAM and have over 1GB of free space on my NVME SSD's. Resource monitoring shows vast amounts of headroom in terms of processor, network bandwidth, and memory utilization. I have no issues with my system and the many things it does. So, it's elusive. I'm going with a latent defect in Windows, but what is triggering it is... inexplicable.”

 

Item two: “Memory is 41% utilized, CPU is 40%, Disk and Network are 0%, and GPU is 8%. I don't have the skills to look into the number of open file handles, etc. But there are no other evident issues with closing, opening, and using numerous applications that would consume additional resources, open file handles and network connections, allocating memory, etc.”

 

Item three: “I never, ever run anti-malware software. They're the main source of problems. IMO, but YMMV, of course. I do run regular standalone scans and always come up clean. The built-in Windows 10 firewall does its thing, and my Unifi Software Defined Network's firewall is doing a lovely job as well. But agreed, what's in place is in place when it works and when it doesn't.”

 

I, w6de, run an i7 6-core system, NVME SSD, 16 GB memory and I almost never see 40% CPU utilization.  I see peaks of CPU use only when running WSJTX at its end of receive decoding.  My quote of Jon in item two clearly points to a software conflict or undetected malware infestation. 

 

Have you read this DXLab WIKI article and followed its advice?

http://www.dxlabsuite.com/dxlabwiki/TerminateUnnecessaryApplications?highlight=%28programs%29

 

73,

Dave, w6de

 

From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Jon Gefaell
Sent: Sunday, February 28, 2021 00:01
To: DXLab@groups.io
Subject: Re: [DXLab] DXKeeper - LotW Sync QSO and QSLs - Not Responding

 

On Sat, Feb 27, 2021 at 02:05 PM, Dave AA6YQ wrote:

+ For the record, I frequently see the "not responding" message in window title bars -- including in the title bars of Microsoft applications. Letting the operation run to completion invariably succeeds.

Thank you, Dave. I just did this again so that I could explain it carefully. Hopefully, this is useful at some point. I'm delighted to be discussing this, thank you.

I selected "Sync LOTW QSLs." The progress dialogue pops up and halts at 59 seconds. The title bar displays 'not responding,' and shortly thereafter, the windows dialogue comes up, saying the same thing and offering a choice of stopping the program or waiting. I select to wait. The DXKeeper windows (main, capture, and the QSL sync progress) are shaded. I have been waiting 35 minutes with no change.

Memory is 41% utilized, CPU is 40%, Disk and Network are 0%, and GPU is 8%. I don't have the skills to look into the number of open file handles, etc. But there are no other evident issues with closing, opening, and using numerous applications that would consume additional resources, open file handles and network connections, allocating memory, etc. 

I'll keep at it. It feels like a blocking issue. One day I'll find my gremlin. :) Thanks again, sir!

 


Re: DXLab Commander connection to HF-AUTO SW

Dave AA6YQ
 

+ AA6YQ comments below

Terry Glagowski / W1TR developed an application called HFAUTO SW to control the Palstar HF-AUTO ATU. I installed it and connected to to DXLab Commander via the [Net Serv] configuration.

How very nice! I've downloaded and installed it. Thanks for the heads up. Can you tell me more about the [Net Serv] configuration, please?

+ If you're asking how to configure Commander's UDP Network Service, see "Commander: Network Service" in

https://www.dxlabsuite.com/commander/Help/NetworkService.htm#UDP_Network_Service

73,

Dave, AA6YQ


Re: DXKeeper - LotW Sync QSO and QSLs - Not Responding

Dave AA6YQ
 

@ AA6YQ comments below

+ If you (understandably) cannot diagnose Windows yourself, then I suggest engaging with Microsoft Support to obtain their assistance in tracking down the root cause of this behavior.

I can't help but chuckle at the notion. "Hello, DX Keeper is has failures to sync LoTW QSLs for me but works for others." ;)

@ Try "I have an application that downloads information from a URL. When I run this application immediately after booting Windows, it succeeds. When I run this application after starting other applications, Windows announces that the application has stopped working".

@ You can provide them with the URL if you temporarily enable the "PC has no internet connection" option I mentioned earlier.

@ You can also inform them that the application uses Microsoft's urlmon.dll component to download the information.

73,

Dave, AA6YQ


Re: DXLab Commander connection to HF-AUTO SW

Jon Gefaell
 

On Fri, Feb 26, 2021 at 04:13 PM, Norm - KC1BMD wrote:
Terry Glagowski / W1TR developed an application called HFAUTO SW to control the Palstar HF-AUTO ATU. I installed it and connected to to DXLab Commander via the [Net Serv] configuration.
How very nice! I've downloaded and installed it. Thanks for the heads up. Can you tell me more about the [Net Serv] configuration, please? 


Re: DXKeeper - LotW Sync QSO and QSLs - Not Responding

Jon Gefaell
 

On Sat, Feb 27, 2021 at 04:47 PM, Dave AA6YQ wrote:

+ The fact that Windows displays a separate window offering to stop DXKeeper or continue waiting is also unique to your situation.

I look forward to hearing back from the OP whether waiting has resolved his concern. Or maybe I missed that?

+ You have reported that the LoTW Sync functions work if you start DXKeeper immediately after rebooting Windows; that likely rules out interference from anti-malware or firewall applications automatically started by Windows, since they were running when you reported success. 

Agreed. I never, ever run anti-malware software. They're the main source of problems. IMO, but YMMV, of course. I do run regular standalone scans and always come up clean. The built-in Windows 10 firewall does its thing, and my Unifi Software Defined Network's firewall is doing a lovely job as well. But agreed, what's in place is in place when it works and when it doesn't. 

+ If you (understandably) cannot diagnose Windows yourself, then I suggest engaging with Microsoft Support to obtain their assistance in tracking down the root cause of this behavior.

I can't help but chuckle at the notion. "Hello, DX Keeper is has failures to sync LoTW QSLs for me but works for others." ;)

The *only* reason I run Windows, which I despise, is because of amateur radio. With DX Lab Suite square at the center. I couldn't even consider anything else.

I think this is my cross to bear, on my own. As problems go, it's pretty mild. Grin. 

Thanks as always for your efforts.


Re: DXKeeper - LotW Sync QSO and QSLs - Not Responding

Dave AA6YQ
 

+ AA6YQ comments below

Thank you, Dave. I just did this again so that I could explain it carefully. Hopefully, this is useful at some point. I'm delighted to be discussing this, thank you.

I selected "Sync LOTW QSLs." The progress dialogue pops up and halts at 59 seconds. The title bar displays 'not responding,' and shortly thereafter, the windows dialogue comes up, saying the same thing and offering a choice of stopping the program or waiting. I select to wait. The DXKeeper windows (main, capture, and the QSL sync progress) are shaded. I have been waiting 35 minutes with no change.

Memory is 41% utilized, CPU is 40%, Disk and Network are 0%, and GPU is 8%. I don't have the skills to look into the number of open file handles, etc. But there are no other evident issues with closing, opening, and using numerous applications that would consume additional resources, open file handles and network connections, allocating memory, etc. 

I'll keep at it. It feels like a blocking issue. One day I'll find my gremlin. :) Thanks again, sir!

+ The fact that Windows displays a separate window offering to stop DXKeeper or continue waiting is also unique to your situation..

+ You have reported that the LoTW Sync functions work if you start DXKeeper immediately after rebooting Windows; that likely rules out interference from anti-malware or firewall applications automatically started by Windows, since they were running when you reported success. 

+ If you (understandably) cannot diagnose Windows yourself, then I suggest engaging with Microsoft Support to obtain their assistance in tracking down the root cause of this behavior.

        73,

                Dave, AA66YQ

 


Re: Lat & Long

Dave AA6YQ
 

+ AA6YQ comments below
Just set up DXLab Suite on a new laptop... all went well but an issue with Lat/long in DX View and Prop View.

My QTHID Lat/Long is correct for my home QTH. [45 31' 14" N 76 37' 30" W] in DXK & SC....

DXVIEW General Tab Lat/Long... was incorrect [45 48' 45" N  63 52' 30" W] so I changed it to my Home QTH lat/long. ( This also changes My Home QTH on DX Atlas). 

Prop View Parameter Tab Lat/long was incorrect [45 48' 45" N  63 52' 30" W] so I changed it to my Home QTH lat/long. 

I save all my settings to a workspace BUT when I opened up all the apps again the lat/long for both DXVIEW and Prop View changed  and neither app keeps my home QTH's Lat/long.

+ When you start DXView and PropView, what latitude and longitude do each display for your QTH?

     73,

             Dave, AA6YQ

 


Re: DXKeeper - LotW Sync QSO and QSLs - Not Responding

Jon Gefaell
 

On Sat, Feb 27, 2021 at 02:05 PM, Dave AA6YQ wrote:
+ For the record, I frequently see the "not responding" message in window title bars -- including in the title bars of Microsoft applications. Letting the operation run to completion invariably succeeds.

Thank you, Dave. I just did this again so that I could explain it carefully. Hopefully, this is useful at some point. I'm delighted to be discussing this, thank you.

I selected "Sync LOTW QSLs." The progress dialogue pops up and halts at 59 seconds. The title bar displays 'not responding,' and shortly thereafter, the windows dialogue comes up, saying the same thing and offering a choice of stopping the program or waiting. I select to wait. The DXKeeper windows (main, capture, and the QSL sync progress) are shaded. I have been waiting 35 minutes with no change.

Memory is 41% utilized, CPU is 40%, Disk and Network are 0%, and GPU is 8%. I don't have the skills to look into the number of open file handles, etc. But there are no other evident issues with closing, opening, and using numerous applications that would consume additional resources, open file handles and network connections, allocating memory, etc. 

I'll keep at it. It feels like a blocking issue. One day I'll find my gremlin. :) Thanks again, sir!

 


Lat & Long

Curt Bowles
 

Hi Dave...

Just set up DXLab Suite on a new laptop... all went well but an issue with Lat/long in DX View and Prop View.

My QTHID Lat/Long is correct for my home QTH. [45 31' 14" N 76 37' 30" W] in DXK & SC....

DXVIEW General Tab Lat/Long... was incorrect [45 48' 45" N  63 52' 30" W] so I changed it to my Home QTH lat/long. ( This also changes My Home QTH on DX Atlas). 

Prop View Parameter Tab Lat/long was incorrect [45 48' 45" N  63 52' 30" W] so I changed it to my Home QTH lat/long. 

I save all my settings to a workspace BUT when I opened up all the apps again the lat/long for both DXVIEW and Prop View changed  and neither app keeps my home QTH's Lat/long.

This is repeatable so I suspect maybe a setting is not correct but I can't find what is causing this1 Help Pse.

73


--
Curt Bowles
VE3ZN


testing help sought: additional support for the Yaesu FTDX-10

Dave AA6YQ
 

I have extended Yaesu FTDX-10 support in the next version of Commander to provide the ability to specify a default width and a
default shift for each of 7 modes, with the option to automatically set the specified width and shift after a mode change:

www.dxlabsuite.com/commander/FTDX-10%20default%20bandwidth%20by%20mode.jpg

After getting this working with an FTDX-10, my plan is to provide similar support for other recent Yaesu transceivers (3000, 1200,
991, 891, 9000, 5000, 2000, 950, 450).

If you have a Yaesu FTDX-10 and would be willing to test this new version, please send email to me via

aa6yq (at) ambersoft.com

Note: the Yaesu FTDX-10 documentation does not specify the available widths when the transceiver is operating in AM or FM, so
reverse engineering these will be part of the fun!

73,

Dave, AA6YQ


Re: Support for icom ID-5100

Dave AA6YQ
 

+ AA6YQ comments below

Hi, is support for ID-5100 planned ? It already almost works using othe models.

+ The ID-5100 only operates on 144 mHz and 440 mHz, and only in AM, FM, or Digital Voice; neither CW nor SSB are supported. It's CI-V instruction set is significantly different than that of any other Icom transceiver supported by Commander.

+ I have no plan to extend Commander to support the ID-5100.

73,

Dave, AA6YQ


Re: Support for icom ID-5100

Peter Laws / N5UWY
 

On Sat, Feb 27, 2021 at 4:23 PM <nicolas.mailloux@micronick.com> wrote:

Hi, is support for ID-5100 planned ? It already almost works using othe rmodels.
Which radio did you set it to that is "close"? I have the baby
brother, ID-4100A and would like to see what I can do with Commander
and that radio.



--
Peter Laws | N5UWY | plaws plaws net | Travel by Train!


Support for icom ID-5100

nicolas.mailloux@...
 

Hi, is support for ID-5100 planned ? It already almost works using othe rmodels.


Re: LoTW and eQSL status of QSO's uploaded from HRD Logbook

Dave AA6YQ
 

+ AA6YQ comments below

I'd like to know if it matters whether I uploaded the QSO's using HRD instead of using DXKeeper (i.e. does DXKeeper care)?

+ LoTW doesn't know which application submitted QSOs, and so can't report this information when directed to provide it.

I understood that LoTW would not know how data was submitted but thought DXKeeper might care if it tracked whether it uploaded the data or not. But OK, I understand. After looking at my log more carefully, it seems that the eQSL and LoTW data was populated when I imported the ADIF, so I think I only have the 18 newest QSO's to sync for both online systems.

Maybe I'll switch from HRD logbook to DXKeeper for everything if I can get accustomed to it. The capabilities (and number of configuration items) is a little daunting and there lots of ways to mess things up, whereas the HRD Logbook could be used as a graphic on "Logging for Dummies" (hi). I do back up my DXK log on exit, so that should help if I run into problems.

+ DXLab was designed for users willing to make the investment of time required to effectively use its advanced capabilities. Yes, being able to modify thousands of QSOs en masse means that you can "mess things up" if you haven't ever reviewed the documentation and fail to backup your log beforehand - but it's mighty handy when you've imported a file of QSOs whose times were recorded in PST instead of UTC, or whose Station Callsign items are all incorrect. Yes, it takes time to learn how to exploit SpotCollector's Spot Database to identify propagation openings between your QTH and needed DX stations, and to discern the operating patterns of those needed DX stations; aggressive DXers are happy to traverse that learning curve - rather than spend time in pileups with the cluster hordes.

+ There's nothing wrong with using a simpler application if it better meets your needs.

73,

Dave, AA6YQ


Re: DXKeeper - LotW Sync QSO and QSLs - Not Responding

Dave AA6YQ
 

+ AA6YQ comments below

* That's a likely symptom of resource exhaustion, Windows misconfiguration, or a latent defect in Windows - which is why I posted the above advice.

I've re-read both my description and his. They seem complimentary. There may be an issue of semantics, and my choice of words to describe the issue may benefit from fine-tuning. I would appreciate some insight as to how our two reports are crucially different.

+ Hank reported the appearance of "not responding" in DXKeeper's Main window's title bar, and (understandably) misinterpreted it to mean that the Sync process was not proceeding. My advice is to let the operation run to completion, ignoring the "not responding" message.

+ You reported that unless you start DXKeeper alone after rebooting, DXKeeper never completes the Sync process. The fact that the Sync process runs to completion when your instance of Windows has been freshly rebooted is what points to a resource management or misconfiguration issue in Windows.

+ For the record, I frequently see the "not responding" message in window title bars -- including in the title bars of Microsoft applications. Letting the operation run to completion invariably succeeds.

73,

Dave. AA6YQ

2621 - 2640 of 202667