Date   

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


improved support for the Russian District Award

Dave AA6YQ
 

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: Skimmer Spots Overwriting SOTA Spots

 

Like I said, I learn something new every day, thanks.  
--
Bob AF9W
DXLab user since 2011


Re: importing adif from RumlogNG to Dxkeeper

Dave AA6YQ
 

+ AA6YQ comments below

I already have the user-defined item 0 set to Pota and its style to Alphanumeric, so all good there. So each time I import a pota adif I will need to chance the rum log userfield 1 to the Dxkeeper user-defined item- 0

+ Correct. DXKeeper could be extended to enable the user to specify an ADIF tag for each user-defined item so that importing that tag would route the information accordingly; this would eliminate the need for manually editing the ADIF file before importing. I've added this to DXKeeper's enhancement list.

73,

Dave, AA6YQ


Re: importing adif from RumlogNG to Dxkeeper

Steve
 

I already have the user-defined item 0 set to Pota and its style to Alphanumeric, so all good there. So each time I import a pota adif I will need to chance the rum log userfield 1  to the Dxkeeper user-defined item- 0

Great thanks for the help.
Steve VE1SK


Re: importing adif from RumlogNG to Dxkeeper

Dave AA6YQ
 

+ AA6YQ comments below

<call:5>VE1SK <qso_date:8>20211120 <time_on:6>110159 <band:3>20m <freq:9>14.276000 <mode:3>SSB <rst_sent:2>59 <rst_rcvd:2>59 <app_rumlog_qsl:1>W <qsl_rcvd:1>N <qsl_sent:1>R <dxcc:1>1 <cqz:1>5 <ituz:1>9 <cont:2>NA <comment:53>FN84EU (Lat: 44.867094º Long: -63.623812º Alt: 31m) <app_rumlog_power:9>Mid Power <eqsl_qsl_rcvd:1>N <eqsl_qsl_sent:1>N <lotw_qsl_rcvd:1>N <lotw_qsl_sent:1>N <pfx:3>VE1 <clublog_qso_upload_status:1>M <app_rumlog_userfield_1:6>ve1234 <app_rumlog_colorcode:1>2 <eor>

+ Thanks. On the "User Items" tab of DXKeeper's Configuration window, set user item 0's Caption to POTA, and its Style to Alphanumeric.

+ Then open the ADIF file with a text editor, and change all occurrences of

app_rumlog_userfield_1

in that ADIF file to

app_dxkeeper_user_defined_0

+ When you import this modified file into DXKeeper, the information in

app_rumlog_userfield_1

+ will appear in DXKeeper's user-defined item 0.

73,

Dave, AA6YQ


Re: importing adif from RumlogNG to Dxkeeper

Steve
 

<call:5>VE1SK <qso_date:8>20211120 <time_on:6>110159 <band:3>20m <freq:9>14.276000 <mode:3>SSB <rst_sent:2>59 <rst_rcvd:2>59 <app_rumlog_qsl:1>W <qsl_rcvd:1>N <qsl_sent:1>R <dxcc:1>1 <cqz:1>5 <ituz:1>9 <cont:2>NA <comment:53>FN84EU (Lat: 44.867094º  Long: -63.623812º Alt: 31m)  <app_rumlog_power:9>Mid Power <eqsl_qsl_rcvd:1>N <eqsl_qsl_sent:1>N <lotw_qsl_rcvd:1>N <lotw_qsl_sent:1>N <pfx:3>VE1 <clublog_qso_upload_status:1>M <app_rumlog_userfield_1:6>ve1234 <app_rumlog_colorcode:1>2 <eor>

hope this helps


Re: importing adif from RumlogNG to Dxkeeper

Joe Subich, W4TV
 

Send it directly to Dave at "aa6yq@..."

73,

... Joe, W4TV

On 2021-11-22 4:16 PM, Steve via groups.io wrote:
I can't seem to upload the adif file that contains the 2 test calls


Re: importing adif from RumlogNG to Dxkeeper

Dave AA6YQ
 

I can't seem to upload the adif file that contains the 2 test calls

+ Please open the ADIF file with a text editor (e.g. Notepad), copy the text representing a single ADIF record, and post that text here.

73,

Dave, AA6YQ


Re: importing adif from RumlogNG to Dxkeeper

Steve
 

I can't seem to upload the adif file that contains the 2 test calls


Re: Skimmer Spots Overwriting SOTA Spots

Dave AA6YQ
 

@ AA6YQ comments below

When there isn't much DX to chase I like to chase SOTA activators. I have cluster.sota.org.uk set as a spot source along with VE7CC. I only accept Skimmer spots from WA, OR, ID, and BC and I do so to see DX stations that show up on Skimmer before someone from NA-W spots them. I understand how SC combines spots given the time and frequency settings. When I get a spot from the SOTA cluster it shows up in a filter I have based on the Network item.

