DXLab support for impending changes to ADIF


Dave AA6YQ
 

Those of us who vote on proposed changes to ADIF recently approved the following 5 changes in the forthcoming ADIF 3.1.4. I voted in
support of all of these changes, but that doesn't mean that DXKeeper should implement them. Here's my current thinking:

1. Add support for 10 and 12 character locators

- This would be straightforward to implement, but over the last 21 years, no one has requested the ability to log grid squares with
more than 8 characters of precision. I'll wait until there's an articulated need from the user community.


2. Add SUBMM to the Band enumeration

- DXKeeper's DefaultBands.txt file already defines SUBMM with this entry (band name, lower frequency MHz, upper frequency MHz):

SUBMM, 300000,1000000

- ADIF 3.1.4 will define it as

SUBMM, 300000, 75000000000

- The DefaultBands.txt file in the next version of DXKeeper will employ the ADIF 3.1.4 definition.


3. Add Parks on the Air fields POTA_REF and MY_POTA_REF

4. Add fields ALTITUDE and MY_ALTITUDE to represent an aircraft's altitude

- DXKeeper provides 8 user-defined items. Each of these items can be configured to import and export an ADIF field not otherwise
supported by DXKeeper, as described in

https://www.dxlabsuite.com/dxkeeper/Help/Configuration.htm#User%20Items%20tab

- DXKeeper can also generate a basic progress report from the information in a specified user-defined field:

https://www.dxlabsuite.com/dxkeeper/Help/Progress.htm#User

- All four of these new fields can be supported with DXKeeper's user-defined fields mechanism, if desired. Thus no change is
planned.


5. Add HAMQTH and HAMLOG fields to track confirmations via these online services

- These fields support confirmation tracking for the HamQTH and HamLog online services. Since confirmations for these services
aren't valid for ARRL or CQ awards, providing LoTW-like or eQSL-like automation is not justified.


If you disagree with any of the above, please post an explanation here. Thanks!

73,

Dave, AA6YQ


CSM\(r\) Gary Huber - AB9M
 

I don't believe this is a disagreement but given the size of an eight-character grid, I can see where an eight-character grid encompasses a boundary such as between two zones, states or provinces, or other entities, additional granularity from 10 or 12 characters could precisely identify which zone, state, province, or entity of the operation. 

73 & DX,
Gary ~ AB9M

From: DXLab@groups.io <DXLab@groups.io> on behalf of Dave AA6YQ <aa6yq@...>
Sent: Saturday, October 8, 2022 5:30 PM
To: DXLab@groups.io <DXLab@groups.io>
Cc: Graham G3ZOD <g3zod@...>
Subject: [DXLab] DXLab support for impending changes to ADIF
 
Those of us who vote on proposed changes to ADIF recently approved the following 5 changes in the forthcoming ADIF 3.1.4. I voted in
support of all of these changes, but that doesn't mean that DXKeeper should implement them. Here's my current thinking:

1. Add support for 10 and 12 character locators

-  This would be straightforward to implement, but over the last 21 years, no one has requested the ability to log grid squares with
more than 8 characters of precision. I'll wait until there's an articulated need from the user community.


2. Add SUBMM to the Band enumeration

- DXKeeper's DefaultBands.txt file already defines SUBMM with this entry (band name, lower frequency MHz, upper frequency MHz):

SUBMM, 300000,1000000

- ADIF 3.1.4 will define it as

SUBMM, 300000, 75000000000

- The DefaultBands.txt file in the next version of DXKeeper will employ the ADIF 3.1.4 definition.


3. Add Parks on the Air fields POTA_REF and MY_POTA_REF

4. Add fields ALTITUDE and MY_ALTITUDE to represent an aircraft's altitude

- DXKeeper provides 8 user-defined items. Each of these items can be configured to import and export an ADIF field not otherwise
supported by DXKeeper, as described in

https://www.dxlabsuite.com/dxkeeper/Help/Configuration.htm#User%20Items%20tab

