Thanks, Dave! I'll assume that you'll be implementing Q65 support in the same way you have implemented support for the other ADIF
submodes; please let me know when that's been completed so that I can inform the DXLab user community. Enjoy your diving!

DXLab users: please hold off on submitting Q65 QSOs to eQSL until eQSL has been updated to accept this new mode.

73,

Dave, AA6YQ

+ AA6YQ comments below

I just got WSJTX set up to directly interface with Spot Collector. I like it - it's slick. One quibble I have - I've noticed that with audio alarms in SpotCollector set to Need & Filtered, I'm getting alarms for stations I directly hear in WSJTX (expected), but also for stations that the stations I'm directly hearing are working.

+ Correct.

E.g., I'll get an audio alarm for ZL4AS, but when I look at the WSJTX Band Activity window, ZL4AS only shows up as being worked by stations I'm hearing (in other words, ZL4AS only shows up on the left-hand side of QSOs, not the right-hand side of QSOs). The net effect is an alarm that tells you "hey, they're out there on the air, but you can't work them right now".

+ The situation you describe is identical to a spot from the DX Cluster: there's no guarantee that you can hear that station. The fact that the station is QRV on the spotted frequency and mode is useful information to the earnest DXer.

Is there a way to not alarm on calls on the "left-hand side" of WSJTX activity?

+ Yes: a Spot Database Entry's ActualSNR field is only populated if WSJT-X has reported decoding that Entry's callsign. See the first table and first screenshot in

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

I note that in the Spot Collector list, stations that I *want* alarmed if they're needed have my call as the Source of the spot.
The stations I don't want alarmed (the ones on the left-hand side of WSJTX activity) show the call of the station I'm actually hearing. Is there a way to use this to filter them out of the alarms, and if so, would it be possible to add a checkbox to include this in the alarm trigger expression?

+ A Spot Database Entry's Source field contains the callsign from which the most recent spot of that Entry's callsign has been received. If your instance of WSJT-X decodes P5DX on 20m FT8, the Spot Database Entry will specify your callsign as the Source, but if I then spot P5DX on 20m FT8 via the DX cluster, the Source field in the Spot Database Entry for P5DX will be updated to AA6YQ. Thus

Source='NJ8J'

is not a reliable way to identify Spot Database Entries for active stations your instance of WSJT-X has decoded; instead, use

ActualSNR>-100

+ You can incorporate this term into the expression that governs your audio alarm.


BTW, I've noticed that it's a bad idea to use RBN as a spot source while using WSJTX unless you have a fairly chunky processor. Mine runs a Core 2 Duo 3000Mhz, and with RBN turned on as a spot source, it was taking most of a full minute to get from telling WSJTX to log a QSO, and that QSO actually making it into DXKeeper.

+ You don't so how much RAM is available, but that sounds way too long, Take a look at

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

73,

Dave, AA6YQ

I just got WSJTX set up to directly interface with Spot Collector. I like it - it's slick. One quibble I have - I've noticed that with audio alarms in SpotCollector set to Need & Filtered, I'm getting alarms for stations I directly hear in WSJTX (expected), but also for stations that the stations I'm directly hearing are working. E.g., I'll get an audio alarm for ZL4AS, but when I look at the WSJTX Band Activity window, ZL4AS only shows up as being worked by stations I'm hearing (in other words, ZL4AS only shows up on the left-hand side of QSOs, not the right-hand side of QSOs). The net effect is an alarm that tells you "hey, they're out there on the air, but you can't work them right now".

Is there a way to not alarm on calls on the "left-hand side" of WSJTX activity? I note that in the Spot Collector list, stations that I *want* alarmed if they're needed have my call as the Source of the spot. The stations I don't want alarmed (the ones on the left-hand side of WSJTX activity) show the call of the station I'm actually hearing. Is there a way to use this to filter them out of the alarms, and if so, would it be possible to add a checkbox to include this in the alarm trigger expression?



BTW, I've noticed that it's a bad idea to use RBN as a spot source while using WSJTX unless you have a fairly chunky processor. Mine runs a Core 2 Duo 3000Mhz, and with RBN turned on as a spot source, it was taking most of a full minute to get from telling WSJTX to log a QSO, and that QSO actually making it into DXKeeper.

Ben
--
Ben Coleman nj8j@...
"I love the way Microsoft follows standards. In much the
same manner that fish follow migrating caribou."
Paul Tomblin

+ AA6YQ comments below

SKCC Logger puts the QSO partner's SKCC number in a SKCC tag (e.g. <SKCC:5>1817T).


When importing this ADIF file to DXKeeper, I want the value in the SKCC tag to go into APP_DXKeeper_USER_DEFINED_6.

Is there a way to specify such a mapping for imports?

+ Yes: On the Configuration window's "User Items" tab,

1. set the Caption for user item #6 to

SKCC

2. check the ADIF box for user item #6.


+ This capability is described here:

