Date   

question callbook database populating fields in dxkeeper

AB2E Darrell
 

Greetings all,
A quick question. I'm getting ready to set up dxkeeper and buy a callbook subscription.
Before I do, I want to verify a feature of DXKeeper.
The DXLabSuite Wiki mentions that DXkeeper will populate missing fields from the callbook lookup.
Can anyone tell me if it will populate the US County?
Can it do this with a complete log update?
I'm also new to county hunting so have never entered counties in DXKeeper so far but I have a log going back many years.

Thanks and a Happy Thanksgiving to all!
73 Darrell AB2E


Re: DxKeeper Enhancement Request - arrl section field automation

KA9JAC
 

I am a bit curious...

Other then the contests where participants have to exchange their arrl section,
is there somewhere else where these are required?

73,
Bob, KA9JAC

On 11/25/2021 4:06 AM, Scott wrote:
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




AVG logo

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



DxKeeper Enhancement Request - arrl section field automation

Scott <scotthibbs@...>
 

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


Pathfinder search updates

Dave AA6YQ
 

If you started Pathfinder yesterday, you were prompted to accept an updated ClubLog search file developed by Jon KM8V that makes it
easy to conduct a Log Search in Club Log.

When you next start Pathfinder, you will be prompted to accept both the updated ClubLog search file and an improved QRZ search file
named QRZdirect.txt, also developed by Jon. QRZdirect displays the target callsign's QRZ page and positions it in Pathfinder so that
the target callsign's information appears at the top of the page, making better use of Pathfinder's main window.

If you have DXKeeper configured to use "QRZ.com via Pathfinder" as your callbook, note that callbook lookups will still display the
target callsign's QRZ page without Jon's improvement. Changing this would potentially require changing the code in Pathfinder that
scrapes callbook information from the target callsign's QRZ page, and then testing this change on all active versions of Windows.
I've had enough of that after last week's "nicknames are now rendered in bold font" episode.

If you discover a new online source of QSL information, or an existing Pathfinder-accessible source that isn't working correctly,
please let me know.

Many thanks to Jon KM8V for his contribution to Pathfinder!

73,

Dave, AA6YQ


Re: improved support for the Russian District Award

w6de
 

Got it.  Since I believe I have already loaded all my Russian/USSR contacts prior to 1994.   I’ll only be manually entering/changing contacts I find still missing or I have entered in error, which nearly 30 years after those QSOs is unlikely.

 

Thank you and 73

Dave, w6de

 

From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Dave AA6YQ via groups.io
Sent: Wednesday, November 24, 2021 01:03
To: DXLab@groups.io
Subject: Re: [DXLab] improved support for the Russian District Award

 

+ AA6YQ comments below

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


Re: jtalert not logging to dxkeeper

Dave AA6YQ
 

+ AA6YQ comments below
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

    
     


Re: jtalert not logging to dxkeeper

Kurt Cathcart
 

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


-Kurt

On 11/24/2021 11:05 AM, Dave AA6YQ wrote:
+ AA6YQ comments below
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


Re: jtalert not logging to dxkeeper

Dave AA6YQ
 

+ AA6YQ comments below
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


Re: jtalert not logging to dxkeeper

Kurt Cathcart
 

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.


-Kurt, KR2C

On 11/24/2021 9:03 AM, Dave AA6YQ wrote:
@ more AA6YQ comments below

++ I do run Malwarebytes. Thank you for the insight.

@ Quite a few users have reported interference from letting Malware Bytes run in the background. I only use it to conduct occasional scans.

@ What happens when you disable it?

73,

Dave, AA6YQ





Re: jtalert not logging to dxkeeper

Dave AA6YQ
 

@ more AA6YQ comments below

++ I do run Malwarebytes. Thank you for the insight.

@ Quite a few users have reported interference from letting Malware Bytes run in the background. I only use it to conduct occasional scans.

@ What happens when you disable it?

73,

Dave, AA6YQ


Re: jtalert not logging to dxkeeper

Kurt Cathcart
 

On 11/23/2021 5:48 PM, Dave AA6YQ wrote:
+ AA6YQ comments below

I got the comms between WSJTX and JTALERT working.

+ What changes did you make to accomplish this?
++ I had the wrong version of .net


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?
++ It was not logged into DXKeeper.  That is probably why I got the manual logging error below.  What I have noticed is that when it fails, it seems to fail when DXK is auto uploading to LoTW or eQSL. I set JTAlert to not instruct DXK to auto upload and then I do it manually in DXK after I'm don with my radio time.  I haven't had a problem yet.


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.
++  I do run Malwarebytes.  Thank you for the insight.
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










Re: improved support for the Russian District Award

Dave AA6YQ
 

+ AA6YQ comments below
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


Re: improved support for the Russian District Award

w6de
 

I 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?

In the past year or two, I did run W6TV's scripts on my DXKeeper log.

73
Dave, w6de

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Dave AA6YQ via
groups.io
Sent: Tuesday, November 23, 2021 01:03
To: DXLab@groups.io
Subject: [DXLab] improved support for the Russian District Award

I have developed an application that downloads a list from

https://cfmrda.ru/files/callsigns_rda.cs

and creates an RDA database.

Some entries on the list simply specify the callsign's Oblast and District,

R0AA KK-08

Some entries on the list specify one or more "activation records",
indicating that the callsign operated in a particular Oblast and
District during a particular time interval. Activation records prior to 1994
can specify USSR callsigns, e.g.

