ADIF import for Rovers


AB2ZY
 

This is probably best answered by Dave or another dev team member.

I'm one of the N1MM developers. I'm making some changes to the ADIF export per a request from the ARRLs LoTW team.

For rovers - this would be VHF and State QSO party contests - they currently have to create a separate ADIF file for each county or grid square they operate from. I've modified N1MM to export rover grid squares to the standard MY_GRIDSQUARE ADIF tag and LoTW will be able populate the actual QTH from the QSO record instead of using the station location from the header.

I'm considering doing the same with counties and the standard MY_CNTY tag. Main objection I have to doing so is that no contest uses the ADIF enumeration values and thus to populate those fields would require maintaining a cross reference between QSO party county codes and ADIF values in N1MM.

One of the things that might help us decide is whether or not DXKeeper does anything with the MY_GRIDSQUARE and MY_CNTY tags on import? If you do and you support MY_CNTY, do you expect ADIF enumeration values or do you translate from state QSO party values?

Al
AB2ZY


Dave Fugleberg
 

Al,
I'm not Dave (well, actually I AM Dave, just not THAT Dave)...however, speaking as a frequent VHF Rover and N1MM and DxKeeper user, anything you can do to reduce the manual post-processing of logs will be VERY welcome!  
Right now, I use ADIF Split by AD1C to split the log by grid, create a new MyQTH in DxKeeper for each grid, load each file with a substitution to set the matching MyQTH, and upload each one to LoTW.  OK for a couple of grids; not much fun for a rove with a dozen or more grids.
Looking forward to hearing more about this !
73 de Dave, W0ZF


On Sun, Mar 14, 2021 at 6:52 PM AB2ZY <akozak@...> wrote:
This is probably best answered by Dave or another dev team member.

I'm one of the N1MM developers. I'm making some changes to the ADIF export per a request from the ARRLs LoTW team.

For rovers - this would be VHF and State QSO party contests - they currently have to create a separate ADIF file for each county or grid square they operate from. I've modified N1MM to export rover grid squares to the standard MY_GRIDSQUARE ADIF tag and LoTW will be able populate the actual QTH from the QSO record instead of using the station location from the header.

I'm considering doing the same with counties and the standard MY_CNTY tag. Main objection I have to doing so is that no contest uses the ADIF enumeration values and thus to populate those fields would require maintaining a cross reference between QSO party county codes and ADIF values in N1MM.

One of the things that might help us decide is whether or not DXKeeper does anything with the MY_GRIDSQUARE and MY_CNTY tags on import? If you do and you support MY_CNTY, do you expect ADIF enumeration values or do you translate from state QSO party values?

Al
AB2ZY


Dave AA6YQ
 

+ AA6YQ comments below

This is probably best answered by Dave or another dev team member.

I'm one of the N1MM developers. I'm making some changes to the ADIF export per a request from the ARRLs LoTW team.

For rovers - this would be VHF and State QSO party contests - they currently have to create a separate ADIF file for each county or grid square they operate from. I've modified N1MM to export rover grid squares to the standard MY_GRIDSQUARE ADIF tag and LoTW will be able populate the actual QTH from the QSO record instead of using the station location from the header.

I'm considering doing the same with counties and the standard MY_CNTY tag. Main objection I have to doing so is that no contest uses the ADIF enumeration values and thus to populate those fields would require maintaining a cross reference between QSO party county codes and ADIF values in N1MM.

One of the things that might help us decide is whether or not DXKeeper does anything with the MY_GRIDSQUARE and MY_CNTY tags on import? If you do and you support MY_CNTY, do you expect ADIF enumeration values or do you translate from state QSO party values?


+ First, Al, thanks for asking!!!

