Date   

Re: N1MM to DXKeeper Gateway multiple county issue

Joe Subich, W4TV
 

On 2020-10-20 7:13 PM, Dave AA6YQ wrote:
+ Each UDP message from N1MM in a county-line QSO scenario does
specify each county abbreviation, so the Gateway could be extended to
receive all of the expected UDP messages before directing DXKeeper to
log any of the QSOs. 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.
That would require that N1MM+ notify the gateway that "N" QSOs are to
be logged. The Gateway can not tell that there will be multiple QSOs
from examining any individual UDP (log QSO) message as each one will
contain only one county "token" just as it would potentially contain
only one grid square in the case of a Rover on a grid boundary in a
VHF contest.

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.

73,

... Joe, W4TV


On 2020-10-20 7:13 PM, Dave AA6YQ wrote:
+ AA6YQ comments below


When you log a multiple-county QSO with N1MM configured for a State QSO
Party contest, N1MM logs one QSO per county, but these multiple QSOs are
not conveyed to DXKeeper via the N1MM-DXKeeper Gateway for reasons that
are presently unknown.

Until the responsible defect is identified and corrected, please do not
use the N1MM-DXKeeper Gateway when employing N1MM to participate in a
State QSO Party. Instead, at the end of the contest, direct N1MM to export
an ADIF file containing the State QSO Party QSOs, and then direct DXKeeper
to import this file.
+ The N1MM-DXKeeper Gateway employs DDE to direct DXKeeper to log a QSO received from N1MM via UDP. Since UDP is a "no guarantee of delivery" protocol, Windows is evidently discarding the incoming UDP messages from N1MM reporting the 2nd, 3rd, or 4th county-line QSOs if the Gateway is in the middle of a DDE transaction conveying the 1st, 2nd, or 3rd county line QSO to DXKeeper.
+ Each UDP message from N1MM in a county-line QSO scenario does specify each county abbreviation, so the Gateway could be extended to receive all of the expected UDP messages before directing DXKeeper to log any of the QSOs. 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.
+ Until the next version of the Gateway is released, please do not use it in State QSO parties.
+ Hint to developers: A process in the middle of a DDE transaction is not likely the only scenario in which Windows will discard an incoming UDP message. UDP is fine for sending messages that won't cause failures if not delivered, like continuous frequency and mode reports from a transceiver. However, if a message must be delivered, either use TCP, or add a positive acknowledgement and timeout mechanism to your UDP-based protocol.
73,
Dave, AA6YQ


Re: N1MM to DXKeeper Gateway multiple county issue

HamApps Support (VK3AMA)
 

On 21/10/2020 10:13 am, Dave AA6YQ wrote:

+ Hint to developers: A process in the middle of a DDE transaction is not likely the only scenario in which Windows will discard an incoming UDP message. UDP is fine for sending messages that won't cause failures if not delivered, like continuous frequency and mode reports from a transceiver. However, if a message must be delivered, either use TCP, or add a positive acknowledgement and timeout mechanism to your UDP-based protocol. 

           73,

                Dave, AA6YQ


I'd tell you a UDP joke... but you might not get it.

de Laurie VK3AMA


Re: N1MM to DXKeeper Gateway multiple county issue

Dave AA6YQ
 

+ AA6YQ comments below
When you log a multiple-county QSO with N1MM configured for a State QSO Party contest, N1MM logs one QSO per county, but these multiple QSOs are not conveyed to DXKeeper via the N1MM-DXKeeper Gateway for reasons that are presently unknown.

Until the responsible defect is identified and corrected, please do not use the N1MM-DXKeeper Gateway when employing N1MM to participate in a State QSO Party. Instead, at the end of the contest, direct N1MM to export an ADIF file containing the State QSO Party QSOs, and then direct DXKeeper to import this file.

+ The N1MM-DXKeeper Gateway employs DDE to direct DXKeeper to log a QSO received from N1MM via UDP. Since UDP is a "no guarantee of delivery" protocol, Windows is evidently discarding the incoming UDP messages from N1MM reporting the 2nd, 3rd, or 4th county-line QSOs if the Gateway is in the middle of a DDE transaction conveying the 1st, 2nd, or 3rd county line QSO to DXKeeper.

+ Each UDP message from N1MM in a county-line QSO scenario does specify each county abbreviation, so the Gateway could be extended to receive all of the expected UDP messages before directing DXKeeper to log any of the QSOs. 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.

+ Until the next version of the Gateway is released, please do not use it in State QSO parties.