- DXKeeper can also generate a basic progress report from the information in a specified user-defined field:

https://www.dxlabsuite.com/dxkeeper/Help/Progress.htm#User

- All four of these new fields can be supported with DXKeeper's user-defined fields mechanism, if desired. Thus no change is
planned.


5. Add HAMQTH and HAMLOG fields to track confirmations via these online services

- These fields support confirmation tracking for the HamQTH and HamLog online services. Since confirmations for these services
aren't valid for ARRL or CQ awards, providing LoTW-like or eQSL-like automation is not justified.


If you disagree with any of the above, please post an explanation here. Thanks!

         73,

               Dave, AA6YQ










Dave AA6YQ
 

+ AA6YQ comments below

I don't believe this is a disagreement but given the size of an eight-character grid, I can see where an eight-character grid
encompasses a boundary such as between two zones, states or provinces, or other entities, additional granularity from 10 or 12
characters could precisely identify which zone, state, province, or entity of the operation.

+ It seems unlikely that your QSO partner could specify their grid square to 10 or 12 characters of precision but not be able to
convey their zone, state, province, or entity.

73,

Dave, AA6YQ


Bruce N7XGR
 

Dave Here is where a more exact grid square is used,
2022-10-08 10:48:24 EDT: W5KUB-112>APRS,TCPIP*,qAS,W5KUB:/144819h4541.25N/00207.50EO089/031/A=048097 11 Sats 2.10V 14660m JN15BQ 1L8EBQ W5KUB http://www.w5kub.com/ 3055

Notice this,   JN15BQ 1L8EBQ
This has been used to find balloons because of this location can be found easily.

This one has now made two trips around the Earth at 48,000 feet at different speeds
launched from near Memphis, TN.

Bruce  N7XGR

On Sun, Oct 9, 2022 at 12:14 AM Dave AA6YQ <aa6yq@...> wrote:
+ AA6YQ comments below

I don't believe this is a disagreement but given the size of an eight-character grid, I can see where an eight-character grid
encompasses a boundary such as between two zones, states or provinces, or other entities, additional granularity from 10 or 12
characters could precisely identify which zone, state, province, or entity of the operation.

+ It seems unlikely that your QSO partner could specify their grid square to 10 or 12 characters of precision but not be able to
convey their zone, state, province, or entity.

        73,

             Dave, AA6YQ







Gilbert Baron W0MN
 

Not true. It would have a better chance to do that but unless you have an infinite number of characters you could ALWAYS INCLUDE MORE THAN ONE PLACE.

 

Outlook LT Gil W0MN

Hierro Candente Batir de Repente

44.08226 N 92.51265 W EN34rb

 

 

From: DXLab@groups.io <DXLab@groups.io> On Behalf Of CSM\(r\) Gary Huber - AB9M
Sent: Saturday, October 8, 2022 10:05 PM
To: DXLab@groups.io
Subject: Re: [DXLab] DXLab support for impending changes to ADIF

 

I don't believe this is a disagreement but given the size of an eight-character grid, I can see where an eight-character grid encompasses a boundary such as between two zones, states or provinces, or other entities, additional granularity from 10 or 12 characters could precisely identify which zone, state, province, or entity of the operation. 

 

73 & DX,

Gary ~ AB9M


From: DXLab@groups.io <DXLab@groups.io> on behalf of Dave AA6YQ <aa6yq@...>
Sent: Saturday, October 8, 2022 5:30 PM
To: DXLab@groups.io <DXLab@groups.io>
Cc: Graham G3ZOD <g3zod@...>
Subject: [DXLab] DXLab support for impending changes to ADIF

 

Those of us who vote on proposed changes to ADIF recently approved the following 5 changes in the forthcoming ADIF 3.1.4. I voted in
support of all of these changes, but that doesn't mean that DXKeeper should implement them. Here's my current thinking:

1. Add support for 10 and 12 character locators

-  This would be straightforward to implement, but over the last 21 years, no one has requested the ability to log grid squares with
more than 8 characters of precision. I'll wait until there's an articulated need from the user community.


2. Add SUBMM to the Band enumeration

- DXKeeper's DefaultBands.txt file already defines SUBMM with this entry (band name, lower frequency MHz, upper frequency MHz):

SUBMM, 300000,1000000

- ADIF 3.1.4 will define it as

SUBMM, 300000, 75000000000

- The DefaultBands.txt file in the next version of DXKeeper will employ the ADIF 3.1.4 definition.


3. Add Parks on the Air fields POTA_REF and MY_POTA_REF

4. Add fields ALTITUDE and MY_ALTITUDE to represent an aircraft's altitude

- DXKeeper provides 8 user-defined items. Each of these items can be configured to import and export an ADIF field not otherwise
supported by DXKeeper, as described in

https://www.dxlabsuite.com/dxkeeper/Help/Configuration.htm#User%20Items%20tab

- DXKeeper can also generate a basic progress report from the information in a specified user-defined field:

https://www.dxlabsuite.com/dxkeeper/Help/Progress.htm#User

- All four of these new fields can be supported with DXKeeper's user-defined fields mechanism, if desired. Thus no change is
planned.


5. Add HAMQTH and HAMLOG fields to track confirmations via these online services

- These fields support confirmation tracking for the HamQTH and HamLog online services. Since confirmations for these services
aren't valid for ARRL or CQ awards, providing LoTW-like or eQSL-like automation is not justified.


If you disagree with any of the above, please post an explanation here. Thanks!

         73,

               Dave, AA6YQ









--

W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop


Joe Subich, W4TV
 

On 2022-10-08 11:04 PM, CSM&#92;(r&#92;) Gary Huber - AB9M wrote:
I don't believe this is a disagreement but given the size of an eight-character grid, I can see where an eight-character grid encompasses a boundary such as between two zones, states or provinces, or other entities, additional granularity from 10 or 12 characters could precisely identify which zone, state, province, or
entity of the operation.
DXKeeper already provides a means to record zones, and primary
administrative divisions. Since those boarders do not follow
latitude/longitude lines (they often follow rivers or other
geographic features) and there is no readily available databases
that map those features to grid squares (even at 10 or 12 character
resolution) recording 10 or 12 character grids, and requiring every
QSO entry in every user log to be expanded by 8 additional bytes is
not warranted.

73,

... Joe, W4TV

On 2022-10-08 11:04 PM, CSM&#92;(r&#92;) Gary Huber - AB9M wrote:
I don't believe this is a disagreement but given the size of an eight-character grid, I can see where an eight-character grid encompasses a boundary such as between two zones, states or provinces, or other entities, additional granularity from 10 or 12 characters could precisely identify which zone, state, province, or entity of the operation.
73 & DX,
Gary ~ AB9M
________________________________
From: DXLab@groups.io <DXLab@groups.io> on behalf of Dave AA6YQ <aa6yq@...>
Sent: Saturday, October 8, 2022 5:30 PM
To: DXLab@groups.io <DXLab@groups.io>
Cc: Graham G3ZOD <g3zod@...>
Subject: [DXLab] DXLab support for impending changes to ADIF
Those of us who vote on proposed changes to ADIF recently approved the following 5 changes in the forthcoming ADIF 3.1.4. I voted in
support of all of these changes, but that doesn't mean that DXKeeper should implement them. Here's my current thinking:
1. Add support for 10 and 12 character locators
- This would be straightforward to implement, but over the last 21 years, no one has requested the ability to log grid squares with
more than 8 characters of precision. I'll wait until there's an articulated need from the user community.
2. Add SUBMM to the Band enumeration
- DXKeeper's DefaultBands.txt file already defines SUBMM with this entry (band name, lower frequency MHz, upper frequency MHz):
SUBMM, 300000,1000000
- ADIF 3.1.4 will define it as
SUBMM, 300000, 75000000000
- The DefaultBands.txt file in the next version of DXKeeper will employ the ADIF 3.1.4 definition.
3. Add Parks on the Air fields POTA_REF and MY_POTA_REF
4. Add fields ALTITUDE and MY_ALTITUDE to represent an aircraft's altitude
- DXKeeper provides 8 user-defined items. Each of these items can be configured to import and export an ADIF field not otherwise
supported by DXKeeper, as described in
https://www.dxlabsuite.com/dxkeeper/Help/Configuration.htm#User%20Items%20tab
- DXKeeper can also generate a basic progress report from the information in a specified user-defined field:
https://www.dxlabsuite.com/dxkeeper/Help/Progress.htm#User
- All four of these new fields can be supported with DXKeeper's user-defined fields mechanism, if desired. Thus no change is
planned.
5. Add HAMQTH and HAMLOG fields to track confirmations via these online services
- These fields support confirmation tracking for the HamQTH and HamLog online services. Since confirmations for these services
aren't valid for ARRL or CQ awards, providing LoTW-like or eQSL-like automation is not justified.
If you disagree with any of the above, please post an explanation here. Thanks!
73,
Dave, AA6YQ