https://www.dxlabsuite.com/dxkeeper/Help/Configuration.htm#User%20Items%20tab

73,

Dave, AA6YQ

Ahhh I see what I might have forgotten.. will check settings in internet explorer 

OK Disregard one of the TLS settings was uncheck... ahhh how fast we forget.. 
Jim K3ybn

Dave et.al. I am again getting the dreaded 12157 error.  I recognize what it is and verified it by looking in the error log. Something strange however. I can go to the LOTW web site and log in with the exact password I loaded into the DxKeeper QSL Configuration page on the LOTW tab.  so what gives. Is there something I missed here? I see no other settings. 

Jim K3YBN

In case anyone imports QSO data from Ham Radio Deluxe logbook:

- I investigated why some QSO's exported from HRD logbook (latest v6.7.0.323) caused the J00aa locator when imported into DXKeeper.
- I found that the ADI file exported from HRD logbook contains Lat/Lon = "00.000" when there is no data for Lat/Lon in QRZ (callbook used).
- My experience was the QRZ xml subscription data but I suppose it could occur with other callbook data sources where there is no Lat/Lon specified.
- I opened a case with HRD and they agreed that the ADI should not export "00.000" and it should be fixed in a future version.

--
73, Norm/KC1BMD

Dave,

Up to this point in time, eQSL.cc has required QSOs made in "ADIF Submodes" like FT8 and FT4 to be submitted to eQSL.cc as Modes, e.g.

<MODE:3>FT8

and

<MODE:3>FT4

despite the fact that their representation in ADIF are

<MODE:4>MFSK <SUBMODE:3>FT8

and

<MODE:4>MFSK <SUBMODE:3>FT4

respectively.


Jay KA9CFD reports that eQSL is rejecting his submission of a QSO made with Q65, and your volunteer F6DKQ respond to his query via email (appended below) by stating that Q65 QSOs must be submitted with

<MODE:4>MFSK <SUBMODE:3>Q65

Is this correct? If so, which "ADIF Submodes" must be submitted as Modes, and which must be submitted as Submodes?

73,

Dave, AA6YQ


----- Forwarded Message -----
From: "support1@..." <support1@...>
To: "ka9cfd@..." <ka9cfd@...>
Sent: Friday, April 23, 2021, 11:01:03 AM UTC
Subject: uploading mode Q65 contacts (Lang:EN)

HI,


The webmaster has already been noticed, I can't tell you more


if you upload qso's as MFSK/Q65, they will be accepted, only the manual entry is impossible


Q65 is not a mode but a submode.



73,

F6DKQ

Support Volunteer


At 10:41 23-Apr-2021 you wrote:

I have several mode Q65 contacts that I want to upload to eQSL. Please advise when this mode will be accepted. The ADIF committee has approved this mode now. Thanks.(Please do not delete or change this [TRACKID=EQVHU330221D] so we can track our conversation!)(Replying to ka9cfd@...)

I forwarded an email I had received from eQSL to you Dave. I dont know much more than that. When I try and upload the Q65 contacts in DXKeeper to eQSL, I get a eQSL problem report back stating Bad Mode:Q65.

Jay KA9CFD

@ AA6YQ comments below