+ In DXKeeper vernacular, a "my QTH" is a physical location from which an operator has made one or more QSOs. DXKeeper permits an operator to define one or more "my QTHs", specifying the details of the physical location for each (postal address, lat/lon, grid, secondary administrative subdivision (e.g. County in the US, City/Gun in Japan), primary administrative subdivision (e.g. State in the US, Prefecture in Japan, Department in France); a "my QTH" can also specify an LoTW "Station Location". Each "my QTH" is assigned a unique ID, most typically a city, town, or village name; some ops include the location's grid square in each "my QTH ID".

+ Every logged QSO specifies a "my QTH ID"; typically, the operator sets DXKeeper's "Default my QTH ID" to the unique ID for the "my QTH" from which he or she is currently making QSOs.

+ When importing an ADIF or tab-delimited file, the user can specify a "my QTH ID" to be assigned to each imported QSO.


+ At present, DXKeeper ignores the MY_GRIDSQUARE, MY_CNTY, MY_STATE, and MY_COUNTRY ADIF fields. If you extend N1MM to emit these fields - using ADIF-compliant values -- for each QSO, then I will extend DXKeeper to (optionally) do the following when it encounters all 4 of these fields in an ADIF record being processed:

1. look for an already-defined "my QTH" consistent with the contents of the record's MY_GRIDSQUARE, MY_CNTY, MY_STATE, and MY_COUNTRY ADIF fields

2. if such a "my QTH" is found, the QSO will be imported with the "my QTH ID" for that "my QTH"

3. if no such "my QTH" is found, DXKeeper will

3a. define a new "my QTH", populating its grid square, secondary subdivision, primary subdivision, and country with the contents of the record's record's MY_GRIDSQUARE, MY_CNTY, MY_STATE, and MY_COUNTRY fields

3b. assign the newly-defined "my QTH" a "my QTH ID" of mobile_<MY_GRIDSQUARE> (e.g. mobile_FN42hj)

3c. import the QSO with the newly-defined "my QTH's" fabricated "my QTH ID".

+ If exporting ADIF-compliant values for MY_CNTY is a bridge too far, I suggest that you retain ADIF compliance by instead exporting state QSO party values in an N1MM-specific field like APP_N1MM_SQP_CNTY_CODE. I'll then organize a crowd-sourced project here to create a database that translates state QSO party county codes to ADIF-compliant county values.


+ Al, if we both make the changes suggested above, we'll please many ops who use N1MM and DXKeeper. There's a way to please even more: When N1MM is logging a QSO in contest X where the exchange includes an item of information for which an ADIF field is defined (e.g. CQ zone, ITU zone, grid square, US County, US State, ARRL Section), export that information in the appropriate ADIF field, as well as in the contest exchange field. N1MM supports many contests, so this likely cannot all be accomplished at once, but starting with the major contests would be a boon for the many ops chasing awards based on grids, counties, states, and zones.


+ Note to mobile DXLab users: WinWarbler already provides the ability to fabricate a mobile "my QTH ID" from a connected NMEA-compliant GPS. See

https://www.dxlabsuite.com/winwarbler/Help/LogSettings.htm#create%20mobile%20myQTHID


73,

Dave, AA6YQ


Alan N5NA
 

Just a couple of comments.  Dave stated:

+ At present, DXKeeper ignores the MY_GRIDSQUARE, MY_CNTY, MY_STATE, and MY_COUNTRY ADIF fields.

When I switched to DXLab earlier this year I imported thousands of state QSO party QSOs from hundreds of different counties creating a myQTH ID for each county.  I used a bulk search and replace program where I searched for the MY_CNTY tag that had the county abbreviation and replaced it with a string of ADIF tags.  Here's an example from the Texas QSO Party:

Search for <MY_CNTY:4>ANDR
Replace with <NOTES:16>TQP from Andrews<MY_STATE:2>TX<MY_CNTY:10>TX,Andrews<App_DXKeeper_My_QTHID:11>TQP-Andrews

So, DXKeeper DOES read the MY_CNTY and MY_STATE ADIF tags.

After importing my QSO party logs using the above method I ended up with close to 300 myQTH IDs.

1. look for an already-defined "my QTH" consistent with the contents of the record's MY_GRIDSQUARE, MY_CNTY, MY_STATE, and MY_COUNTRY ADIF fields

I think for a VHF rover the county is probably not going to be logged.  For a state QSO party the grid square is not going to be logged.  So requiring MY_GRIDSQUARE AND MY_CNTY may not be a good solution.

Having N1MM+ export MY_GRIDSQUARE or MY_CNTY would be a great enhancement.  Last fall I did a search and replace on my Texas QSO Party ADIF log putting the correctly formatted MY_CNTY in the log.  It was the easiest import of a QSO party log into LOTW I'd ever done.  Of course, right now the county is not used by any awards in LOTW but I like having the correct county I operated from in LOTW anyway.

73, Alan N5NA


Dave AA6YQ
 

@ AA6YQ comments below

+ At present, DXKeeper ignores the MY_GRIDSQUARE, MY_CNTY, MY_STATE, and MY_COUNTRY ADIF fields.

When I switched to DXLab earlier this year I imported thousands of state QSO party QSOs from hundreds of different counties creating a myQTH ID for each county. I used a bulk search and replace program where I searched for the MY_CNTY tag that had the county abbreviation and replaced it with a string of ADIF tags. Here's an example from the Texas QSO Party:

Search for <MY_CNTY:4>ANDR
Replace with <NOTES:16>TQP from Andrews<MY_STATE:2>TX<MY_CNTY:10>TX,Andrews<App_DXKeeper_My_QTHID:11>TQP-Andrews

So, DXKeeper DOES read the MY_CNTY and MY_STATE ADIF tags.

After importing my QSO party logs using the above method I ended up with close to 300 myQTH IDs.


@ Here's what the current version of DXKeeper does with MY_fields in imported ADIF files:

"When an imported ADIF record contains an APP_DXKEEPER_MY_QTHID tag, the associated myQTH ID is placed in the imported QSO's myQTH ID item. If the log contains no QTH definition that specifies the imported myQTH ID, then a new QTH definition is created, and assigned this myQTH ID. If the imported ADIF record contains any of the following ADIF 2.0 tags, their associated data is used to populated the newly-created QTH definition: MY_CITY, MY_CNTY, MY_COUNTRY, MY_CQZONE, MY_GRIDSQUARE, MY_IOTA, MY_ITUZONE, MY_LAT, MY_LON, MY_POSTAL_CODE, MY_STATE, and MY_STREET."

https://www.dxlabsuite.com/dxkeeper/Help/Import.htm


@ Thus most of what I proposed implementing in

https://groups.io/g/DXLab/message/200409

@ is in fact already implemented. All that's needed is to provide the option to handle an ADIF record with no APP_DXKEEPER_MY_QTHID tag by optionally fabricating a "my QTH ID" from the content of MY_GRIDSQUARE.



+ 1. look for an already-defined "my QTH" consistent with the contents of the record's MY_GRIDSQUARE, MY_CNTY, MY_STATE, and MY_COUNTRY ADIF fields

I think for a VHF rover the county is probably not going to be logged. For a state QSO party the grid square is not going to be logged. So requiring MY_GRIDSQUARE AND MY_CNTY may not be a good solution.

@ I'll have to work through call of the permutations, but I suspect there's a reasonable way to handle every scenario with either MY_GRIDSQUARE specified, or MY_COUNTRY and one of MY_STATE or MY_CNTY specified.

@ Thanks, Alan!

73,

Dave, AA6YQ


AB2ZY
 

Dave AA6YQ:

I've come around to the same point on my own.

The next release (tomorrow) of N1MM will export the rover grid square with the MY_GRIDSQUARE ADIF tag. For those that import directly to LoTW using ADIF fed into TQSL, that will relieve them of the necessity of creating separate logs. You (DXLab) may choose to do with that tag as you wish at your chosen pace.

I agree regarding the counties. I'm unwilling to hijack an ADIF field that has a defined specification. An APP specific tag (e.g. APP_N!MM_ROVERCNTY) where I can spit out whatever was recorded for the country abbreviation is about as far as I'm willing to go. We definitely do not want to get into the business of maintaining non contest related information, i.e. the mapping of state QSO part county abbreviations to ADIF enumerations. Maybe AD1C could provide a web component that could be called from an application or something similar so that the functionality could be incorporated without requiring every app developer to maintain the ever changing database.

Best regards,

Al
AB2ZY


Joe Subich, W4TV
 

Al,

The next release (tomorrow) of N1MM will export the rover grid
square with the MY_GRIDSQUARE ADIF tag.
Don't forget, the MY_GRIDSUARE tag needs to handle up to four grids.

We definitely do not want to get into the business of maintaining non
contest related information, i.e. the mapping of state QSO part
county abbreviations to ADIF enumerations.
You have the additional issue of dealing with independent cities ...
I don't know if Virginia, Nevada, etc. use the independent cities
as multipliers along with counties. LotW allows the upload of the
independent city as MY_COUNTY even though ADIF does not recognize
them and the award sponsor requires that the applicant select *one*
adjacent country.

Maybe AD1C could provide a web component that could be called from an
application or something similar so that the functionality could be
incorporated without requiring every app developer to maintain the
ever changing database.
I believe AD1C already has an application that will read an ADIF file
and replace app specific tags (e.g. APP_N1MM_ECH#:SEM) with the standard
<MY_COUNTY:11>FL,SEMINOLE

73,

... Joe, W4TV


On 2021-03-15 7:11 PM, AB2ZY wrote:
Dave AA6YQ:
I've come around to the same point on my own.
The next release (tomorrow) of N1MM will export the rover grid square with the MY_GRIDSQUARE ADIF tag. For those that import directly to LoTW using ADIF fed into TQSL, that will relieve them of the necessity of creating separate logs. You (DXLab) may choose to do with that tag as you wish at your chosen pace.
I agree regarding the counties. I'm unwilling to hijack an ADIF field that has a defined specification. An APP specific tag (e.g. APP_N!MM_ROVERCNTY) where I can spit out whatever was recorded for the country abbreviation is about as far as I'm willing to go. We definitely do not want to get into the business of maintaining non contest related information, i.e. the mapping of state QSO part county abbreviations to ADIF enumerations. Maybe AD1C could provide a web component that could be called from an application or something similar so that the functionality could be incorporated without requiring every app developer to maintain the ever changing database.
Best regards,
Al
AB2ZY


ve3ki
 

"Don't forget, the MY_GRIDSUARE tag needs to handle up to four grids." -- The ADIF specification does not allow for multiple values in a single field. N1MM+ handles this grid boundary situation by creating up to four separate ADIF records (actually, up to 16 separate records if the other station is also on a grid boundary). Al's update wouldn't change this - it will simply duplicate the existing APP_N1MM_RoverQth field contents in MY_GRIDSQUARE.

The AD1C County Conversion app replaces the APP_N1MM_EXCH1 field containing a contest county abbreviation with an ADIF-compliant CNTY field, but AFAIK it does not do anything with the APP_N1MM_RoverQth field (or, of course, any new fields that duplicate it).

73,
Rich VE3KI


73,
Rich VE3KI


On Mon, Mar 15, 2021 at 07:48 PM, Joe Subich, W4TV wrote:
Al,

The next release (tomorrow) of N1MM will export the rover grid
square with the MY_GRIDSQUARE ADIF tag.
Don't forget, the MY_GRIDSUARE tag needs to handle up to four grids.

We definitely do not want to get into the business of maintaining non
contest related information, i.e. the mapping of state QSO part
county abbreviations to ADIF enumerations.
You have the additional issue of dealing with independent cities ...
I don't know if Virginia, Nevada, etc. use the independent cities
as multipliers along with counties. LotW allows the upload of the
independent city as MY_COUNTY even though ADIF does not recognize
them and the award sponsor requires that the applicant select *one*
adjacent country.

Maybe AD1C could provide a web component that could be called from an
application or something similar so that the functionality could be
incorporated without requiring every app developer to maintain the
ever changing database.
I believe AD1C already has an application that will read an ADIF file
and replace app specific tags (e.g. APP_N1MM_ECH#:SEM) with the standard
<MY_COUNTY:11>FL,SEMINOLE

73,

... Joe, W4TV


On 2021-03-15 7:11 PM, AB2ZY wrote:
Dave AA6YQ:

I've come around to the same point on my own.

The next release (tomorrow) of N1MM will export the rover grid square with the MY_GRIDSQUARE ADIF tag. For those that import directly to LoTW using ADIF fed into TQSL, that will relieve them of the necessity of creating separate logs. You (DXLab) may choose to do with that tag as you wish at your chosen pace.

I agree regarding the counties. I'm unwilling to hijack an ADIF field that has a defined specification. An APP specific tag (e.g. APP_N!MM_ROVERCNTY) where I can spit out whatever was recorded for the country abbreviation is about as far as I'm willing to go. We definitely do not want to get into the business of maintaining non contest related information, i.e. the mapping of state QSO part county abbreviations to ADIF enumerations. Maybe AD1C could provide a web component that could be called from an application or something similar so that the functionality could be incorporated without requiring every app developer to maintain the ever changing database.

Best regards,

Al
AB2ZY






Joe Subich, W4TV
 

The ADIF specification does not allow for multiple values in a single
field.
Correct. The proper ADIF tag is <MY_VUCC_GRIDS> which handles up to
four grids.

N1MM+ handles this grid boundary situation by creating up to four separate ADIF records (actually, up to 16 separate records if the other station is also on a grid boundary).
That is problematic with LotW as successive QSOs will overwrite data
if the time is the same and can result in failure to receive credit
if the non-rover only uploads a single QSO. The proper tag is <MY_VUCC_GRIDS> as that will populate Grid, Grid_2, Grid_3, and Grid_4
in the LotW/tQSL Station Location structure and result in full credit
for one, two or four grids.

The AD1C County Conversion app replaces the APP_N1MM_EXCH1 field containing a contest county abbreviation with an ADIF-compliant CNTY
field, but AFAIK it does not do anything with the APP_N1MM_RoverQth field (or, of course, any new fields that duplicate it).
I assume Jim would be happily to extend the AD1C County Conversion app
to convert the sent exchange to MY_CNTY if the Sent exchange is in a
convenient APP tag.

73,

... Joe, W4TV


On 2021-03-15 8:10 PM, ve3ki wrote:
"Don't forget, the MY_GRIDSUARE tag needs to handle up to four grids." -- The ADIF specification does not allow for multiple values in a single field. N1MM+ handles this grid boundary situation by creating up to four separate ADIF records (actually, up to 16 separate records if the other station is also on a grid boundary). Al's update wouldn't change this - it will simply duplicate the existing APP_N1MM_RoverQth field contents in MY_GRIDSQUARE.
The AD1C County Conversion app replaces the APP_N1MM_EXCH1 field containing a contest county abbreviation with an ADIF-compliant CNTY field, but AFAIK it does not do anything with the APP_N1MM_RoverQth field (or, of course, any new fields that duplicate it).
73,
Rich VE3KI
73,
Rich VE3KI
On Mon, Mar 15, 2021 at 07:48 PM, Joe Subich, W4TV wrote:


Al,


The next release (tomorrow) of N1MM will export the rover grid
square with the MY_GRIDSQUARE ADIF tag.
Don't forget, the MY_GRIDSUARE tag needs to handle up to four grids.


We definitely do not want to get into the business of maintaining non
contest related information, i.e. the mapping of state QSO part
county abbreviations to ADIF enumerations.
You have the additional issue of dealing with independent cities ...
I don't know if Virginia, Nevada, etc. use the independent cities
as multipliers along with counties. LotW allows the upload of the
independent city as MY_COUNTY even though ADIF does not recognize
them and the award sponsor requires that the applicant select *one*
adjacent country.


Maybe AD1C could provide a web component that could be called from an
application or something similar so that the functionality could be
incorporated without requiring every app developer to maintain the
ever changing database.
I believe AD1C already has an application that will read an ADIF file
and replace app specific tags (e.g. APP_N1MM_ECH#:SEM) with the standard
<MY_CNTY:11>FL,SEMINOLE

73,

... Joe, W4TV


On 2021-03-15 7:11 PM, AB2ZY wrote:

Dave AA6YQ:

I've come around to the same point on my own.

The next release (tomorrow) of N1MM will export the rover grid square with
the MY_GRIDSQUARE ADIF tag. For those that import directly to LoTW using
ADIF fed into TQSL, that will relieve them of the necessity of creating
separate logs. You (DXLab) may choose to do with that tag as you wish at
your chosen pace.

I agree regarding the counties. I'm unwilling to hijack an ADIF field that
has a defined specification. An APP specific tag (e.g. APP_N!MM_ROVERCNTY)
where I can spit out whatever was recorded for the country abbreviation is
about as far as I'm willing to go. We definitely do not want to get into
the business of maintaining non contest related information, i.e. the
mapping of state QSO part county abbreviations to ADIF enumerations. Maybe
AD1C could provide a web component that could be called from an
application or something similar so that the functionality could be
incorporated without requiring every app developer to maintain the ever
changing database.

Best regards,

Al
AB2ZY






Dave AA6YQ
 

+ AA6YQ comments below

The next release (tomorrow) of N1MM will export the rover grid square with the MY_GRIDSQUARE ADIF tag. For those that import directly to LoTW using ADIF fed into TQSL, that will relieve them of the necessity of creating separate logs. You (DXLab) may choose to do with that tag as you wish at your chosen pace.

I agree regarding the counties. I'm unwilling to hijack an ADIF field that has a defined specification. An APP specific tag (e.g. APP_N!MM_ROVERCNTY) where I can spit out whatever was recorded for the country abbreviation is about as far as I'm willing to go. We definitely do not want to get into the business of maintaining non contest related information, i.e. the mapping of state QSO part county abbreviations to ADIF enumerations. Maybe AD1C could provide a web component that could be called from an application or something similar so that the functionality could be incorporated without requiring every app developer to maintain the ever changing database.

+ Besides MY_GRIDSQUARE and APP_N1MM_ROVERCNTY, what other MY_ fields should DXLab look for in N1MM-emitted ADIF?

+ Please attach a representative N1MM-generated ADIF file to an email message, and send the message to me via

aa6yq (at) ambersoft.com

+ thanks!

73,

Dave, AA6YQ


Dave AA6YQ
 

+ AA6YQ comments below

Alan N5NA wrote:

When I switched to DXLab earlier this year I imported thousands of state QSO party QSOs from hundreds of different counties creating a myQTH ID for each county.  I used a bulk search and replace program where I searched for the MY_CNTY tag that had the county abbreviation and replaced it with a string of ADIF tags.

+ The next version of DXKeeper provides a new "Create mobile myQTHID" option on the Main window's "Import QSOs" tab. If you haven't specified a myQTHID on this tab's "Substitution options" panel, and you've enabled the new "Create mobile myQTHID" option, and DXKeeper encounters an ADIF record that doesn't specify an App_DXKeeper_My_QTHID, then if the forthcoming new version of N1MM has included a MY_GRIDSQUARE field that specifies CM87,  then DXKeeper will import the record with a myQTHID of

mobile_FN42

+ The question is what to do if there's no MY_GRIDSQUARE field in the record. If a MY_CNTY were reliably present (is it?), that could be used -- but the problem is that these are ambiguous. QSOs made in the PA and VA State QSO Parties could specify <MY_CNTY:3>LAN. The only way I can see to reliably disambiguate this would be to also include the contents of the CONTEST-ID field. Were I to do that, a fabricated myQTHID could look like

mobile_PA-QSO-PARTY_LAN

+ Comments? Better ideas?

      73,

            Dave, AA6YQ


Dave AA6YQ
 

To be clear, there are two independent challenges when importing contest logs:

1. Importing a contest log created by a roving station that contains QSOs made from several -- possibly many -- different locations. This prevents the user from importing the log by specifying a single myQTHID to be applied to each imported QSO. Ideally, DXKeeper would independently fabricate an appropriate myQTHID for each imported QSO, eliminating the need for the roving user to do that with filtering and mass modification operations.

2. Dealing with the non-standard county abbreviations used in State QSO Party contests so that ops pursuing USACA ("Worked all US Counties") and WAS ("Worked all US States") would have logged QSOs that accurately specify a US state and county. As has been pointed out, Jim AD1C maintains an application that translates non-standard County abbreviations in an ADIF file to standard County abbreviations in an ADIF file; ideally, the need to pre-process and ADIF file before importing it into DXKeeper could be eliminated. I am in discussion with Jim.

73,

Dave, AA6YQ



+ AA6YQ comments below

Alan N5NA wrote:

When I switched to DXLab earlier this year I imported thousands of state QSO party QSOs from hundreds of different counties creating a myQTH ID for each county. I used a bulk search and replace program where I searched for the MY_CNTY tag that had the county abbreviation and replaced it with a string of ADIF tags.

+ The next version of DXKeeper provides a new "Create mobile myQTHID"
+ option on the Main window's "Import QSOs" tab. If you haven't
+ specified a myQTHID on this tab's "Substitution options" panel, and
+ you've enabled the new "Create mobile myQTHID" option, and DXKeeper
+ encounters an ADIF record that doesn't specify an
+ App_DXKeeper_My_QTHID, then if the forthcoming new version of N1MM has
+ included a MY_GRIDSQUARE field that specifies CM87, then DXKeeper
+ will import the record with a myQTHID of

mobile_FN42

+ The question is what to do if there's no MY_GRIDSQUARE field in the
+ record. If a MY_CNTY were reliably present (is it?), that could be
+ used -- but the problem is that these are ambiguous. QSOs made in the
+ PA and VA State QSO Parties could specify <MY_CNTY:3>LAN. The only way
+ I can see to reliably disambiguate this would be to also include the
+ contents of the CONTEST-ID field. Were I to do that, a fabricated
+ myQTHID could look like

mobile_PA-QSO-PARTY_LAN

+ Comments? Better ideas?

73,

Dave, AA6YQ


Alan N5NA
 

On Tue, Mar 16, 2021 at 07:21 PM, Dave AA6YQ wrote:
+ The question is what to do if there's no MY_GRIDSQUARE field in the
+ record. If a MY_CNTY were reliably present (is it?), that could be
+ used -- but the problem is that these are ambiguous. QSOs made in the
+ PA and VA State QSO Parties could specify <MY_CNTY:3>LAN. The only way
+ I can see to reliably disambiguate this would be to also include the
+ contents of the CONTEST-ID field. Were I to do that, a fabricated
+ myQTHID could look like


mobile_PA-QSO-PARTY_LAN

+ Comments? Better ideas?
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.  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.

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.  

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?


ve3ki
 

The Documents/N1MM+/MultChaser directory you mentioned was not created by N1MM+. In all likelihood it, along with all of the files it contains, came from a third-party program.

73,
Rich VE3KI


On Tue, Mar 16, 2021 at 11:07 PM, Alan Sewell wrote:
On Tue, Mar 16, 2021 at 07:21 PM, Dave AA6YQ wrote:
+ The question is what to do if there's no MY_GRIDSQUARE field in the
+ record. If a MY_CNTY were reliably present (is it?), that could be
+ used -- but the problem is that these are ambiguous. QSOs made in the
+ PA and VA State QSO Parties could specify <MY_CNTY:3>LAN. The only way
+ I can see to reliably disambiguate this would be to also include the
+ contents of the CONTEST-ID field. Were I to do that, a fabricated
+ myQTHID could look like


mobile_PA-QSO-PARTY_LAN

+ Comments? Better ideas?
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.  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.

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.  

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?


Dave AA6YQ
 

+ 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


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


Dave AA6YQ
 

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

+ During the weekend you cite, would operators QRV from counties in different states give the same county code?

       73,

               Dave, AA6YQ


Joe Subich, W4TV
 

+ During the weekend you cite, would operators QRV from counties in
different states give the same county code?
The 7QP participants use a county code/exchange that includes state
and county. I have not researched if there is any overlap between
the other two states.

73,

... Joe, W4TV


On 2021-03-17 10:59 PM, Dave AA6YQ wrote:
+ AA6YQ comments below
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.
+ During the weekend you cite, would operators QRV from counties in different states give the same county code?
       73,
               Dave, AA6YQ


Scott Stembaugh
 

Actually there are 4 QPs that weekend, 7qp, inqp, neqp, and Delaware qp. 
7qp and inqp use state/county, neqp uses county/state, and DEQP uses a completely different exchange - NDE (New Castle), KDE (Kent County), and SDE (Suffix county)  

On Thu, Mar 18, 2021, 09:04 Joe Subich, W4TV <lists@...> wrote:

 > + During the weekend you cite, would operators QRV from counties in
 > different states give the same county code?

The 7QP participants use a county code/exchange that includes state
and county.  I have not researched if there is any overlap between
the other two states.

73,

    ... Joe, W4TV


On 2021-03-17 10:59 PM, Dave AA6YQ wrote:
> + AA6YQ comments below
>
>     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.
>
> + During the weekend you cite, would operators QRV from counties in
> different states give the same county code?
>
>         73,
>
>                 Dave, AA6YQ







Dave AA6YQ
 

+ AA6YQ comments below
Actually there are 4 QPs that weekend, 7qp, inqp, neqp, and Delaware qp. 
7qp and inqp use state/county, neqp uses county/state, and DEQP uses a completely different exchange - NDE (New Castle), KDE (Kent County), and SDE (Suffix county)

+ So then there's no ambiguity. Thanks, Scott!

      73,

           Dave, AA6YQ