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

Join DXLab@groups.io to automatically receive all group messages.