+ AA6YQ comments below

On Fri, Jun 5, 2020 at 09:10 AM, Garrett Gonella wrote:

I need some help... I have tried uninstalling Commander and reinstalling it. I have cleared the registry and tried again, but my DX Keeper does not fill in the frequency field automatically when logging a contact.  I hope there is a simple fix.

+ Some questions:

1. what make and model transceiver are you using?

2. does Commander display your transceiver's frequency and mode when you make changes via the transceiver's front panel?

3. can you change your transceiver's frequency and mode using Commander's Main window?

4. what letters appear between the square brackets in the title bar of DXKeeper's Main window?

5. what version numbers appear in the title bars of Commander's and DXKeeper's Main window?

 

Note that uninstalling and re-installing a DXLab application is strongly discouraged; doing so rarely solves the problem at hand, but can create much worse problems.

         73,

               Dave, AA6YQ

login: G4WJS
Hello Bill, this is GB7MBC in Morecambe, Lancashire
running DXSpider V1.57 build 251
Nodes: 13/418 Clr - Users: 232/4812 Clr Max: 299/6042 Clr - Uptime: 4 06:24
GB7MBC>

For SpotCollector to consider a DX Cluster source valid, the prompt
that it returns must contain your username (as configured in the Spot
Source). See https://www.dxlabsuite.com/spotcollector/Help/DXClusterInteraction.htm

73,

    ~iain / N6ML

Thank you Iain!