+ Hint to developers: A process in the middle of a DDE transaction is not likely the only scenario in which Windows will discard an incoming UDP message. UDP is fine for sending messages that won't cause failures if not delivered, like continuous frequency and mode reports from a transceiver. However, if a message must be delivered, either use TCP, or add a positive acknowledgement and timeout mechanism to your UDP-based protocol. 

           73,

                Dave, AA6YQ



 

 


Re: Sync LoTW

Dave AA6YQ
 

+ AA6YQ comments below

Thanks, Salvatore, that explains it. I knew the message about no new confirmations remains the same until a new confirmation is
found, but I wasn't aware that the date also remained the same until there is a change.
Thanks for the explanation. Glad it's not an issue.

+ The date and time shown beneath the "Sync LoTW QSLs" button is when LoTW last reported a new confirmation. When you invoke "Sync
LoTW QSLs", DXKeeper presents this date and time to LoTW, requesting to be informed of any new confirmations created after that date
and time. If LoTW has new confirmations to report, it includes the date and time of the most recently created confirmation to
DXKeeper, which then displays it beneath the "Sync LoTW QSLs" button.

+ The date and time shown beneath the "Sync LoTW QSOs" button work in a similar manner.

73,

Dave, AA6YQ


Re: Sync LoTW

w3qt_mike
 

Thanks, Salvatore, that explains it. I knew the message about no new
confirmations remains the same until a new confirmation is found, but I
wasn't aware that the date also remained the same until there is a change.
Thanks for the explanation. Glad it's not an issue.

73,
Mike, W3QT

-----Original Message-----
From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Salvatore Besso
Sent: Tuesday, October 20, 2020 10:23 AM
To: DXLab@groups.io
Subject: Re: [DXLab] Sync LoTW

Mike,

the "Sync LotW QSLs" date doesn't change if there are no LotW changes, for
example new confirmations but also data corrections. What does the text log
say at the end of the sync operation? If it says "there are no changes..."
or something similar, the sync date will not change and it will remain at
the last date where you've had changes.

73 de
Salvatore (I4FYV)


Test post

Larry Koziel
 

In two previous attempts to post about a problem, the posts never showed up. If this posts ok, I'll explain my problem.

Larry K8MU


Re: N1MM to DXKeeper Gateway multiple county issue

ve3ki
 

I spoke too soon about the sent exchange in my last paragraph. While the sent exchange other than serial numbers is not normally exported to ADIF by N1MM+, in the case of a Rover contest entry it is exported in a field called APP_N1MM_RoverQTH. If you edit the ADIF file exported from N1MM+ to change <APP_N1MM_RoverQTH: to <STX_STRING: , this should transfer the sent exchange county abbreviation into the tx info field in DXKeeper. You can then filter the DXKeeper log to show only contacts with a given STX_STRING field during the time of the contest, specify the corresponding tQSL station location and upload to LotW, repeating for each different STX_STRING value used during the contest.

73,
Rich VE3KI


On Tue, Oct 20, 2020 at 01:03 PM, ve3ki wrote:
Correct. If your contest entry category in N1MM+ is ROVER and you use the COUNTYLINE command to enter the location as the corner of DuPage, Kane, Kendall and Will counties (DUPG,KANE,KEND,WILL) and enter a single contact with W9IAU with the exchange GALL/HAML/SALI/WHIT, sixteen QSOs will automatically appear in the N1MM+ log, one for each of the 4x4 county combinations. The QSOs will be logged with times differing by two-second intervals, which means they might all be logged within the same clock minute, or they might be logged within two consecutive clock minutes if the 2-second increments happen to cause the minutes part of the time to roll over. Apart from the 2-second time differences, an internal database guid and the contents of the Exchange1 field, the contacts will be otherwise identical.

If you then export the log to ADIF and import that ADIF file into DXKeeper, all 16 contacts will be imported into the DXKeeper log. The rx info (SRX_STRING) field will contain the county abbreviation received from the other station. If you have not used the AD1C county conversion program and you want to record the other station's county in the county field in the DXKeeper log with the full county name, you will have to enter that information (you may be able to use the Advanced Sorts, Filters and Modifiers window to help with this). 

N1MM+ does not export the sent exchange to ADIF, so the tx info (STX_STRING) field in DXKeeper will be empty. If you wish, you can fill it in manually by referring to the sent exchange column in the Cabrillo file. If you wish to upload these contacts to LotW with the correct counties in the station information, you will have to separate out the contacts by individual sent exchange and use a separate tQSL station location for each county (sent exchange).