Rich K3VAT
 

Bravo! for including #3 - POTA additions, which is gaining more and more popularity.  TU Dave and Team.  73 Rich, K3VAT


Dave AA6YQ
 

+ AA6YQ comments below
Dave Here is where a more exact grid square is used,
2022-10-08 10:48:24 EDT: W5KUB-112>APRS,TCPIP*,qAS,W5KUB:/144819h4541.25N/00207.50EO089/031/A=048097 11 Sats 2.10V 14660m JN15BQ 1L8EBQ W5KUB http://www.w5kub.com/ 3055
 
Notice this,   JN15BQ 1L8EBQ
This has been used to find balloons because of this location can be found easily.

JN15BQ 1L8EBQ is not a valid 12-character grid square; in a grid square, the pairs or characters alternate between letters and numbers.

+ How frequently are balloons launched and recovered?

      73,

          Dave, AA6YQ


Anthony W. DePrato
 


97% of the ham population does not use grid sq's above 4 places
only 3% of the pop is even interested in APRS or tracking balloons. it is great that a few hams do like this as ham radio has a very large spread out interest coverage.
73 tony wa4jqs

At 01:41 AM 10/9/2022, you wrote:
Dave Here is where a more exact grid square is used,
2022-10-08 10:48:24 EDT: W5KUB-112 >APRS,TCPIP*,qAS, W5KUB:/144819h4541.25N/00207.50EO089/031/A=048097 11 Sats 2.10V 14660m JN15BQ 1L8EBQ W5KUB http://www.w5kub.com/ 3055

Notice this,   JN15BQ 1L8EBQ
Which is used for this, https://aprs.fi/#!call=a%2FW5KUB-112&timerange=604800&tail=604800
This has been used to find balloons because of this location can be found easily.

This one has now made two trips around the Earth at 48,000 feet at different speeds
launched from near Memphis, TN.

Bruce  N7XGR

Anthony W. (Tony) DePrato
WA4JQS Since 1962
CQ DX HALL OF FAME #35
CALL'S Held
VP8SSI VP8BZL 3Y0PI ZD8JQS V31SS
WA4JQS /ZS1 WA4JQS/KC4 WA4JQS/4K1



w6de
 

Balloon tracking in an application for DX tracking? How many Balloon trackers use DXLabs? It can't be more than a fractional percentage of the DXLabs community.

73,
Dave, w6de

-----Original Message-----
From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Joe Subich, W4TV via groups.io
Sent: 9 October, 2022 13:30
To: DXLab@groups.io
Subject: Re: [DXLab] DXLab support for impending changes to ADIF


