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