Date   

Commander + CW Skimmer to Commander - strange behaviour

Wolf, DK1FW
 

Dave,

For pile-up situations I have been using CW-Skimmer together W3OA's CW-Skimmer-to-Commander. For years this combination has worked flawlessly.

Since adding WSJT support to my DXLab configuration I observe a stange behaviour.
This only occurs, when I have previously switched to FT8 (through WW) prior to CW, even if JTDX and JTAlert have not yet been started.

When switching modes (generally through WW) I use WW startup macros, which control some mode specific settings of my FT-5000.
For WSJT modes the PSK startup macro puts VFO-A (RX) into SSB while VFO-B (TX) is switched to PSK.

When switching to CW (e. g. after FT8)  the corresponding CW startup macro sets both VFOs to CW identically and de-activates Split.
After then  bringing  up CW-Skimmer and CW-Skimmer-to-Commander the stuation is as follows:
With Split de-activated clicking into the Skimmer waterfall moves VFO-A to that frequency in CW-mode (as it should).
When in Split cklicking into the CW Skimmer waterfall moves VFO-B to that frequency but puts VFO-B into PSK Mode.

I can get out of this situation by (only) terminating Commander. After starting Commander again and switching the radio to CW behaviour is normal again. Clicking into the Skimmer waterfall moves VFO-B to that frequency in CW as it should.

So it looks like Commander somehow remembers the association of VFO-B and PSK even if VFO-B has been switched to CW.

I can live with that situation by my technical mind is puzzled.

73 de Wolf, DK1FW


Re: QSOs Not Appearing on WAZ Report

Dave AA6YQ
 

+ AA6YQ comments below

While comparing the WAZ report produced by the DXKeeper CQ WAZ Check Progress function, I discovered two QSOs that have been verified by the ARRL and have been marked as verified in my DXKeeper log but do not show up as confirmed in the WAZ report DXKeeper generates.

+ Neither the ARRL nor CQ provide a programmatic interface that would enable DXKeeper to determine that a QSO has been granted WAZ award credit, so in this case you must manually update each QSO to reflect the granting of WAZ award credit.

What must I do to have these two QSOs properly reported in the WAZ report so I can track my WAZ status?

+ With the QSL panel visible on the Main window's "Log QSOs" tab, select one of the two QSOs in the Log Page Display, set the QSL panel's "WAZ vfy" selector to 'V', and then click the Save button above the Log Page Display. Repeat this process for the second QSO.

+ Note that if you use DXKeeper to generate a WAZ submission, then after the QSOs in that submission have been granted WAZ award credit, you would be able to set their "WAZ vfy" items to 'V' en masse. See

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

73,

Dave, AA6YQ


QSOs Not Appearing on WAZ Report

Barry Priddy
 

While comparing the WAZ report produced by the DXKeeper CQ WAZ Check Progress function, I discovered two QSOs that have been verified by the ARRL and have been marked as verified in my DXKeeper log but do not show up as confirmed in the WAZ report DXKeeper generates.

What must I do to have these two QSOs properly reported in the WAZ report so I can track my WAZ status?

Barry Priddy - K5VIP


Re: N1MM to DXKeeper Gateway multiple county issue

Dave AA6YQ
 

The (not yet publicly released) next version of the N1MM-DXKeeper Gateway now correctly handles the situation in which N1MM logs a QSO as multiple QSOs, such as a QSO in a State QSO party whose exchange is GALL/HAML/SALI/WHIT :

<http://www.dxlabsuite.com/N1MM-DXKeeper/N1MM-DXKeeper%20Gateway%20116.jpg>

Thanks to all for the help with understanding this scenario!

73,

Dave, AA6YQ


Re: How to disable FTx audible alarms (only) ??

Dave AA6YQ
 

+ AA6YQ comments below

i do not want to display or hear any audible alarms for FT4/FT8 spots.

+ I assume that you mean "I want to hide Spot Database Entries for stations operating in FT4 and FT8, and do not want an audio alarm when Spot Database Entries for stations operating in FT4 and FT8 are first created".

i have unchecked the boxes for the mode on SC's MODE filters, which seems to fix displaying those modes, but that does NOT seem to stop the audible alarms from going off for FTx...