On 2022-10-08 11:04 PM, CSM&#92;(r&#92;) Gary Huber - AB9M wrote:
I don't believe this is a disagreement but given the size of an
eight-character grid, I can see where an eight-character grid
encompasses a boundary such as between two zones, states or provinces,
or other entities, additional granularity from 10 or 12 characters
could precisely identify which zone, state, province, or entity of the
operation.
DXKeeper already provides a means to record zones, and primary administrative divisions. Since those boarders do not follow latitude/longitude lines (they often follow rivers or other geographic features) and there is no readily available databases that map those features to grid squares (even at 10 or 12 character
resolution) recording 10 or 12 character grids, and requiring every QSO entry in every user log to be expanded by 8 additional bytes is not warranted.

73,

... Joe, W4TV

On 2022-10-08 11:04 PM, CSM&#92;(r&#92;) Gary Huber - AB9M wrote:
I don't believe this is a disagreement but given the size of an eight-character grid, I can see where an eight-character grid encompasses a boundary such as between two zones, states or provinces, or other entities, additional granularity from 10 or 12 characters could precisely identify which zone, state, province, or entity of the operation.

73 & DX,
Gary ~ AB9M
________________________________
From: DXLab@groups.io <DXLab@groups.io> on behalf of Dave AA6YQ
<aa6yq@...>
Sent: Saturday, October 8, 2022 5:30 PM
To: DXLab@groups.io <DXLab@groups.io>
Cc: Graham G3ZOD <g3zod@...>
Subject: [DXLab] DXLab support for impending changes to ADIF

Those of us who vote on proposed changes to ADIF recently approved the
following 5 changes in the forthcoming ADIF 3.1.4. I voted in support of all of these changes, but that doesn't mean that DXKeeper should implement them. Here's my current thinking:

1. Add support for 10 and 12 character locators

- This would be straightforward to implement, but over the last 21
years, no one has requested the ability to log grid squares with more than 8 characters of precision. I'll wait until there's an articulated need from the user community.


2. Add SUBMM to the Band enumeration

- DXKeeper's DefaultBands.txt file already defines SUBMM with this entry (band name, lower frequency MHz, upper frequency MHz):

SUBMM, 300000,1000000

- ADIF 3.1.4 will define it as

SUBMM, 300000, 75000000000

- The DefaultBands.txt file in the next version of DXKeeper will employ the ADIF 3.1.4 definition.


3. Add Parks on the Air fields POTA_REF and MY_POTA_REF

4. Add fields ALTITUDE and MY_ALTITUDE to represent an aircraft's
altitude

- DXKeeper provides 8 user-defined items. Each of these items can be
configured to import and export an ADIF field not otherwise supported
by DXKeeper, as described in

https://www.dxlabsuite.com/dxkeeper/Help/Configuration.htm#User%20Item
s%20tab

- DXKeeper can also generate a basic progress report from the information in a specified user-defined field:

https://www.dxlabsuite.com/dxkeeper/Help/Progress.htm#User

- All four of these new fields can be supported with DXKeeper's
user-defined fields mechanism, if desired. Thus no change is planned.


5. Add HAMQTH and HAMLOG fields to track confirmations via these
online services

- These fields support confirmation tracking for the HamQTH and HamLog
online services. Since confirmations for these services aren't valid for ARRL or CQ awards, providing LoTW-like or eQSL-like automation is not justified.


If you disagree with any of the above, please post an explanation here. Thanks!

73,

Dave, AA6YQ















Peter Laws / N5UWY
 

On Sat, Oct 8, 2022 at 5:31 PM Dave AA6YQ <aa6yq@...> wrote:


If you disagree with any of the above, please post an explanation here. Thanks!
"You didn't include this one thing that my 17 friends and I use and
now I hate DXLab!"

Lol.

I trust you to keep the Suite free of the really esoteric stuff (Like,
say, 12-char Maidenhead grid locators ... that 17 people use).