73,
Rich VE3KI


On Tue, Oct 20, 2020 at 10:57 AM, Scott Stembaugh wrote:
you have to tell N1MM that you are on a county line. I think you enter COUNTYLINE in the callbox before you make qsos. 

On Tue, Oct 20, 2020, 07:29 Mike - W1MI <aa1ar@...> wrote:
On Tue, Oct 20, 2020 at 04:00 AM, Phil Deaver wrote:
One more note on state QSO parties. This was true a few months ago and is probably still true (although I wasn't able to verify it with the station I worked this weekend. None of the callsigns on the QRZ page list an email address unfortunately). The station on the county line only gets credit for one contact while the contacting station gets credit for 2 or 3 or 4 QSOs. We found this out the hard way during the 7QP QSO party. We were told we would get double QSO points being on the county line, but that apparently was bad information. N1MM would only log one contact for the county line station with both counties in the report field. So it took us extra time to send out both counties info, we had many requests for repeats since it was a little unusual and we had to train some of the stations on how to input the two counties into N1MM. All of this slowed us down (quite a bit) and the only benefit to us was that our station was more desirable since it was a 2-fer to the calling station. So the result of this is that the calling station would have 2 QSOs into DXKeeper and LOTW while the called station would have 1 QSO. 

 Phil,
Looking at the last few paragraphs of https://n1mmwp.hamdocs.com/manual-supported/contests-setup/setup-qsop-contests/
you should have gotten multiple QSOs in your log for each contact.  Maybe something wasn't set up quite right...
73, Mike - W1MI


Re: Missing QSO's

Joe Subich, W4TV
 

Bill,

1) *BACK UP YOUR DXKEEPER LOG*
2) On the DXKeeper Import QSOs tab, make sure Duplicate checking
is enabled (check "check duplicates on import range +/- 1 minutes -
set to 1 minutes if not already set to 1 minute)
3) Import the WSJTX_LOG.adi file.

The majority of the QSOs should be ignored as duplicates, the
"missing" 37 should be imported if they are not themselves duplicates
of existing QSOs (log entries).

73,

... Joe, W4TV

On 2020-10-20 12:16 PM, Bill - AA4M wrote:
They are both showing the same 37 QSO error.
73, Bill  AA4M
On 10/20/2020 09:11:17, Carl - WC4H via groups.io wrote:
Hi Bill.

wsjtx.log file is not the log.  The wsjtx_log.adi file is the one to look at.

73.
Carl - WC4H


Re: N1MM to DXKeeper Gateway multiple county issue

ve3ki
 

Correct. If your contest entry category in N1MM+ is ROVER and you use the COUNTYLINE command to enter the location as the corner of DuPage, Kane, Kendall and Will counties (DUPG,KANE,KEND,WILL) and enter a single contact with W9IAU with the exchange GALL/HAML/SALI/WHIT, sixteen QSOs will automatically appear in the N1MM+ log, one for each of the 4x4 county combinations. The QSOs will be logged with times differing by two-second intervals, which means they might all be logged within the same clock minute, or they might be logged within two consecutive clock minutes if the 2-second increments happen to cause the minutes part of the time to roll over. Apart from the 2-second time differences, an internal database guid and the contents of the Exchange1 field, the contacts will be otherwise identical.

If you then export the log to ADIF and import that ADIF file into DXKeeper, all 16 contacts will be imported into the DXKeeper log. The rx info (SRX_STRING) field will contain the county abbreviation received from the other station. If you have not used the AD1C county conversion program and you want to record the other station's county in the county field in the DXKeeper log with the full county name, you will have to enter that information (you may be able to use the Advanced Sorts, Filters and Modifiers window to help with this). 

N1MM+ does not export the sent exchange to ADIF, so the tx info (STX_STRING) field in DXKeeper will be empty. If you wish, you can fill it in manually by referring to the sent exchange column in the Cabrillo file. If you wish to upload these contacts to LotW with the correct counties in the station information, you will have to separate out the contacts by individual sent exchange and use a separate tQSL station location for each county (sent exchange).

73,
Rich VE3KI


On Tue, Oct 20, 2020 at 10:57 AM, Scott Stembaugh wrote:
you have to tell N1MM that you are on a county line. I think you enter COUNTYLINE in the callbox before you make qsos. 

