Re: ADIF import for Rovers


Joe Subich, W4TV
 

I can't see that one ADIF log would have QSOs from more than one state QSO party. Could you not select the QSO party you're importing from a drop down list? AD1C's program does it that way.
There are multiple examples of overlapping state QSO parties. One
can not count on the Contest ID to define the state. I know of one
weekend that has a regional QSO party (7QP) plus two other states -
Maryland and Indiana, IIRC.

73,

... Joe, W4TV


On 2021-03-17 5:31 PM, Dave AA6YQ wrote:
+ AA6YQ comments below
I can't comment on the grid square import since I've never operated as a VHF contest rover. I have operated mobile in a number of state QSO parties.
I think not all logging programs export a CONTEST-ID tag.
+ N1MM does; I'm happy to start there, and then persuade others to follow.
I can't see that one ADIF log would have QSOs from more than one state QSO party. Could you not select the QSO party you're importing from a drop down list? AD1C's program does it that way.
+ DXKeeper could be extended to recognize state QSO parties in the imported CONTEST-ID tag, and infer "my state" that way.
Personally I would prefer to have more control on naming the myQTHID. The possible example above is longer than I would want to use. For example for the logs I imported for the Texas QSO Party myQTHIDs were TQP-Midland, TQP-Andrews, etc.
+ Understood.
Looking in the Documents/N1MM+/MultChaser directory on my computer I noticed there are XML files for each QSO party with the county abbreviation and full county name. Perhaps AB2ZY could expand those files so they could be used to provide a correct MY_CNTY tag on export of a QSO party log. A spot check shows the full county names in those files would have to be checked to insure they were the same as the LOTW county names. Some are not.
While this would be a nice feature I wonder how many DXLab users operate mobile in state QSO parties?
+ Nothing being contemplated would take more than 30 minutes to implement, document, and test -- but the addition of a new "Create Mobile myQTHID" option on the Main window's "Import QSOs" tab would increase user-perceived complexity.
+ Ideally, there will be a way for the N1MM user to ensure that the ADIF exported for each logged QSO includes a MY_GRIDSQUARE field that DXKeeper can then use to fabricate a myQTHID, if both enabled and necessary. That ensures that QSOs valid for VUCC will be correctly submitted to LoTW, no matter what the contest.
+ If that's not the case, then using MY_GRIDSQUARE when present, and a combination of the state inferred from the state QSO party specified in CONTEST-ID and the county code from the new APP_N1MM_ROVERCNTY field would be the fallback. This would yield fabricated myQTHIDs like
mobile_FN42
+ and
mobile_VA_LAN
+ and
mobile_PA_LAN
+ In the case where MY_GRIDSQUARE is not present, the rover who logs VHF or UHF QSOs from multiple grid squares within a county would have some manual work to do to ensure correct uploads to LoTW.
+ In case anyone is wondering what we're doing here, it's called "Requirements Elicitation by Stumbling Around".
73,
Dave, AA6YQ

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