But I do have a question: Some of this stuff is in the ADIF spec
(which is fine) but if I import an ADIF file that has items that are
part of the ADIF spec but are not directly supported by DXKeeper
(whether these new ones or something in a previous rev of the spec),
what does the program do with that data?



--
Peter Laws | N5UWY / VE2UWY | plaws plaws net | Travel by Train!


Dave AA6YQ
 

+ AA6YQ comments below

Bravo! for including #3 - POTA additions, which is gaining more and more popularity.

+ DXKeeper has long provided the ability to utilize its 8 user-defined items to record information associated with ADIF fields not otherwise supported by DXKeeper -- like POTA. See this "how to" article by Mark AA3K:

https://www.dxlabsuite.com/dxlabwiki/UserAwardProgressreports

73,

Dave, AA6YQ


Dave AA6YQ
 

+ AA6YQ comments below

If you disagree with any of the above, please post an explanation here. Thanks!
"You didn't include this one thing that my 17 friends and I use and now I hate DXLab!"

+ How can you and your friends be using something that is not yet implemented?

But I do have a question: Some of this stuff is in the ADIF spec (which is fine) but if I import an ADIF file that has items that are part of the ADIF spec but are not directly supported by DXKeeper (whether these new ones or something in a previous rev of the spec), what does the program do with that data?

+ If the discussion here does not change thing plan I proposed here

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

+ then

1. the new GRIDSQUARE_EXT and MY_GRIDSQUARE_EXT fields conveying the 10th and 12th gridsquare pairs would be ignored if encountered in an ADIF file being imported or in an ADIF record received by DXKeeper from another application

2. the multiple new fields defined to track HamQTH and HamLog confirmation status would be ignored if encountered in an ADIF file being imported or in an ADIF record received by DXKeeper from another application

73,

Dave, AA6YQ


CSM&#92;(r&#92;) Gary Huber - AB9M
 

Dave, perhaps I should explain my initial email (and make apologies for starting all this).

I operate from EN50nk21 in its North-East quadrant. In fact, my eastern property line is along the EN50nk21 and EN50nk31 boundaries. While looking at the neighborhood via <Main - list and display SOTA summits on map - sotamaps.org> I realized that I have incorrectly used the wrong grid in the past and further that operators in many rural locations may have their rural mailbox (along a road or highway) while their station is in a different eight character grid.

Perhaps it is a similar situation when an FT8 station confirms a QSO and the LoTW grid and the actual grid are adjacent? A number DX confirmation comes to mind and I am never sure whether the FT8 grid or LoTW grid is correct

I can provide screenshots from Google Earth and sotamaps if you are interested.

73,
Gary ~ AB9M

From: DXLab@groups.io <DXLab@groups.io> on behalf of Dave AA6YQ <aa6yq@...>
Sent: Sunday, October 9, 2022 4:15 PM
To: DXLab@groups.io <DXLab@groups.io>
Cc: 'Graham G3ZOD' <g3zod@...>
Subject: Re: [DXLab] DXLab support for impending changes to ADIF
 
+ AA6YQ comments below

> If you disagree with any of the above, please post an explanation here. Thanks!

"You didn't include this one thing that my 17 friends and I use and now I hate DXLab!"

+ How can you and your friends be using something that is not yet implemented?

But I do have a question:  Some of this stuff is in the ADIF spec (which is fine) but if I import an ADIF file that has items that are part of the ADIF spec but are not directly supported by DXKeeper (whether these new ones or something in a previous rev of the spec), what does the program do with that data?

+ If the discussion here does not change thing plan I proposed here

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

+ then

1. the new GRIDSQUARE_EXT and MY_GRIDSQUARE_EXT  fields conveying the 10th and 12th gridsquare pairs would be ignored if encountered in an ADIF file being imported or in an ADIF record received by DXKeeper from another application

