Date   

Re: N1MM to DXKeeper Gateway multiple county issue

Mike - W1MI
 

On Mon, Oct 19, 2020 at 07:54 PM, ve3ki wrote:
Mike,

If you already have a lot of QSOs transferred from N1MM+ to DXKeeper via the Gateway and the only ones you are missing are from county line QSOs (which I assume are only a small fraction of the total), then what I would do is export the full ADIF from N1MM+ and then edit out all of the QSOs that are already in DXKeeper (all the non-county-line QSOs pus the county-line ones that did make it through the Gateway). You can do this quite easily in ADIF Master (<http://www.dxshell.com/adif-master.html>), which presents the ADIF file in a spreadsheet format, allows sorting on any field, and makes editing tasks like deleting unwanted rows en masse quite easy. Once the file is pared down to only non-dupe QSOs, which should take only a couple of minutes, you can import it into DXKeeper with dupe checking turned off.

73,
Rich VE3KI
Thanks, Rich

I was going to edit it in notepad, but ADIF Master would speed things up!

73, Mike - W1MI


Re: N1MM to DXKeeper Gateway multiple county issue

Mike - W1MI
 

On Mon, Oct 19, 2020 at 07:01 PM, Dave AA6YQ wrote:
+ 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?


Re: N1MM to DXKeeper Gateway multiple county issue

Phil Deaver
 

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. 


Re: WSJT-X stopped logging to DXK

Dave AA6YQ
 

+ AA6YQ comments below

Today WSJT-X stopped logging to DXK. Clicking OK on the Log QSO box has no effect. The QSO just disappeared. Normally the DXK log entry is populated and the QSO is logged. This is not happening. Ive had to open the capture window and log the call manually in order to secure a DXK entry. I checked SC and if is running but I do not see the window showing DXK and SC are connected.

+ In the "Spot source status" panel at the top of SpotCollector's Main window, there are 7 circular indicators. What color is the right-most indicator in this panel.

+ In the title bar of SpotCollector's Main window, what letters appear between the square brackets?

+ In your SpotCollector folder, is there a file named

errorlog.txt

+ or

SC_WSJTX_Errorlog.txt

+ ? If either or both are present, please attach them to an email message, and send the message to me via

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ


WSJT-X stopped logging to DXK

Ed W2LCQ
 


Today WSJT-X stopped logging to DXK. Clicking OK on the Log QSO box has no effect. The QSO just disappeared. Normally the DXK log entry is populated and the QSO is logged. This is not happening. Ive had to open the capture window and log the call manually in order to secure a DXK entry. I checked SC and
if is running but I do not see the window showing DXK and SC are connected.
I updated 2 DBs using DX View earlier today  I doubt that could cause the problem. If you have any suggestions how I can get WSTJ-X logging back on track I‘d appreciate any help. Thanks so much.

Best, Ed

73 de W2LCQ, Ed Jones

Frankford Radio Club
B.U.G. 204 - TBDXC 1337 - CWops 701 (Life) - SKCC 5474T - FISTS 12294 - QCWA 33438 - LICWC 51 - ARRL - New York County (Manhattan) FN30AT

Most certainly, some planets are not inhabited, but others are, and among these there must exist life under all conditions and phases of development.”Nicola Tesla


Test

Ed W2LCQ
 

Test

73 de W2LCQ, Ed Jones

Frankford Radio Club
B.U.G. 204 - TBDXC 1337 - CWops 701 (Life) - SKCC 5474T - FISTS 12294 - QCWA 33438 - LICWC 51 - ARRL - New York County (Manhattan) FN30AT

Most certainly, some planets are not inhabited, but others are, and among these there must exist life under all conditions and phases of development.”Nicola Tesla


Re: N1MM to DXKeeper Gateway multiple county issue

Dave AA6YQ
 

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.

      73,

             Dave, AA6YQ
 

+ AA6YQ comments below
I can't tell you for sure whether N1MM+ emits one <contactinfo> message or four, but from the N1MM+ manual:
"Separate QSOs will appear in your log, one for each county."
If four separate QSOs are logged, it might seem reasonable to expect four <contactinfo> messages in rapid succession, but without setting up a test I cannot be sure about that.

+ The 3 possibilities are

1. N1MM+ only sent 2 <contactinfo> messages (defect in N1MM+)

2. N1MM+ sent 4 <contactinfo> messages, but only 2 of those messages were actually delivered the N1MM_DXKeeper gateway because the UDP protocol that N1MM+ employs to deliver <contactinfo> messages is a "best efforts" protocol, with no guarantee of delivery.

3. N1MM+ sent 4 <contactinfo> messages, and all 4 of those messages were actually delivered to the the N1MM_DXKeeper gateway, but a defect in gateway or DXKeeper resulted only two QSOs being logged.

+ I would be helpful if someone familiar with N1MM+, the N1MM-DXKeeper Gateway, and state QSO parties could attempt to replicate this scenario so that we can determine what's going on, and correct whatever defects we find.


Re: N1MM to DXKeeper Gateway multiple county issue

ve3ki
 

Mike,

If you already have a lot of QSOs transferred from N1MM+ to DXKeeper via the Gateway and the only ones you are missing are from county line QSOs (which I assume are only a small fraction of the total), then what I would do is export the full ADIF from N1MM+ and then edit out all of the QSOs that are already in DXKeeper (all the non-county-line QSOs pus the county-line ones that did make it through the Gateway). You can do this quite easily in ADIF Master (<http://www.dxshell.com/adif-master.html>), which presents the ADIF file in a spreadsheet format, allows sorting on any field, and makes editing tasks like deleting unwanted rows en masse quite easy. Once the file is pared down to only non-dupe QSOs, which should take only a couple of minutes, you can import it into DXKeeper with dupe checking turned off.

73,
Rich VE3KI


On Mon, Oct 19, 2020 at 07:25 AM, Mike - W1MI wrote:
On Mon, Oct 19, 2020 at 12:26 AM, Dave AA6YQ wrote:
+ LoTW only requires QSO start times to match within 30 minutes, so the "log one QSO every 2 seconds" approach will not prevent LoTW confirmations, so long as your QSO partner submits 4 QSOs to LoTW, each using a Station Location that specifies the correct US Country. At present, however, LoTW confirmations do not count towards CQ's USA-CA award (worked all US Counties).
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.  It won't be a big deal to manually get these few QSO's imported, but is there a way to get DXKeeper to do it automatically?

73, Mike - W1MI


Re: Spot collector fails to launch

Dave AA6YQ
 

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

+ This is almost always the result of an incompetent or incorrectly-configured anti-malware application. You can confirm this by rebooting Windows into "Safe mode with networking", starting the Launcher, and then directing the Launcher to start SpotCollector.

+ See

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

       73,

              Dave, AA6YQ


Re: N1MM to DXKeeper Gateway multiple county issue

Dave AA6YQ
 

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


        73,

              Dave, AA6YQ


Re: Spot collector fails to launch

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 Mon, Oct 19, 2020 at 12:26 AM, Dave AA6YQ wrote:
+ LoTW only requires QSO start times to match within 30 minutes, so the "log one QSO every 2 seconds" approach will not prevent LoTW confirmations, so long as your QSO partner submits 4 QSOs to LoTW, each using a Station Location that specifies the correct US Country. At present, however, LoTW confirmations do not count towards CQ's USA-CA award (worked all US Counties).
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.  It won't be a big deal to manually get these few QSO's imported, but is there a way to get DXKeeper to do it automatically?

73, Mike - W1MI


Re: N1MM to DXKeeper Gateway multiple county issue

Phil Deaver
 

Here are the four QSO's in question. The QSOs are timestamped  two seconds apart.. Only the first two show up in DXKeeper.

<CALL:5>W9AIU <QSO_DATE:8>20201018 <TIME_ON:6>203419 <TIME_OFF:6>203419 <SECTION:2>IL <BAND:3>20M <STATION_CALLSIGN:4>WR7T <FREQ:8>14.04243 <COMMENT:19>GALL/HAML/SALI/WHIT <CONTEST_ID:12>IL-QSO-PARTY <FREQ_RX:8>14.04243 <MODE:2>CW <RST_RCVD:3>599 <RST_SENT:3>599 <TX_PWR:3>100 <OPERATOR:4>WR7T <CQZ:1>4 <STX:1>4 <APP_N1MM_EXCHANGE1:4>GALL <APP_N1MM_POINTS:1>2 <APP_N1MM_RADIO_NR:1>1 <APP_N1MM_CONTINENT:2>NA <APP_N1MM_RUN1RUN2:1>1 <APP_N1MM_RADIOINTERFACED:1>1 <APP_N1MM_ISORIGINAL:4>True <APP_N1MM_NETBIOSNAME:7>PHIL-PC <APP_N1MM_ISRUNQSO:1>0 <APP_N1MM_ID:32>fa3974d532724abba7e1be7212724c9f <APP_N1MM_CLAIMEDQSO:1>1 <EOR>

 <CALL:5>W9AIU <QSO_DATE:8>20201018 <TIME_ON:6>203421 <TIME_OFF:6>203421 <SECTION:2>IL <BAND:3>20M <STATION_CALLSIGN:4>WR7T <FREQ:8>14.04243 <COMMENT:19>GALL/HAML/SALI/WHIT <CONTEST_ID:12>IL-QSO-PARTY <FREQ_RX:8>14.04243 <MODE:2>CW <RST_RCVD:3>599 <RST_SENT:3>599 <TX_PWR:3>100 <OPERATOR:4>WR7T <CQZ:1>4 <STX:1>4 <APP_N1MM_EXCHANGE1:4>HAML <APP_N1MM_POINTS:1>2 <APP_N1MM_RADIO_NR:1>1 Here are the 
<APP_N1MM_CONTINENT:2>NA <APP_N1MM_RUN1RUN2:1>1 <APP_N1MM_RADIOINTERFACED:1>1 <APP_N1MM_ISORIGINAL:4>True <APP_N1MM_NETBIOSNAME:7>PHIL-PC <APP_N1MM_ISRUNQSO:1>0 <APP_N1MM_ID:32>a02fa0230eab40f184f6814b051843d9 <APP_N1MM_CLAIMEDQSO:1>1 <EOR>

 <CALL:5>W9AIU <QSO_DATE:8>20201018 <TIME_ON:6>203423 <TIME_OFF:6>203423 <SECTION:2>IL <BAND:3>20M <STATION_CALLSIGN:4>WR7T <FREQ:8>14.04243 <COMMENT:19>GALL/HAML/SALI/WHIT <CONTEST_ID:12>IL-QSO-PARTY <FREQ_RX:8>14.04243 <MODE:2>CW <RST_RCVD:3>599 <RST_SENT:3>599 <TX_PWR:3>100 <OPERATOR:4>WR7T <CQZ:1>4 <STX:1>4 <APP_N1MM_EXCHANGE1:4>SALI <APP_N1MM_POINTS:1>2 <APP_N1MM_RADIO_NR:1>1 <APP_N1MM_CONTINENT:2>NA <APP_N1MM_RUN1RUN2:1>1 <APP_N1MM_RADIOINTERFACED:1>1 <APP_N1MM_ISORIGINAL:4>True <APP_N1MM_NETBIOSNAME:7>PHIL-PC <APP_N1MM_ISRUNQSO:1>0 <APP_N1MM_ID:32>e4dbaafe62ca433d83729eebdba4c5ca <APP_N1MM_CLAIMEDQSO:1>1 <EOR>

 <CALL:5>W9AIU <QSO_DATE:8>20201018 <TIME_ON:6>203425 <TIME_OFF:6>203425 <SECTION:2>IL <BAND:3>20M <STATION_CALLSIGN:4>WR7T <FREQ:8>14.04243 <COMMENT:19>GALL/HAML/SALI/WHIT <CONTEST_ID:12>IL-QSO-PARTY <FREQ_RX:8>14.04243 <MODE:2>CW <RST_RCVD:3>599 <RST_SENT:3>599 <TX_PWR:3>100 <OPERATOR:4>WR7T <CQZ:1>4 <STX:1>4 <APP_N1MM_EXCHANGE1:4>WHIT <APP_N1MM_POINTS:1>2 <APP_N1MM_RADIO_NR:1>1 <APP_N1MM_CONTINENT:2>NA <APP_N1MM_RUN1RUN2:1>1 <APP_N1MM_RADIOINTERFACED:1>1 <APP_N1MM_ISORIGINAL:4>True <APP_N1MM_NETBIOSNAME:7>PHIL-PC <APP_N1MM_ISRUNQSO:1>0 <APP_N1MM_ID:32>b394bfb474ca4e6c8454c0d82c598dba <APP_N1MM_CLAIMEDQSO:1>1 <EOR>

I had been using N1MM exports to ADIF files previously but I discovered the neat program N1MM to DXKeeper Gateway a few days ago. It works great. I just left it running during the Illinois QSO party.

Phil WR7T


Re: N1MM to DXKeeper Gateway multiple county issue

Dave AA6YQ
 

+ AA6YQ comments below

There are 58 (+/-) QSO parties with county abbreviations supported by N1MM+. Those abbreviations range between 3 and 6 characters in length - four characters was for the particular QSO party Phil logged the contacts in (I'm guessing it was the Illinois QSO Party). There is a file distributed with the N1MM Logger+ program (actually with each program update) that contains lists of the abbreviations used in all of those contests, but that list does not indicate what the actual county name is, only which abbreviations are considered valid in each contest. The correspondence between the abbreviations and the full county names would presumably be found on the applicable contest sponsor web sites. The list could change from time to time depending on whether the sponsors for one of the contests choose to change their abbreviation list or format for some reason. For these reasons, I don't think this list would be useful for your suggested purpose.

+ if Jim AD1C can maintain an application that performs the county name "translations" in batch, then it should be possible to perform them interactively. I'll ask him about it.

If Phil could report the exact times logged in DXKeeper for the two QSOs, that would help pin down what is happening. If they are identical to the second, N1MM+ must be issuing <contactinfo> messages with identical times, which would be surprising given that it logs them with different times, but not impossible. If they differ by two seconds (or four or six seconds), the issue is likely with the UDP message transmission / buffering / decoding process.

In any case, my own recommendation would be for people wanting to transfer contacts from these contests to use the ADIF export / AD1C county code conversion / ADIF import procedure. Not only is it less likely to have problems, the visibility of the ADIF files makes it much easier to diagnose and debug any problems that might arise,

+ I'll add a "Log debugging info" option to the next version of the N1MM-DXKeeper Gateway so that we can better track down problems like this one.

73,

Dave, AA6YQ


Re: N1MM to DXKeeper Gateway multiple county issue

Dave AA6YQ
 

* More AA6YQ comments below


+ There's clearly a defect lurking here; thanks for reporting the
behavior so that it can be tracked down and corrected.
It is likely in the data N1MM+ emits in the UDP broadcast. Any way to check the *TIME* in the four QSOs N1MM has logged? I don't believe DXKeeper considers the "Exchange1"/"SRX_STRING" data in its duplicate checking routine (only date/time/call/band/frequency/mode) thus the four N1MM+ "QSO" records would each need to have unique times. If any two QSOs were recorded with the same time to the second, the second QSO record would probably be ignored as a duplicate by DXKeeper.

* Only if duplicate checking were enabled on the Main window's "Import QSOs" tab, which is not recommended given the performance penalty.

73,

Dave, AA6YQ


Re: N1MM to DXKeeper Gateway multiple county issue

Dave AA6YQ
 

+ AA6YQ comments below

have you allowed for the unfortunate behaviour of the VB6 UDP client that concatenates UDP datagrams into one response buffer?

+ Thanks for the reminder, Bill. It looks like the original developer of the N1MM-DXKeeper gateway handled that correctly.

73,

Dave, AA6YQ


Re: N1MM to DXKeeper Gateway multiple county issue

ve3ki
 

Dave,

There are 58 (+/-) QSO parties with county abbreviations supported by N1MM+. Those abbreviations range between 3 and 6 characters in length - four characters was for the particular QSO party Phil logged the contacts in (I'm guessing it was the Illinois QSO Party). There is a file distributed with the N1MM Logger+ program (actually with each program update) that contains lists of the abbreviations used in all of those contests, but that list does not indicate what the actual county name is, only which abbreviations are considered valid in each contest. The correspondence between the abbreviations and the full county names would presumably be found on the applicable contest sponsor web sites. The list could change from time to time depending on whether the sponsors for one of the contests choose to change their abbreviation list or format for some reason. For these reasons, I don't think this list would be useful for your suggested purpose.

If Phil  could report the exact times logged in DXKeeper for the two QSOs, that would help pin down what is happening. If they are identical to the second, N1MM+ must be issuing <contactinfo> messages with identical times, which would be surprising given that it logs them with different times, but not impossible. If they differ by two seconds (or four or six seconds), the issue is likely with the UDP message transmission / buffering / decoding process.

In any case, my own recommendation would be for people wanting to transfer contacts from these contests to use the ADIF export / AD1C county code conversion / ADIF import procedure. Not only is it less likely to have problems, the visibility of the ADIF files makes it much easier to diagnose and debug any problems that might arise,

73,
Rich VE3KI


On Sun, Oct 18, 2020 at 08:26 PM, Dave AA6YQ wrote:
+ AA6YQ comments below
I can't tell you for sure whether N1MM+ emits one <contactinfo> message or four, but from the N1MM+ manual:
"Separate QSOs will appear in your log, one for each county."
If four separate QSOs are logged, it might seem reasonable to expect four <contactinfo> messages in rapid succession, but without setting up a test I cannot be sure about that.

+ The 3 possibilities are

1. N1MM+ only sent 2 <contactinfo> messages (defect in N1MM+)

2. N1MM+ sent 4 <contactinfo> messages, but only 2 of those messages were actually delivered the N1MM_DXKeeper gateway because the UDP protocol that N1MM+ employs to deliver <contactinfo> messages is a "best efforts" protocol, with no guarantee of delivery.

3. N1MM+ sent 4 <contactinfo> messages, and all 4 of those messages were actually delivered to the the N1MM_DXKeeper gateway, but a defect in gateway or DXKeeper resulted only two QSOs being logged.

+ I would be helpful if someone familiar with N1MM+, the N1MM-DXKeeper Gateway, and state QSO parties could attempt to replicate this scenario so that we can determine what's going on, and correct whatever defects we find.


In any case, the "county" data exported by N1MM+ is not exported as county data. It is exported as "Exchange1" data, which I believe the Gateway translates into the SRX_STRING field. If there were four <contactinfo> messages, there should be four QSOs imported into DXKeeper, each with a different four-letter exchange abbreviation stored in the SRX_STRING field. There would be nothing stored in the County field, because N1MM+ does not export ADIF county data, it exports received contest exchange abbreviations, which are not valid county data in accordance with the ADIF specification that DXKeeper uses.

There is a program written by AD1C that can read an ADIF file exported by N1MM+ (or other contest logging programs) and convert the contest exchange abbreviation data recorded by the logging program into a valid ADIF County field -- see <http://software.ad1c.us/ADIF_County/index.html>. The way to use this to get the county data into DXKeeper would be by turning off the Gateway during the contest, exporting an ADIF file from N1MM+ after the contest, running it through the conversion program, and then importing the converted ADIF file into DXKeeper.

+ Alternatively, I could add that capability to the N1MM-DXKeeper Gateway. Where would I find the list of state QSO parties for which N1MM records 4-letter county abbreviations in SRX_STRING field? Where would I find a list of the 4-letter county abbreviations and their full county names?

My understanding of how county-line QSOs are logged in N1MM+ (see <https://n1mmwp.hamdocs.com/manual-supported/contests-setup/setup-qsop-contests/#rover-mobile-and-county-line-support>)
is that there would be four separate QSOs logged in N1MM+ at two-second intervals, resulting in four separate QSOs in the ADIF file and therefore in DXKeeper. When uploaded to LotW, these would be recorded as four otherwise identical QSOs at two-second intervals. Note that information about the other station's location (state/county/country/zone/IOTA reference) from your log is not uploaded to LotW - that kind of information comes only from the other station's upload. To have the county data recorded correctly in LotW, the other station would have to upload each of the four separately-logged QSOs signed with a separate station location, one for each county. Also, while the times of those four QSOs would also be separated by two-second intervals, it is unlikely that the exact time logged would be identical to the second at both ends of the QSO, meaning matching up the QSO records between the two stations might be a bit trickier than usual.

+ LoTW only requires QSO start times to match within 30 minutes, so the "log one QSO every 2 seconds" approach will not prevent LoTW confirmations, so long as your QSO partner submits 4 QSOs to LoTW, each using a Station Location that specifies the correct US Country. At present, however, LoTW confirmations do not count towards CQ's USA-CA award (worked all US Counties).

+ Many thanks for the helpful response, Rich!

73,

Dave, AA6YQ


Re: N1MM to DXKeeper Gateway multiple county issue

Joe Subich, W4TV
 

+ There's clearly a defect lurking here; thanks for reporting the
behavior so that it can be tracked down and corrected.
It is likely in the data N1MM+ emits in the UDP broadcast. Any way
to check the *TIME* in the four QSOs N1MM has logged? I don't believe
DXKeeper considers the "Exchange1"/"SRX_STRING" data in its duplicate
checking routine (only date/time/call/band/frequency/mode) thus the
four N1MM+ "QSO" records would each need to have unique times. If
any two QSOs were recorded with the same time to the second, the
second QSO record would probably be ignored as a duplicate by DXKeeper.

N1MM should probably assign a unique start time to each "QSO" as a
matter of course otherwise LotW will also have heartburn with any
records that share start times.

73,

... Joe, W4TV


On 2020-10-18 8:11 PM, Dave AA6YQ wrote:
+ AA6YQ comments below
N1MM logged four QSOs without my interaction.
The county data was in the exchange I received from the IL station. The QSO's that made it into dxkeeper show the exchange in the RX info section of the contest panel, but only the first two of the four qso's show up.
+ Thanks, Phil! That clarifies the situation.
======I was impressed that N1MM parsed it =======+ To what does the word "it" refer?
I was impressed that N1MM took the exchange from one QSO and logged it as four separate QSO's with different counties, and giving me credit for working those 4 counties in the QSO party.
It's not a problem for me. I thought I would just report my findings in case anyone was interested.
+ There's clearly a defect lurking here; thanks for reporting the behavior so that it can be tracked down and corrected.
73,
Dave, AA6YQ


Re: N1MM to DXKeeper Gateway multiple county issue

g4wjs
 

On 19/10/2020 01:26, Dave AA6YQ wrote:
+ AA6YQ comments below
I can't tell you for sure whether N1MM+ emits one <contactinfo> message or four, but from the N1MM+ manual:
"Separate QSOs will appear in your log, one for each county."
If four separate QSOs are logged, it might seem reasonable to expect four <contactinfo> messages in rapid succession, but without setting up a test I cannot be sure about that.

+ The 3 possibilities are

1. N1MM+ only sent 2 <contactinfo> messages (defect in N1MM+)

2. N1MM+ sent 4 <contactinfo> messages, but only 2 of those messages were actually delivered the N1MM_DXKeeper gateway because the UDP protocol that N1MM+ employs to deliver <contactinfo> messages is a "best efforts" protocol, with no guarantee of delivery.

3. N1MM+ sent 4 <contactinfo> messages, and all 4 of those messages were actually delivered to the the N1MM_DXKeeper gateway, but a defect in gateway or DXKeeper resulted only two QSOs being logged.

+ I would be helpful if someone familiar with N1MM+, the N1MM-DXKeeper Gateway, and state QSO parties could attempt to replicate this scenario so that we can determine what's going on, and correct whatever defects we find.


In any case, the "county" data exported by N1MM+ is not exported as county data. It is exported as "Exchange1" data, which I believe the Gateway translates into the SRX_STRING field. If there were four <contactinfo> messages, there should be four QSOs imported into DXKeeper, each with a different four-letter exchange abbreviation stored in the SRX_STRING field. There would be nothing stored in the County field, because N1MM+ does not export ADIF county data, it exports received contest exchange abbreviations, which are not valid county data in accordance with the ADIF specification that DXKeeper uses.

There is a program written by AD1C that can read an ADIF file exported by N1MM+ (or other contest logging programs) and convert the contest exchange abbreviation data recorded by the logging program into a valid ADIF County field -- see<http://software.ad1c.us/ADIF_County/index.html>. The way to use this to get the county data into DXKeeper would be by turning off the Gateway during the contest, exporting an ADIF file from N1MM+ after the contest, running it through the conversion program, and then importing the converted ADIF file into DXKeeper.

+ Alternatively, I could add that capability to the N1MM-DXKeeper Gateway. Where would I find the list of state QSO parties for which N1MM records 4-letter county abbreviations in SRX_STRING field? Where would I find a list of the 4-letter county abbreviations and their full county names?

My understanding of how county-line QSOs are logged in N1MM+ (see<https://n1mmwp.hamdocs.com/manual-supported/contests-setup/setup-qsop-contests/#rover-mobile-and-county-line-support>)
is that there would be four separate QSOs logged in N1MM+ at two-second intervals, resulting in four separate QSOs in the ADIF file and therefore in DXKeeper. When uploaded to LotW, these would be recorded as four otherwise identical QSOs at two-second intervals. Note that information about the other station's location (state/county/country/zone/IOTA reference) from your log is not uploaded to LotW - that kind of information comes only from the other station's upload. To have the county data recorded correctly in LotW, the other station would have to upload each of the four separately-logged QSOs signed with a separate station location, one for each county. Also, while the times of those four QSOs would also be separated by two-second intervals, it is unlikely that the exact time logged would be identical to the second at both ends of the QSO, meaning matching up the QSO records between the two stations might be a bit trickier than usual.

+ LoTW only requires QSO start times to match within 30 minutes, so the "log one QSO every 2 seconds" approach will not prevent LoTW confirmations, so long as your QSO partner submits 4 QSOs to LoTW, each using a Station Location that specifies the correct US Country. At present, however, LoTW confirmations do not count towards CQ's USA-CA award (worked all US Counties).

+ Many thanks for the helpful response, Rich!

73,

Dave, AA6YQ
Hi Dave,

have you allowed for the unfortunate behaviour of the VB6 UDP client that concatenates UDP datagrams into one response buffer?



--
73

Bill

G4WJS.


Re: N1MM to DXKeeper Gateway multiple county issue

Dave AA6YQ
 

+ AA6YQ comments below
I can't tell you for sure whether N1MM+ emits one <contactinfo> message or four, but from the N1MM+ manual:
"Separate QSOs will appear in your log, one for each county."
If four separate QSOs are logged, it might seem reasonable to expect four <contactinfo> messages in rapid succession, but without setting up a test I cannot be sure about that.

+ The 3 possibilities are

1. N1MM+ only sent 2 <contactinfo> messages (defect in N1MM+)

2. N1MM+ sent 4 <contactinfo> messages, but only 2 of those messages were actually delivered the N1MM_DXKeeper gateway because the UDP protocol that N1MM+ employs to deliver <contactinfo> messages is a "best efforts" protocol, with no guarantee of delivery.

3. N1MM+ sent 4 <contactinfo> messages, and all 4 of those messages were actually delivered to the the N1MM_DXKeeper gateway, but a defect in gateway or DXKeeper resulted only two QSOs being logged.

+ I would be helpful if someone familiar with N1MM+, the N1MM-DXKeeper Gateway, and state QSO parties could attempt to replicate this scenario so that we can determine what's going on, and correct whatever defects we find.


In any case, the "county" data exported by N1MM+ is not exported as county data. It is exported as "Exchange1" data, which I believe the Gateway translates into the SRX_STRING field. If there were four <contactinfo> messages, there should be four QSOs imported into DXKeeper, each with a different four-letter exchange abbreviation stored in the SRX_STRING field. There would be nothing stored in the County field, because N1MM+ does not export ADIF county data, it exports received contest exchange abbreviations, which are not valid county data in accordance with the ADIF specification that DXKeeper uses.

There is a program written by AD1C that can read an ADIF file exported by N1MM+ (or other contest logging programs) and convert the contest exchange abbreviation data recorded by the logging program into a valid ADIF County field -- see <http://software.ad1c.us/ADIF_County/index.html>. The way to use this to get the county data into DXKeeper would be by turning off the Gateway during the contest, exporting an ADIF file from N1MM+ after the contest, running it through the conversion program, and then importing the converted ADIF file into DXKeeper.

+ Alternatively, I could add that capability to the N1MM-DXKeeper Gateway. Where would I find the list of state QSO parties for which N1MM records 4-letter county abbreviations in SRX_STRING field? Where would I find a list of the 4-letter county abbreviations and their full county names?

My understanding of how county-line QSOs are logged in N1MM+ (see <https://n1mmwp.hamdocs.com/manual-supported/contests-setup/setup-qsop-contests/#rover-mobile-and-county-line-support>)
is that there would be four separate QSOs logged in N1MM+ at two-second intervals, resulting in four separate QSOs in the ADIF file and therefore in DXKeeper. When uploaded to LotW, these would be recorded as four otherwise identical QSOs at two-second intervals. Note that information about the other station's location (state/county/country/zone/IOTA reference) from your log is not uploaded to LotW - that kind of information comes only from the other station's upload. To have the county data recorded correctly in LotW, the other station would have to upload each of the four separately-logged QSOs signed with a separate station location, one for each county. Also, while the times of those four QSOs would also be separated by two-second intervals, it is unlikely that the exact time logged would be identical to the second at both ends of the QSO, meaning matching up the QSO records between the two stations might be a bit trickier than usual.

+ LoTW only requires QSO start times to match within 30 minutes, so the "log one QSO every 2 seconds" approach will not prevent LoTW confirmations, so long as your QSO partner submits 4 QSOs to LoTW, each using a Station Location that specifies the correct US Country. At present, however, LoTW confirmations do not count towards CQ's USA-CA award (worked all US Counties).

+ Many thanks for the helpful response, Rich!

73,

Dave, AA6YQ

3921 - 3940 of 200754