+ A Spot Database Entry's Network field contains the name of the spot source that most recently contributed information to that Entry. Why does your filter reference this field?

**I was looking for a way to distinguish SOTA spots. There is a telnet link to SOTA spots and I was using the network name for that link. However, I understand why that was the wrong way to do it.

+ What is the objective of your filter?

**The objective of my filter was to isolate SOTA spots from other spots when I just want to chase SOTA . I also jump between a SOTA filter and a Needed DX filter to watch what is going on.

However, if a Skimmer spot comes in for the same station via VE7CC, the SOTA spot is overwritten and the SOTA spot disappears from my filter.

+ Information from a new spot is added to existing information; "over-writing" only occurs when a subsequent spot contains updated information, e.g. a new QSX frequency or a (hopefully) corrected grid square.

** Realizing that the Notes fields are not overwritten but additive I created a different filter using "Notes Like "?#*/*" AND <AGEFILTER> AND <MODEFILTER>" which seems to be doing a good job of isolating the SOTA spots with summit information from RBN spots.

@ SpotCollector recognizes SOTA tags in spot notes, extracts them, and places them in each Spot Database Entry's SOTA field. You can make this field visible in the Spot Database Display. To see all Entries that specify a SOTA tag, you can use

LEN(SOTA)>0

@ instead of

Notes Like "?#*/*"

@ You can use the SOTA field to assemble a "SOTA Need" filter, e.g.

SOTA in ('W7A/CS-014', 'GM/CS-121',' GW/SW-016')

@ Similar support is provided for POTA and WWFF.

73,

Dave, AA6YQ


Re: Skimmer Spots Overwriting SOTA Spots

 

On Sun, Nov 21, 2021 at 11:47 AM, Dave AA6YQ wrote:
**AF9W comments below:
+ AA6YQ comments below

When there isn't much DX to chase I like to chase SOTA activators. I have cluster.sota.org.uk set as a spot source along with VE7CC. I only accept Skimmer spots from WA, OR, ID, and BC and I do so to see DX stations that show up on Skimmer before someone from NA-W spots them. I understand how SC combines spots given the time and frequency settings. When I get a spot from the SOTA cluster it shows up in a filter I have based on the Network item.

+ A Spot Database Entry's Network field contains the name of the spot source that most recently contributed information to that Entry. Why does your filter reference this field?
**I was looking for a way to distinguish SOTA spots.  There is a telnet link to SOTA spots and I was using the network name for that link.  However, I understand why that was the wrong way to do it.  
+ What is the objective of your filter?
**The objective of my filter was to isolate SOTA spots from other spots when I just want to chase SOTA .  I also jump between a SOTA filter and a Needed DX filter to watch what is going on.  
However, if a Skimmer spot comes in for the same station via VE7CC, the SOTA spot is overwritten and the SOTA spot disappears from my filter.

+ Information from a new spot is added to existing information; "over-writing" only occurs when a subsequent spot contains updated information, e.g. a new QSX frequency or a (hopefully) corrected grid square.
** Realizing that the Notes fields are not overwritten but additive I created a different filter using "Notes Like "?#*/*" AND <AGEFILTER> AND <MODEFILTER>" which seems to be doing a good job of isolating the SOTA spots with summit information from RBN spots.  

** All is good now.  I really love your software, it is amazing.  I learn something new every time I use it.  

73,

Dave, AA6YQ

 
--
Bob AF9W
DXLab user since 2011


Re: importing adif from RumlogNG to Dxkeeper

Dave AA6YQ
 

+ AA6YQ comments below

I am experimenting with importing adif file from my iPad using RumlogNG . I am going to us this for Pota. the issue that I am having, I have both Dxkeeper userDefine 0 and Rumlog user defined 1 setup for Pota. when I import the adif file in to DXkeeper I can't find the pota info from rum log. I have checked the file with ADIF master and it is there but how do I get the info into to the user defined #.

+ Please post an example of an ADIF record exported by RumlogNG that specifies a POTA code.

73,

Dave, AA6YQ


importing adif from RumlogNG to Dxkeeper

Steve
 

I am experimenting with importing adif file from my iPad using RumlogNG . I am going to us this for Pota. the issue that I am having, I have both Dxkeeper userDefine 0 and Rumlog user defined 1 setup for Pota. when I import the adif file in to DXkeeper I can't find the pota info from rum log. I have checked the  file with ADIF master and it is there but how do I get the info into to the user defined #. I have been away for the radio for a couple of years, so getting my head back in the software.. lol

Thanks Steve VE1SK

5041 - 5060 of 209558