2. the multiple new fields defined to track HamQTH and HamLog confirmation status would be ignored if encountered in an ADIF file being imported or in an ADIF record received by DXKeeper from another application

     73,

             Dave, AA6YQ







Dave AA6YQ
 

+ AA6YQ comments below
Dave, perhaps I should explain my initial email (and make apologies for starting all this).
 
I operate from EN50nk21 in its North-East quadrant. In fact, my eastern property line is along the EN50nk21 and EN50nk31 boundaries. While looking at the neighborhood via <Main - list and display SOTA summits on map - sotamaps.org> I realized that I have incorrectly used the wrong grid in the past and further that operators in many rural locations may have their rural mailbox (along a road or highway) while their station is in a different eight character grid.
 
Perhaps it is a similar situation when an FT8 station confirms a QSO and the LoTW grid and the actual grid are adjacent? A number DX confirmation comes to mind and I am never sure whether the FT8 grid or LoTW grid is correct
 
I can provide screenshots from Google Earth and sotamaps if you are interested.

+ No apology is necessary, Gary. Critique and better ideas are always welcome here; in this case, I explicitly asked for comments.

+ Your comments above do not explain why more than 8 characters of precision are frequently necessary in a grid square:

1.  A 6-character grid square is accurate enough to compute the bearing to which to rotate a directional antenna.

2. I'm not aware of any awards based on grid squares with more than 6 characters of accuracy. VUCC, for example, only considers the first 6-characters of a grid square designator.

+ The "track my balloon" scenario would certainly benefit from increased precision, but is likely not common enough to justify an enhancement. 

        73,

              Dave, AA6YQ

 

 


Dave AA6YQ
 

On Sun, Oct 9, 2022 at 06:22 PM, Dave AA6YQ wrote:
I'm not aware of any awards based on grid squares with more than 6 characters of accuracy. VUCC, for example, only considers the first 6-characters of a grid square designator.

+ Correction: VUCC only considers the first 4 characters of a grid square designator; see

http://www.arrl.org/files/file/Awards/VUCC_Rules_February_2022.pdf

 

    73,

         Dave, AA6YQ


Joe Subich, W4TV
 

On 2022-10-09 9:22 PM, Dave AA6YQ wrote:

2. I'm not aware of any awards based on grid squares with more than 6
characters of accuracy. VUCC, for example, only considers the first 6-characters of a grid square designator.
VUCC only considers the first *four* characters of the grid square -
subsquares are ignored.

73,

... Joe, W4TV

On 2022-10-09 9:22 PM, Dave AA6YQ wrote:
+ AA6YQ comments below


Dave, perhaps I should explain my initial email (and make apologies for
starting all this).

I operate from EN50nk21 in its North-East quadrant. In fact, my eastern
property line is along the EN50nk21 and EN50nk31 boundaries. While looking
at the neighborhood via < Main - list and display SOTA summits on map -
sotamaps.org ( https://www.sotamaps.org/ ) > I realized that I have
incorrectly used the wrong grid in the past and further that operators in
many rural locations may have their rural mailbox (along a road or
highway) while their station is in a different eight character grid.

Perhaps it is a similar situation when an FT8 station confirms a QSO and
the LoTW grid and the actual grid are adjacent? A number DX confirmation
comes to mind and I am never sure whether the FT8 grid or LoTW grid is
correct

I can provide screenshots from Google Earth and sotamaps if you are
interested.
+ No apology is necessary, Gary. Critique and better ideas are always welcome here; in this case, I explicitly asked for comments.
+ Your comments above do not explain why more than 8 characters of precision are frequently necessary in a grid square:
1.  A 6-character grid square is accurate enough to compute the bearing to which to rotate a directional antenna.
2. I'm not aware of any awards based on grid squares with more than 6 characters of accuracy. VUCC, for example, only considers the first 6-characters of a grid square designator.
+ The "track my balloon" scenario would certainly benefit from increased precision, but is likely not common enough to justify an enhancement.
73,
Dave, AA6YQ