+ Correct. For flexibility, SpotCollector provides you with independent control of what's visible in the Spot Database Display and what is announced. See

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


how to mute these (and these only) off??

i guess i would have thought that the Mode Filter settings would have done both.

+ That would be inflexible if it were the only option. For example, some ops keep the Spot Database Display filtered to display all "needed" active stations, but configure audio alerts for "needed" active stations on 6m only.

+ Reviewing the documentation eliminates guesswork. The documentation for audio alerts is here:

<https://www.dxlabsuite.com/spotcollector/Help/ConfigurationAudio.htm>

+ To configure audio alerting to match your filtering (Band, Mode, Origin, Continent, eQSL, LOTW) of the Spot Database Display, set the "Audio Alarm trigger" panel to "Needed & Filtered" on the "Audio Alarm" tab of SpotCollector's Configuration window.

73,

Dave, AA6YQ


Re: How To Turn Off Automatic Real-Time LOTW QSO Logging?

Dave AA6YQ
 

+ AA6YQ comments below

I'm sure I flipped some bit somewhere in my DXKeeper configuration, but if I did I can't find it. My QSO's are being sent to LOTW in real time. I get this popup after each Q.

The only place I can find in the documentation for this to be configured is in DXKeeper's QSL config for LOTW. But it seems not to be checked here (see below).

+ Screenshots are not conveyed here.

Suggestions on where to look?

+ The "Upload each QSO logged via the Capture window to LoTW" option on the "QSL Configuration" window's LoTW tab only governs automatic uploading when you're logging a QSO via the Capture window.

+ The "upload to LoTW when logging" option in the "QSO Info" panel on the Log tab of WinWarbler's Configuration window governs automatic uploading when you're logging via WinWarbler's Main window.

+ The LoTW checkbox in the WSJT-X panel on the "Spot Sources" tab of SpotCollector's Configuration window governs automatic uploading when you have WSJT-X directly interoperating with DXLab.

+ The "Instruct DXKeeper to upload each new QSO to LoTW" checkbox in the "DXLab DXKeeper" sub-section of the Logging section of JT-Alert's Settings window governs automatic uploading when you're logging QSOs via JT-Alert.

+ In summary, the application doing the logging generally controls whether or not automatic uploading to LoTW is enabled. Support for automatic uploading to Club Log and eQSL is similar.

73,

Dave, AA6YQ


How to disable FTx audible alarms (only) ??

bob-w9zv
 

i do not want to display or hear any audible alarms for FT4/FT8 spots.

i have unchecked the boxes for the mode on SC's  MODE filters, which seems to fix displaying those modes,
but that does NOT seem to stop the audible alarms from going off for FTx... 

how to mute these (and these only) off?? 
i guess i would have thought that the Mode Filter settings would have done both.

 


How To Turn Off Automatic Real-Time LOTW QSO Logging?

 

Hi, 
I'm sure I flipped some bit somewhere in my DXKeeper configuration, but if I did I can't find it.  My QSO's are being sent to LOTW in real time.  I get this popup after each Q. 



The only place I can find in the documentation for this to be configured is in DXKeeper's QSL config for LOTW.    But it seems not to be checked here (see below).



Suggestions on where to look?

Thanks in advance,
73, Greg, KM5GT


Re: DXK: LotW Sent/Rcvd Status for FT4

Dave AA6YQ
 

+ AA6YQ comments below

just the one.