EK1SK <1991-01-01, 1992-01-31> VO-29

meaning that EK1SK operated from VO-29 from 1991-01-01 to 1992-01-31.

The next version of DXView provides the option to download and install the
new RDA database. I will periodically make new versions
of the RDA database available, as I've been doing with the eQSL and LoTW
databases, as Joe W4TV has been doing with the DXCC
database, as Tom KQ5S has been doing with the USAP database, and as Dick
N3XRU has been doing with the IOTA database.

If the RDA database is present, the next versions of DXView, DXKeeper, and
SpotCollector will exploit it; SpotCollector's Spot
Database, for example, includes a new Secondary field that is populated with
each active Russian callsign's District code. The next
version of WinWarbler will accepts Secondary Administrative Subdivision
information from DXView and SpotCollector.

Up till now, DXLab applications have always derived information from
callsigns under the assumption that current prefix-to-location
rules apply. Joe W4TV's "fix scripts" automate the correction of QSOs made
under different prefix-to-location rules, but must be
manually invoked. 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.

Note that DXLab's "Realtime Award Tracking" has not been extended to support
the Russian District Award. Identifying active stations
in needed Districts can be accomplished with a manually-maintained filter in
SpotCollector.

The next versions of DXView, DXKeeper, SpotCollector, and WinWarbler have
been sent to several users for testing. If you're in hot
pursuit of RDA awards and would like to help test these new versions, please
let me know via

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ


Re: jtalert not logging to dxkeeper

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






--
This email has been checked for viruses by AVG.
https://www.avg.com


Re: jtalert not logging to dxkeeper

Kurt Cathcart
 

OK -


I got the comms between WSJTX and JTALERT working.  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

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


Any ideas?


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


-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






Re: DXKeeper running very slowly

Dave AA6YQ
 

Since last week DXKeeper is logging calls so slowly as to make working anything very tedious. It can take up to 40 seconds from pressing the log pop up to the callsign appearing at the top of my DXKeeper list.
It starts ok but gradually gets slower and slower. I've removed all AV ware and stopped eventually everything except DXKeeper.
I feel the cause is W11 Insider preview. I'm inclined to persist. Anyone else who has similar problems who can advise please feel free to do so.

+ Please reboot Windows into "Safe mode with networking", start DXKeeper, and log some test QSOs.

+ Any change in behavior?

73,

Dave, AA6YQ


Re: DXKeeper running very slowly

Hasan Schiers N0AN
 

Tony,

There are a number of programs (which may have resurfaced in an update) that are known to cause the precise problems with slow loading you are referring to). Many are listed in one of the doc files for DXLabSuites. If you read that and disable those programs from running, you may find the problem is solved.

I had it here, and since I disabled some of the 'suggested offenders', I have not seen the slowness since and it's been nearly a year.

73, N0AN
Hasan


On Tue, Nov 23, 2021 at 10:44 AM Tony Dixon G4CJC <tdxio@...> wrote:
Since last week DXKeeper is logging calls so slowly as to make working anything very tedious. It can take up to 40 seconds from pressing the log pop up to the callsign appearing at the top of my DXKeeper list.
It starts ok but gradually gets slower and slower. I've removed all AV ware and stopped eventually everything except DXKeeper. 
I feel the cause is W11 Insider preview. I'm inclined to persist. Anyone else who has similar problems who can advise please feel free to do so. 
73
Tony G4CJC


DXKeeper running very slowly

Tony Dixon G4CJC
 

Since last week DXKeeper is logging calls so slowly as to make working anything very tedious. It can take up to 40 seconds from pressing the log pop up to the callsign appearing at the top of my DXKeeper list.
It starts ok but gradually gets slower and slower. I've removed all AV ware and stopped eventually everything except DXKeeper. 
I feel the cause is W11 Insider preview. I'm inclined to persist. Anyone else who has similar problems who can advise please feel free to do so. 
73
Tony G4CJC


Pathfinder 5.3.3 is available

Dave AA6YQ
 

If you are using Window Defender Antivirus (Windows 10), update it to its latest malware definition in

<https://www.microsoft.com/en-us/wdsi/definitions>

before installing or upgrading to PropView Pathfinder 5.3.3


This release

- gracefully handles the arrival of new directives when a previous directive is still in progress (tnx to Paul W2ECK and Jose
N4BAA)

- compensates for recent QRZ changes to nickname rendering (tnx to Andy K0AF and Jose N4BAA)


Notes:

1. Update your firewall and anti-malware applications to consider this new version of Pathfinder to be "safe"

Virus total: 3 of 66 engines detected malware

Jotti: 0 of 13 engines detected malware

Microsoft Security Intelligence: no malware detected


2. If this upgrade doesn't work correctly, see the "After an Upgrade" section of
<http://www.dxlabsuite.com/dxlabwiki/ApplicationStoppedWorking>


3. After upgrading, to revert to the previous version of Pathfinder, see
<http://www.dxlabsuite.com/dxlabwiki/RevertApplicationVersion>


Pathfinder 5.3.3 is available via the DXLab Launcher and via

<www.dxlabsuite.com/download.htm>

73,

Dave, AA6YQ


Re: improved support for the Russian District Award

 

Dave, 

Thank you for your ongoing and forward thinking work around managing QSO's real time with good informaition.

Mike
KM2B

5001 - 5020 of 209531