I have been using the “Identifying Special Callsigns” feature (http://dxlabsuite.com/spotcollector/Help/ConfigurationSpecialCallsigns.htm) of SpotCollector with good success, but I wonder if there is some beneficial additional functionality available that I am missing.

I would like SC to display the callsigns of CWops members that I have yet to work on a given band, but only for the CW mode, in pursuit of CWops awards, along with any spots relevant to my DXCC or Challenge objectives without regard to band or mode.

Using the CWops roster as the Leaderboard special callsign list, I can display spots for all CWops members on unworked bands along with spots needed for DXCC or Challenge objectives, but the spot database display shows this for all modes and not just CW. So, in the case of CWops members, I end up seeing many spots for modes that are not of interest.

If I invoke the Mode filter and set it for CW, then SC displays only the needed entries for CW, which works fine for the CWops awards, but I will miss other desirable entries such as an ATNO on FT8.

The ideal solution would be to allow me to further filter the Leaderboard spot displays by mode so that it contributes only the CWops counters that I need to the display, in conjunction with the display of other spots I need for DXCC and Challenge goals regardless of mode.

Is there a way to do this in the existing program?

+ Yes. Assuming that the tag you've specified for CWops members in the "Special Callsign List" is

cwops

+ use this SQL expression

<NEEDFILTER> or ((TAGS like '*<cwops>*') and (MODE='CW'))


That doesn't solve the problem, which was to show only CWOps members *on CW, who have not been worked before on CW* (but also show other stations who are Needed on other modes).

@ The stated desire is "display the callsigns of CWops members that I have yet to work on a given band, but only for the CW mode"

I can't think of any way to do it with SpotCollector's current capabilities....

@ On the Configuration window's "Spot Database" tab, check the Controls panel's "Maintain DXCC entity-band-mode fields" box, and then click the Recomputation panel's Recompute button.

@ Then use this SQL expression:

<NEEDFILTER> or ((TAGS like '*<cwops>*') and (MODE='CW') and (BandModeWorked='N'))

@ This will limit the display of active CWOPs stations (not otherwise needed) to those that haven't been worked in CW on the spotted band.

@ Note that enabling the "Maintain DXCC entity-band-mode fields" option will increase SpotCollector's resource consumption, as it will more frequently query the log file in order to keep each Spot Database Entry's BandModeWorked field up to date.

73,

Dave, AA6YQ

On Fri, Apr 23, 2021 at 5:48 PM Bob AF9W <af9w@...> wrote:

I am looking to get a new computer for my shack. Currently I use a Thinkpad Laptop with an Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz with 2 cores, 16Gb of Memory, and an Intel HD Graphics on board. My usual software suite is Win4K3Suite with bandscope, DXLab Suite with everything but Warbler running and VE7CC. I may also run WSJT-X and CW Skimmer connected to the I/Q output of my KX3. The issue I run into is CW Skimmer seems to run out of cycles quickly. Without CW Skimmer CPU usage averages about 50%. Once CW Skimmer starts it goes to 100% and Skimmer can’t keep up with screen refresh. My question is would people suggest more i5 cores or should I go with i7? I am asking here because people on this forum run DXLab Suite and have similar workloads to mine.

I would go Ryzen these days... possibly 3700x.

That said; don't be disappointed if it doesn't resolve the CW Skimmer
issue. I've found it unusable recently when there are other apps
running (some seem to affect it more than others). It (skimmer) shows
100% "decoding capacity used", and the waterfall stops, but the actual
CPU usage (observed with Process Explorer) is nowhere near 100%. It
seems the skimmer is competing with the other apps for some resource,
but I've not been able to identify what it is. This happens on my new
3700x system as well as my old 2nd Gen Core-i7, which used to run
skimmer and the other apps with no problem. I think something changed
in Windows, but I don't know what.

73/GL!

~iain / N6ML

+ AA6YQ comments below

I am looking to get a new computer for my shack. Currently I use a Thinkpad Laptop with an Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
with 2 cores, 16Gb of Memory, and an Intel HD Graphics on board. My usual software suite is Win4K3Suite with bandscope, DXLab Suite
with everything but Warbler running and VE7CC. I may also run WSJT-X and CW Skimmer connected to the I/Q output of my KX3. The
issue I run into is CW Skimmer seems to run out of cycles quickly. Without CW Skimmer CPU usage averages about 50%.

+ 50% CPU consumption is quite high. Ignoring CPU Skimmer, which applications are the top 5 consumers of CPU cycles?

73,

Dave, AA6YQ

Hi Dave

I got it going. so case is solved. Tnx Dave NU4N

--
73's de NU4N Dave

+ AA6YQ comments below

For the USA-CA award that I am pursuing, is there a way/place where to indicate the already submitted, accepted, verified counties as iI do, for example for IOTA, WAS, WAZ. etc.?

+ No, support for the USA-CA award is limited to generating a progress report.

73,

Dave, AA6YQ

+ Please place your log file (pathname specified in the "Log file" panel on the Configuration window's log tab) in a zip archive, attach the zip archive to an email message, and send the message to me via

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ

+ AA6YQ comments below

Seems I have joined the problems with Version 16.1.0 club. I updated my DXK file to Vs 16.1.0. After a few minutes, it finally
opened but to a blank log page. The heading was "Vs 16.10 (no log opened) (K2SX). I tried opening it using an older smaller log
file (KM4FOC with only 16K QSOs) and it seemed to open OK. My K2SX file has 290K QSOs. Went back to try and open DXK with
K2SX.mdb and got the "log contains more fields than expected. Tis version is incapable of opening it. Probably can likely be
overcome by opening current version of DXK". I am also getting a note that "A new version of TQSL is available" which I
acknowledged but did nothing with. It seems like some others are having similar problem but I don't see a fix for this yet.
Suggestions?

+ Please place your K2SX log file in a zip archive, attach the zip archive to an email message, and send the message to me via

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ

+ AA6YQ comments below

Started WW and selected PSK31.
noticed the tones coming out seemed low freq, less than 400Hz, as though LF hum present.
much different from previous operation as I recall.

Disconnected everything from the PC and the tones from the PC speaker were still Low freq thought I might have an open ground etc. checked all connections OK Tone test with the PC only sounded normal.

Started Multipsk for comparison and the PSK31 tones sounded clean and in the 2k+ freq range as expected.
Is the PSK LF sounding tones normal for WW or am I missing something ?

+ The last update to WinWarbler (9.3.7) was released back in February, so any change in behavior is most likely the result of a change in your hardware or software. As a first step, terminate WinWarbler, and direct the Launcher to restore WinWarbler's settings from the Workspace you maintain with "known working settings".

73,

Dave, AA6YQ