Great Software. Love it. 

* I couldn't find a click here for enhancement requests... So if this isn't how to, let me know. So maybe we make one or make it more obvious?

Ok, for my enhancement request. 

Background:

When I log a qso and do the call book lookup, I get the arrl section filled out automatically if the state is not divided into multiple sections. If it is divided (such as California or Texas), I have to look up the section by hand using http://www.arrl.org/section-boundaries which lists the counties. (I printed it out)  Luckily I have the county due to the lookup. 

 

Request:

A "?" button for the arrl section so that it uses the county to get the correct arrl section. I don't think these change often, so maybe I could make a CSV file to search. Or it can be automatically determined by the county listed instead of a changeable field. I don't see a reason to have the arrl section and county reflect a different county/section match.

 

Thanks so much,

Scott 

KD4SIR

---

This email has been checked for viruses by AVG antivirus software. www.avg.com

That seemed to work fine.  I'll look elsewhere for my problem.  Thanks for the help.

+ That means one or more of the applications that Windows is automatically starting when booted "normally" is interfering with DXKeeper. The culprit is usually anti-malware. You're already aware of the "Getting Started" article on this topic.

      73,

            Dave, AA6YQ

That seemed to work fine.  I'll look elsewhere for my problem.  Thanks for the help.

-Kurt

So it seems that the manual method also has flaws.  LoTW so far uploads fine.  eQSL looks like it uploads 3-4 contacts then gets stuck.  I need to force DXK to shut down. I disable Malwarebytes, CCleaner and Defender with no change in behaviour.

+ Please do the following:

1. reboot Windows into "Safe Mode with Networking"

2. start DXKeeper

3. direct DXKeeper to submit 6 QSOs to eQSL

+ What happens?

      73,

           Dave, AA6YQ

+ AA6YQ comments below

I got the comms between WSJTX and JTALERT working.

+ What changes did you make to accomplish this?

Now on to the next piece. For the most part all is running well. However, occasionally I'm getting an error message:


Logging warning

Error Message: DXKeeper File: Unable to confirm QSO Logged

+ That error message comes from JT-Alert. Was the QSO actually logged in DXKeeper?

Note: The QSO is still saved to the WSJT-X Log File

This seems to happen after a number of successfully logged QSOs.

Sometimes I get another error message:


Unable to Log QSO due to a lengthy directive from another DXLab application

+ That message from DXKeeper only appears when you attempt to log a QSO from DXKeeper's Capture window, but DXKeeper was busy processing a directive from another application for more than 30 seconds -- which should never happen.

Any ideas?

+ Together, these symptoms add up to "something is interfering with DXKeeper"; the most likely culprit is an anti-malware application not configured to consider DXKeeper to be safe, but there are other possibilities. See

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

Also, How do I move the WSJT-X logs that weren't logged to DXK after the fact?

+ WSJT-X maintains a log file in ADIF format. Open this file with a text editor, and locate the ADIF record for each QSO that should have been logged in DXKeeper, but wasn't. Create a new file named Missing.ADI, and place each missing ADIF record in this file. Then close Missing.ADI, and direct DXKeeper to import it.

73,

Dave, AA6YQ


-Kurt, KR2C


On 11/20/2021 4:43 PM, Dave AA6YQ wrote:

+ AA6YQ comments below

OK, Thank you. I was thinking that the problem was between jtalert and DXK.

+ There could be a problem between JT-Alert and DXKeeper, but if JT-Alert isn't interoperating with WSJT-X, JT-Alert will have nothing for DXKeeper to log.

+ Start upstream, and proceed downstream step-by-step:

WSJT-X => JT-Alert => DXKeeper

73,

Dave, AA6YQ

am confused by your statement:
". . . To exploit the "activation records" present in the RDA database, the
next version of DXKeeper takes a QSO's "Begin Date" into consideration when
using the Main window's "Log QSOs" tab to log a QSO with a Russian or USSR
callsign with "Optimize for realtime QSO entry" disabled, deriving the DXCC
entity, CQ zone, ITU zone, and IOTA tag from the callsign's Oblast and
District."

In particular the line: . . . with "Optimize for realtime QSO entry"
disabled. This seems to conflict with
https://www.dxlabsuite.com/dxkeeper/Help/Configuration.htm where it says:
When this box is unchecked, DXKeeper's Main window is optimized for manually
entering past QSOs:

In the past I have disabled--realtime QSO entry--only when I was editing my
logbook. Does this mean that the Oblast and District optimizing will only
take place if I manually enter the QSO on the "Log QSOs" tab of DXKeeper?
What about the Capture Window?

+ When you log a QSO with a Russian station via the Capture window, DXKeeper will query the RDA database for that station's location on the current date. 

+ When you log a QSO with a Russian station via the WinWarbler's "QSO Info" panel, DXKeeper will query the RDA database for that station's location on the current date. 

+ When you log a QSO with a Russian station via the Main window's "Log QSOs" tab with "Optimize for realtime QSO entry" enabled, DXKeeper will query the RDA database for that station's location on the current date. 

+ When you log a QSO with a Russian or USSR station via the Main window's "Log QSOs" tab with "Optimize for realtime QSO entry" disabled, DXKeeper will query the RDA database for that station's location on the QSO's "begin" date.

+ Before 1994, stations from "non-Russian" areas of the USSR -- e.g. Lithuania or Kazakhstan -- could make QSOs from Russia using their home callsigns. These QSOs are valid for RDA awards, hence the reason for querying the RDA database when logging a QSO that was made prior to 1994.

73,

      Dave, AA6YQ