Clearly I should have RTFM :(

I guess something changed at that cluster node, maybe switched to DXSpider, I don't recall which flavour of DX Cluster node it was for the last few Years when it has worked FB.

73
Bill
G4WJS.

--
73

Bill

G4WJS.

I need some help... I have tried uninstalling Commander and reinstalling it. I have cleared the registry and tried again, but my DX Keeper does not fill in the frequency field automatically when logging a contact.  I hope there is a simple fix.

On Fri, Jun 5, 2020 at 6:10 AM g4wjs <bill.8@classdesign.com> wrote:

On 05/06/2020 14:01, g4wjs wrote:

On 05/06/2020 13:59, g4wjs wrote:

It is my outgoing spot source and seems to be otherwise behaving normally.


I'll take that back, looking back at SpotCollector history I don't see any entries with that source as the "Network".

I have just disabled all other sources and can confirm spots are not being taken from this source, here's a session print:

This is the GB7MBC DXCluster system using DXSpider software

If you are getting echo and you don't want it, do: unset/echo

or (if you are a Microsoft telnet user) disable 'local echoing'.

+---------------------------------------------------------------------+

! Warning: Computer Misuse Act (1990) UK applies !

! This system may only be accessed by Radio Amateurs using their real !

! callsigns and in accordance with their jurisdiction's licensing !

! conditions. All connections to this system are recorded. !

+---------------------------------------------------------------------+





login: G4WJS
Hello Bill, this is GB7MBC in Morecambe, Lancashire
running DXSpider V1.57 build 251
Nodes: 13/418 Clr - Users: 232/4812 Clr Max: 299/6042 Clr - Uptime: 4 06:24
GB7MBC>

For SpotCollector to consider a DX Cluster source valid, the prompt
that it returns must contain your username (as configured in the Spot
Source). See https://www.dxlabsuite.com/spotcollector/Help/DXClusterInteraction.htm

73,

~iain / N6ML

It started working again about an hour after I posted this.

--
73, Matt, N0EYE

On 05/06/2020 13:59, g4wjs wrote:

It is my outgoing spot source and seems to be otherwise behaving normally.

I'll take that back, looking back at SpotCollector history I don't see any entries with that source as the "Network".

I have just disabled all other sources and can confirm spots are not being taken from this source, here's a session print:

This is the GB7MBC DXCluster system using DXSpider software

If you are getting echo and you don't want it, do: unset/echo

or (if you are a Microsoft telnet user) disable 'local echoing'.

+---------------------------------------------------------------------+

!           Warning: Computer Misuse Act (1990) UK applies            !

! This system may only be accessed by Radio Amateurs using their real !

!  callsigns and in accordance with their jurisdiction's licensing    !

!      conditions. All connections to this system are recorded.       !

+---------------------------------------------------------------------+





login: G4WJS
Hello Bill, this is GB7MBC in Morecambe, Lancashire
running DXSpider V1.57 build 251
Nodes: 13/418 Clr - Users: 232/4812 Clr Max: 299/6042 Clr - Uptime: 4 06:24
GB7MBC>
DX de K7CF:       7005.0  JA4XW                                       1304Z
DX de F4HZR:      7144.0  DL3JJ/P      WCA DL-00240                   1304Z
DX de HF0WFF:    14134.0  SP5UUD/P     SPFF-1722 PGA-SU08             1305Z
DX de W6XI:      50060.9  W5EME/B      EM32><>DM42                    1305Z DM42
DX de PA2PKZ:    28015.0  PI75ZUT      CW                             1305Z
DX de K7CF:       7005.0  JR1CEP                                      1306Z
DX de LA7EIA:    28074.0  UA3DLL       JO59CR<ES>KO85                 1306Z
DX de M0KED:      7118.0  GB2DD        D Day SES                      1306Z
DX de YO3GSK:    28074.5  UR9QT        FT8                            1307Z KN34
DX de W6XI:      50061.5  W5EME/B      EM32<>DM42 FREQ CORR.          1307Z DM42

SpotCollector is also reconnecting periodically, I assume because it thinks it's not working.

My initial command is:

set/dxgrid<13>set/wwv<13>sh/dx<13>sh/wwv<13>

which is working on other sources.

--
73

Bill

G4WJS.

On 05/06/2020 13:59, g4wjs wrote:

It is my outgoing spot source and seems to be otherwise behaving normally.

I'll take that back, looking back at SpotCollector history I don't see any entries with that source as the "Network".



--
73

Bill

G4WJS.

Hi Dave and all,

my main spot source window, a DXSpider telnet cluster node (gb7mbc.spoo.org:8000), refuses to stay hidden. If I close the window and check the "Hide" option in Config it hides, but the next SpotCollector restart leaves the spot source window open. The traffic light indicator stays yellow which is probably related. It is my outgoing spot source and seems to be otherwise behaving normally.



--
73

Bill

G4WJS.

+ AA6YQ comments below

I'm Larry, K0IS, from LeClaire, IA. First licensed as WN0ODK, became WA0ODK, and in 1978 passed my extra and became K0IS. Operate
mostly CW, recently applied for my 5BDXCC all CW and have six meter WAS, both with no more than 100 watts in the shack.

+ Welcome to DXLab, Larry!

So now I've decided to jump into the FT8 fray and I'm really enjoying it. I've recently downloaded JT Alert to bring WSJT-X and DX
Labs DX Keeper together. I know my QSO's are going to LOTW because after every FT8 QSO using WSJT-X when I "Log" the contact I get
first of all a pair of script errors which I ignore for now

+ Let's not ignore them. What is the text of these "script errors"?

, but a pop up requires me to sign in to LOTW with my password after every QSO. This while the next station may be calling me
already but I can't see the screen because the pop up telling me to sign in to LOTW is blocking the view. This has to stop, HI HI.

+ Evidently, you have password-protected your LoTW "Callsign Certificate". This is only necessary if your computer is not under your
physical control which from your description above doesn't sound like is the case. To remove the password protection that is
requiring you to unlock your "Callsign Certificate" so that each logged QSO can be uploaded, see these step-by-step instructions:

<https://lotw.arrl.org/lotw-help/removecertificatepassword/>

73,

Dave, AA6YQ

--

Larry A.

FWIW .. you can do the same with JT-Alert ... just use an ADIF file.

Neil, KN3ILZ

GridTracker is good if you use MSHV as well as WSJT-X and/or JTDX (or if you use just MSHV).  It lets you define an ADIF file as one of the logs.  So by defining wsjtx_log.adi as that file, it keeps your WSJT-X log up to date without importing and exporting.  

73.
Carl - WC4H

 

+ AA6YQ comments below

Thanks for this suggestion. Although the "fails to launch" behavior still occurred in safe mode, the additional debug it inspired led me to the root cause: Notepad++ had taken the file association for .bat files. In Explorer, this meant double-clicking a .bat file would open it for editing instead of running it. Once I undid the association, it started working correctly.

+ That's a new one, Bryan. I'm glad you spotted it!

73,

Dave, AA6YQ

Hi Dave,

Thanks for this suggestion.  Although the "fails to launch" behavior still occurred in safe mode, the additional debug it inspired led me to the root cause: Notepad++ had taken the file association for .bat files.  In Explorer, this meant double-clicking a .bat file would open it for editing instead of running it.  Once I undid the association, it started working correctly.  

Thanks for the support, and of course thanks for the great suite of programs!

73,
Bryan

+ AA6YQ comments below

Is anyone else having issues with Keeper not being able to connect to LoTW this morning? I'm getting this message: "Attempt to connect to LoTW failed: ResponseInfo = Gopher - Attribute not found (12057)".

The LoTW status page says everything is working on their end.

+ LoTW was working correctly a few minutes ago.

+ As a diagnostic step, please reboot Windows into "Safe mode with networking"; then start DXKeeper and invoke "Sync LoTW QSOs". What happens?

73,

Dave, AA6YQ

+ AA6YQ comments below

On my new Win10 PC with fresh installations of DXLabs and Trusted QSL, I have run into a problem where DXKeeper simply does not launch tqsl.exe for any LoTW operation. Versions are TQSL 2.5.4 and DxKeeper 15.6.0.

The basic "news" check done by DXKeeper at startup eventually fails with the TQSL is unable to contact LOTW error, and no C:\DXLab\DXKeeper\LotWNews.txt file is created. However, if I copy the command from C:\DXLab\DXKeeper\LotWCommand.bat:

"C:\Program Files (x86)\TrustedQSL\tqsl.exe" -n 2>"C:\DXLab\DXKeeper\LotWNews.txt"

and paste it into a Command Prompt, it runs fine, and C:\DXLab\DXKeeper\LotWNews.txt is created.

Even the simple "Run" button in the LoTW configuration tab (DXKeeper QSL Configuration --> LotW) does not work - nothing happens. No errors reported by DXKeeper, TQSL, or Windows. However, as before, if I copy the command from LotWCommand.bat:

"C:\Program Files (x86)\TrustedQSL\tqsl.exe"

it launches the TQSL app just fine.

I can launch TQSL fine from the desktop icon, and can perform log signing and upload manually, so it is not a LotW server or network connectivity issue.

I have added Windows Defender exceptions for:
C:\DXlab
C:\Program Files (x86)\TrustedQSL



I have verified file permissions include "Read and Execute" on all files in the above directories.

In case it might be relevant: the DXKeeper settings were imported from a Workspace saved on another computer. The TQSL location was the same on the old computer, but verified to be the same on this new computer.

What else should I check?

+ As a diagnostic step, please reboot Windows into "Safe mode with networking". Then direct the Launcher to start DXKeeper; can DXKeeper now start TQSL?

73,

Dave, AA6YQ

+ AA6YQ comments below

If you use GridTracker, it will log to Dxkeeper without needing to use anything else. It can also upload to many online services such as lots and hrdlog.

+ DXKeeper's LoTW automation depends on each QSO accurately reflecting its LOTW status. Using another application to submit QSOs to LoTW behind DXKeeper's back should be avoided. See

<https://www.dxlabsuite.com/dxlabwiki/QSLingLotW>

73,

Dave, AA6YQ

I neglected to say that this is on "Sync LoTW QSOs".

--
73, Matt, N0EYE