+ OK. Please place your log file (pathname is specified in the Log panel at the top of the Configuration window's Log tab) in a zip archive, and attach the zip archive to an email message, along with the LotW_UpdateSingle_ADI.txt file. Then send the email message to me via

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ


Re: DXK: LotW Sent/Rcvd Status for FT4

Larry Koziel
 

just the one.

Larry K8MU


Re: DXK: LotW Sent/Rcvd Status for FT4

Dave AA6YQ
 

Thanks for the report below.

In the Filter panel textbox at the bottom of the Main window's Log QSOs tab, please type

JA6FIO

into the Filter panel's textbox, and then click the Filter panel's Call button.

How many QSOs with JA6FIO on 2020-10-14 at 22:00:00 are shown in the Log Page Display?

73,

Dave, AA6YQ

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Larry Koziel
Sent: Wednesday, October 21, 2020 5:11 PM
To: DXLab@groups.io
Subject: Re: [DXLab] DXK: LotW Sent/Rcvd Status for FT4

This is what I got back in LotW_UpdateSingle_ADI.txt:

ARRL Logbook of the World Status Report

Generated at 2020-10-21 21:05:31

for k8mu

Query:

CALL: JA6FIO

OWNCALL: K8MU

BAND: 20M

QSL ONLY: NO

QSO SINCE: 2020-10-14 22:00:00

QSO UNTIL: 2020-10-14 22:00:00

QSO RX SINCE: (empty)



<PROGRAMID:4>LoTW

<APP_LoTW_LASTQSORX:19>2020-10-15 00:22:03



<APP_LoTW_NUMREC:1>1



<eoh>



<APP_LoTW_OWNCALL:4>K8MU

<STATION_CALLSIGN:4>K8MU

<CALL:6>JA6FIO

<BAND:3>20M

<FREQ:8>14.08224

<MODE:4>MFSK

<SUBMODE:3>FT4

<APP_LoTW_MODEGROUP:4>DATA

<QSO_DATE:8>20201014

<APP_LoTW_RXQSO:19>2020-10-15 00:22:03 // QSO record inserted/modified at LoTW

<TIME_ON:6>220000

<APP_LoTW_QSO_TIMESTAMP:20>2020-10-14T22:00:00Z // QSO Date & Time; ISO-8601

<QSL_RCVD:1>Y

<QSLRDATE:8>20201019

<APP_LoTW_RXQSL:19>2020-10-19 00:49:13 // QSL record matched/modified at LoTW

<DXCC:3>339

<COUNTRY:5>JAPAN

<APP_LoTW_DXCC_ENTITY_STATUS:7>Current

<PFX:3>JA6

<APP_LoTW_2xQSL:1>Y

<IOTA:6>AS-077

<GRIDSQUARE:6>QN13KF

<STATE:2>40 // Fukuoka-ken

<CNTY:4>4001 // Fukuoka-shi

<CQZ:2>25

<ITUZ:2>45

<eor>



<APP_LoTW_EOF>

Still no change in LotW_QSL_Sent (U) or LotW_QSL_Rcvd (R).

73,

Larry K8MU





<http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&utm_campaign=sig-email&utm_content=emailclient>


Re: DXK: LotW Sent/Rcvd Status for FT4

Larry Koziel
 

This is what I got  back in LotW_UpdateSingle_ADI.txt:

ARRL Logbook of the World Status Report

Generated at 2020-10-21 21:05:31

for k8mu

Query:

        CALL: JA6FIO

     OWNCALL: K8MU

        BAND: 20M

    QSL ONLY: NO

   QSO SINCE: 2020-10-14 22:00:00

   QSO UNTIL: 2020-10-14 22:00:00

QSO RX SINCE:  (empty)

 

<PROGRAMID:4>LoTW

<APP_LoTW_LASTQSORX:19>2020-10-15 00:22:03

 

<APP_LoTW_NUMREC:1>1

 

<eoh>

 

<APP_LoTW_OWNCALL:4>K8MU

<STATION_CALLSIGN:4>K8MU

<CALL:6>JA6FIO

<BAND:3>20M

<FREQ:8>14.08224

<MODE:4>MFSK

<SUBMODE:3>FT4

<APP_LoTW_MODEGROUP:4>DATA

<QSO_DATE:8>20201014

<APP_LoTW_RXQSO:19>2020-10-15 00:22:03 // QSO record inserted/modified at LoTW

<TIME_ON:6>220000

<APP_LoTW_QSO_TIMESTAMP:20>2020-10-14T22:00:00Z // QSO Date & Time; ISO-8601

<QSL_RCVD:1>Y

<QSLRDATE:8>20201019

<APP_LoTW_RXQSL:19>2020-10-19 00:49:13 // QSL record matched/modified at LoTW

<DXCC:3>339

<COUNTRY:5>JAPAN

<APP_LoTW_DXCC_ENTITY_STATUS:7>Current

<PFX:3>JA6

<APP_LoTW_2xQSL:1>Y

<IOTA:6>AS-077

<GRIDSQUARE:6>QN13KF

<STATE:2>40 // Fukuoka-ken

<CNTY:4>4001 // Fukuoka-shi

<CQZ:2>25

<ITUZ:2>45

<eor>

 

<APP_LoTW_EOF>

Still no change in LotW_QSL_Sent (U) or LotW_QSL_Rcvd (R).

73,

Larry K8MU

 


Re: DXK: LotW Sent/Rcvd Status for FT4

Dave AA6YQ
 

+ AA6YQ comments below

Some time ago I happened to notice that some QSOs that had been confirmed in LotW did not have that reflected in their status in DXK. I remember manually updated some QSOs, but I didn't really pay much attention to the details. Until now.

When I noticed this again, I began to investigate and found that this seemed to affect FT4 QSOs. When I checked LotW, I found 406 FT4 QSOs of which 304 were confirmed. DXK showed 395 QSOs but only 6 confirmed! I suspect that these 6 QSO records were ones I updated manually, but I'm not sure because I did that months ago and as I said I didn't really pay much attention back then.

I automatically log FT8/4 contacts to DXK via JTAlert and from there upload to LotW. I've found that LotW_QSL_Sent for the contacts LotW is showing as confirmed is "U" and not "Y", and LotW_QSL_Rcvd show as "R".

+ That means the QSOs were submitted to LoTW, but never updated to reflect acceptance by LoTW.

I've looked at my latest LotW_QSOs_ADI.txt and it shows acknowledgment of FT4 QSOs as well as for other modes but LotW_QSL_Sent shows them as "U". Likewise, I checked my latest LotW_QSLs_ADI.txt and found that only the FT4 QSLs did not have LotW_QSL_Rcvd changed from "R" to "Y".

What could be going on here? I haven't attempted to see if this happens for contacts in other modes, so is this specific to FT4? Is there a fix? And how do I go about correcting the status of hundreds of contact?

+ As a first diagnostic step, right click the Log Page Display entry for one of the FT4 QSOs whose "LoTW QSL Sent" item is set to 'U', and select "Update from LoTW" from the pop-up menu. What happens?

73,

Dave, AA6YQ


Re: N1MM to DXKeeper Gateway multiple county issue

Dave AA6YQ
 

* more AA6YQ comments below

Short of a "log n-QSOs" directive, you would need to buffer about
30 seconds worth of UDP messages (4 x 4 x 2 seconds) before sending
the log entries to DXKeeper to be sure that none are missed.

+ Fixed time intervals are unreliable. For whatever value you choose, someone's computer will under some circumstance take 1 second longer.

+ In the absence of a guaranteed reliable "end of transaction" indicator (e.g. "messages for all N QSOs have been sent"), the only recourse is to switch to a mechanism that doesn't cause incoming UDP messages to be dropped.

Using the gateway, I notice QSOs that are part of a multi-county group have the original copied exchange in the comment field, such as "GALL/HAML/SALI/WHIT". The four QSOs are logged in the same order as the counties in the comment. Single county QSOs have a blank comment. Maybe this could be used to distinguish them?

* I explained why that approach would be suboptimal in an earlier post:

"However, that would require making the Gateway aware that the current contest is a State QSO party, and making the Gateway know where to look for country abbreviations so it can count them. Dependencies like these would increase fragility; suppose N1MM starts generating multiple QSOs for QSOs on grid boundaries, for example. So I will redesign the next version of the Gateway to send QSOs to DXKeeper via TCP rather than via DDE."

<https://groups.io/g/DXLab/message/196903>

73,

Dave, AA6YQ


Re: spot collector not starting

Dave AA6YQ
 

+ AA6YQ comments below

GM all!
Lately Spot collector keeps failing to launch. I get two pop up windows one saying Spot collector failed to launch after 60 seconds and then another one 180 seconds.
Any help on this would be appreciated.
thanks, N4EK

+ See my response to your first post of this report:

<https://groups.io/g/DXLab/message/196874>

73,

Dave, AA6YQ


DXK: LotW Sent/Rcvd Status for FT4

Larry Koziel
 

Some time ago I happened to notice that some QSOs that had been confirmed in LotW did not have that reflected in their status in DXK. I remember manually updated some QSOs, but I didn't really pay much attention to the details. Until now.

When I noticed this again, I began to investigate and found that this seemed to affect FT4 QSOs. When I checked LotW, I found 406 FT4 QSOs of which 304 were confirmed. DXK showed 395 QSOs but only 6 confirmed! I suspect that these 6 QSO records were ones I updated manually, but I'm not sure because I did that months ago and as I said I didn't really pay much attention back then. 

I automatically log FT8/4 contacts to DXK via JTAlert and from there upload to LotW. I've found that LotW_QSL_Sent for the contacts LotW is showing as confirmed is "U" and not "Y", and LotW_QSL_Rcvd show as "R". I've looked at my latest LotW_QSOs_ADI.txt and it shows acknowledgment of FT4 QSOs as well as for other modes but LotW_QSL_Sent shows them as "U". Likewise, I checked my latest LotW_QSLs_ADI.txt and found that only the FT4 QSLs did not have LotW_QSL_Rcvd changed from "R" to "Y".

What could be going on here? I haven't attempted to see if this happens for contacts in other modes, so is this specific to FT4? Is there a fix? And how do I go about correcting the status of hundreds of contact?

73,

Larry K8MU


Re: spot collector not starting

N4EK Ed
 

GM all!
Lately Spot collector keeps failing to launch. I get two pop up windows one saying Spot collector failed to launch after 60 seconds and then another one 180 seconds.
Any help on this would be appreciated.
thanks, N4EK

--


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


Re: N1MM to DXKeeper Gateway multiple county issue

Mike - W1MI
 

On Wed, Oct 21, 2020 at 02:43 AM, Dave AA6YQ wrote:
+ AA6YQ comments below
Short of a "log n-QSOs" directive, you would need to buffer about
30 seconds worth of UDP messages (4 x 4 x 2 seconds) before sending
the log entries to DXKeeper to be sure that none are missed.

+ Fixed time intervals are unreliable. For whatever value you choose, someone's computer will under some circumstance take 1 second longer. 

+ In the absence of a guaranteed reliable "end of transaction" indicator (e.g. "messages for all N QSOs have been sent"), the only recourse is to switch to a mechanism that doesn't cause incoming UDP messages to be  dropped.

       73,

               Dave, AA6YQ

Using the gateway, I notice QSOs that are part of a multi-county group have the original copied exchange in the comment field, such as "GALL/HAML/SALI/WHIT".  The four QSOs are logged in the same order as the counties in the comment.  Single county QSOs have a blank comment.  Maybe this could be used to distinguish them?
73, Mike - W1MI


Re: N1MM to DXKeeper Gateway multiple county issue

Phil Deaver
 

Dave-
It's always more complicated than what you expect. As I understand it, in order to qualify for a county line station you must be a rover or an expedition station. The home station location we operated is located within 500 ft of the other county line so the organizer of the competition encouraged us to operate as a county line station. That turned out to be bad information. When the competition was set up it couldn't be configured as a county line station but we didn't know that at the time and gave out two counties to each QSO. (or maybe when we sent in the log we found out we didn't qualify as a county line station since we weren't a rover or an expedition). It was a mess. 
Phil WR7T


Re: N1MM to DXKeeper Gateway multiple county issue

Dave AA6YQ
 

+ AA6YQ comments below
Short of a "log n-QSOs" directive, you would need to buffer about
30 seconds worth of UDP messages (4 x 4 x 2 seconds) before sending
the log entries to DXKeeper to be sure that none are missed.

+ Fixed time intervals are unreliable. For whatever value you choose, someone's computer will under some circumstance take 1 second longer. 

+ In the absence of a guaranteed reliable "end of transaction" indicator (e.g. "messages for all N QSOs have been sent"), the only recourse is to switch to a mechanism that doesn't cause incoming UDP messages to be  dropped.

       73,

               Dave, AA6YQ

3121 - 3140 of 200001