Re: N1MM to DXKeeper Gateway multiple county issue


ve3ki
 

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.

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.

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.

73,
Rich VE3KI


On Sun, Oct 18, 2020 at 05:28 PM, Dave AA6YQ wrote:
+ AA6YQ comments below

I'm running DXKeeper Gateway version 1.1.5 and 1.0.8701.0 N1MM and up-to-date versions of Dxkeeper and Dxview. I was working a state QSO party this weekend and one station sent me four counties in Illinois. All four counties showed up as separate QSOs in N1MM 

+ Did you direct N1MM to log one QSO, or four QSOs?

+ Does anyone from the N1MM development team know whether N1MM emits one or four <contactinfo> UDP messages in a scenario like this?


but only the first two counties got transferred to DXKeeper and LOTW.

+ Where were the first two counties recorded in DXKeeper?


I was impressed that N1MM parsed it

+ To what does the word "it" refer?

h
and that at least two counties made it into dxkeeper and LOTW but if I were a county hunter, I'd miss the other two counties.

+ The N1MM-DXKeeper Gateway does not convey US counties from N1MM to DXKeeper; see the list of information conveyed in the Operation section of

<https://www.dxlabsuite.com/N1MM-DXKeeper/index.htm>


Is there a limit of two counties or a string length issue? They all were four characters. (GALL/HAML/SALI/WHIT).

+ DXKeeper does not interpret 4-character sequences appended to callsigns as US County names. DXKeeper can record callsigns of up to 13 characters in length.


+ The N1MM-DXKeeper Gateway logs one QSO in DXKeeper in response to each <contactinfo> UDP message it receives from N1MM.

<https://n1mmwp.hamdocs.com/appendices/external-udp-broadcasts/#contact-info-udp-packet>

+ The <contactinfo> UDP message does not provide a means of conveying the name of a US country, or of any other secondary administrative subdivision.

73,

Dave, AA6YQ

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