On Tue, Oct 20, 2020, 07:29 Mike - W1MI <aa1ar@...> wrote:
On Tue, Oct 20, 2020 at 04:00 AM, Phil Deaver wrote:
One more note on state QSO parties. This was true a few months ago and is probably still true (although I wasn't able to verify it with the station I worked this weekend. None of the callsigns on the QRZ page list an email address unfortunately). The station on the county line only gets credit for one contact while the contacting station gets credit for 2 or 3 or 4 QSOs. We found this out the hard way during the 7QP QSO party. We were told we would get double QSO points being on the county line, but that apparently was bad information. N1MM would only log one contact for the county line station with both counties in the report field. So it took us extra time to send out both counties info, we had many requests for repeats since it was a little unusual and we had to train some of the stations on how to input the two counties into N1MM. All of this slowed us down (quite a bit) and the only benefit to us was that our station was more desirable since it was a 2-fer to the calling station. So the result of this is that the calling station would have 2 QSOs into DXKeeper and LOTW while the called station would have 1 QSO. 

 Phil,
Looking at the last few paragraphs of https://n1mmwp.hamdocs.com/manual-supported/contests-setup/setup-qsop-contests/
you should have gotten multiple QSOs in your log for each contact.  Maybe something wasn't set up quite right...
73, Mike - W1MI


Re: LOTW Download Error Message

Dave AA6YQ
 

+ AA6YQ comments below
I am new to DXLab and am transiting from an different logging program.
+ Welcome to DXLab, Henry!

I have successfully imported my existing log and have successfully uploaded that log to LotW and have successfully synced LotW QSOs, all 65K of them. When I try to sync QSLs, I get the following error from DXKeeper. What might I have missed? 

"Unable to download from LotW: Invalid request"

+ Given that you've successfully invoked "Sync LoTW QSOs", your LoTW username and password are specified correctly. If retrying the "Sync LoTW QSLs" operation doesn't produce a different outcome, please do the following:

1. on the Configuration window's General tab, check the "Log debugging info" box

2. terminate DXKeeper

3. start DXKeeper

4. invoke the "Sync LoTW QSLs" operation

5. on the Configuration window's General tab, uncheck the "Log debugging info" box

6. attach the errorlog.txt file from your DXKeeper folder to an email message, and send the message to me via

aa6yq (at) ambersoft.com

           73,

                 Dave, AA6YQ


Re: Award progress report CSV generation

Dave AA6YQ
 

+ AA6YQ comments below
How can I generate a progress report in CSV, instead of TXT?
I saw the instructions below but it is not clear where I configure it:

+ Most award progress reports are generated as text files. A few (like WAZ) are generated as HTML files because their complexity warrants the use of tables with hyperlinks. A few (like Marathon) "award submission files" are generated in comma-delimited format because that's what their award sponsors required. 

+ There is no option to generate a progress report in a format of your choosing.

          73,

                 Dave, AA6YQ


Re: Missing QSO's

Dave AA6YQ
 

+ AA6YQ comments below
I just discovered  that my "wsjtx.log" file is showing 37 more QSO's than DXKeeper.  I  think what happened is that at some point in the past I accidentally turned off JTAlert, which resulted in a group of contacts not making it to DXKeeper.  Is there any easy way I can find the missing QSO's?

+ First, make a backup copy of your log file (in case things don't go as expected).

+ Second, direct DXKeeper to import your WSJT-X log file with "duplicate checking" enabled, with a range of 1 minute. Prepare for this operation to take a while. See

<https://www.dxlabsuite.com/dxkeeper/Help/Import.htm#Duplicate_Checking>

      73,

              Dave, AA6YQ


LOTW Download Error Message

Henry Boze
 

I am new to DXLab and am transiting from an different logging program. I have successfully imported my existing log and have successfully uploaded that log to LotW and have successfully synced LotW QSOs, all 65K of them. When I try to sync QSLs, I get the following error from DXKeeper. What might I have missed? 

"Unable to download from LotW: Invalid request"

Thanks for any help with this issue.

73,

Henry, N4HB


Re: N1MM to DXKeeper Gateway multiple county issue

Dave AA6YQ
 

+ AA6YQ comments below
Looking at the last few paragraphs of https://n1mmwp.hamdocs.com/manual-supported/contests-setup/setup-qsop-contests/
you should have gotten multiple QSOs in your log for each contact.  Maybe something wasn't set up quite right...
+ N1MM did log multiple QSOs for county-line contacts, but the current version of the N1MM-DXKeeper Gateway ks unaware of this possibility.

        73,

             Dave, AA6YQ


Re: N1MM to DXKeeper Gateway multiple county issue

Dave AA6YQ
 

* more AA6YQ comments below

The 2 second time difference creates another issue for me.  I also saw only two QSO's in DXKeeper for each of my 5 sets of QSOs with multiple counties.  If I import the entire contest log, DXKeeper rejects the missing QSOs as dupes because I have a checkmark next to "Check duplicates on import, range +/- 1 minutes".  If I remove the checkmark, I will get many dupes

 

+ Why are you enabling duplicate checking when importing your contest log from N1MM?

 

Since the majority of my contest log is already in DXKeeper, turning off dupe checking and re-importing would result in many dupes, would it not?

* Yes, it would. I'd misunderstood your earlier report to mean that you were importing an ADIF file with your contest QSOs after the contest, and was wondering why you had duplicate checking enabled when you did that.

       73,

             Dave, AA6YQ


Award progress report CSV generation

Py2Rn
 

How can I generate a progress report in CSV, instead of TXT?
I saw the instructions below but it is not clear where I configure it:

Generating Award Progress and Submission Reports

The awards for which DXKeeper provides progress reporting have differing requirements as to which items must be recorded with a QSO in order to properly determine credit. A table describing the requirements for each supported award is provided here.

DXKeeper can generate a wide variety of award progress and submission reports. The format of all dates used in these reports is specified via the Date Format panel on the Config window's Reports tab. Generated reports are placed in files in DXKeeper's  Reports sub-folder with filenames constructed from your callsign, the report name, and the report date, e.g.

  • AA6YQ Marathon Unlimited Mixed Progress 2014-12-15.txt

  • AA6YQ Marathon Formula Mixed Submission 2014-12-01.csv

  • AA6YQ Worked All DOKs 2008-11-27.txt

  • AA6YQ Worked All Prefixes Summary 2008-08-23.htm

Generated reports are saved as text files unless otherwise noted to produce files in HTML or CSV (comma-separated values) formats. After generating a progress report file, DXKeeper will display the report using the default viewer application for the file type assigned in Windows; typically, this assignment is

  • Notepad for .txt files

  • Microsoft Internet Explorer for .htm files

  • Microsoft Excel for .csv files

    Thanks

    Ed 

    PY2RN


Re: Missing QSO's

Bill - AA4M
 

They are both showing the same 37 QSO error.

73, Bill  AA4M


On 10/20/2020 09:11:17, Carl - WC4H via groups.io wrote:
Hi Bill.

wsjtx.log file is not the log.  The wsjtx_log.adi file is the one to look at.

73.
Carl - WC4H


Re: Missing QSO's

Carl - WC4H
 

Hi Bill.

wsjtx.log file is not the log.  The wsjtx_log.adi file is the one to look at.

73.
Carl - WC4H


Missing QSO's

Bill - AA4M
 

Hello,

I just discovered  that my "wsjtx.log" file is showing 37 more QSO's than DXKeeper.  I  think what happened is that at some point in the past I accidentally turned off JTAlert, which resulted in a group of contacts not making it to DXKeeper.  Is there any easy way I can find the missing QSO's?

73, Bill  AA4M


Re: N1MM to DXKeeper Gateway multiple county issue

Scott Stembaugh
 

you have to tell N1MM that you are on a county line. I think you enter COUNTYLINE in the callbox before you make qsos. 


On Tue, Oct 20, 2020, 07:29 Mike - W1MI <aa1ar@...> wrote:
On Tue, Oct 20, 2020 at 04:00 AM, Phil Deaver wrote:
One more note on state QSO parties. This was true a few months ago and is probably still true (although I wasn't able to verify it with the station I worked this weekend. None of the callsigns on the QRZ page list an email address unfortunately). The station on the county line only gets credit for one contact while the contacting station gets credit for 2 or 3 or 4 QSOs. We found this out the hard way during the 7QP QSO party. We were told we would get double QSO points being on the county line, but that apparently was bad information. N1MM would only log one contact for the county line station with both counties in the report field. So it took us extra time to send out both counties info, we had many requests for repeats since it was a little unusual and we had to train some of the stations on how to input the two counties into N1MM. All of this slowed us down (quite a bit) and the only benefit to us was that our station was more desirable since it was a 2-fer to the calling station. So the result of this is that the calling station would have 2 QSOs into DXKeeper and LOTW while the called station would have 1 QSO. 

 Phil,
Looking at the last few paragraphs of https://n1mmwp.hamdocs.com/manual-supported/contests-setup/setup-qsop-contests/
you should have gotten multiple QSOs in your log for each contact.  Maybe something wasn't set up quite right...
73, Mike - W1MI