Date
1 - 17 of 17
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 |
|
|
|
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 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 On Sun, Oct 9, 2022 at 12:14 AM Dave AA6YQ <aa6yq@...> wrote: + AA6YQ comments below |
|
|
|
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@...>
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 -- 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\(r\) 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, orDXKeeper 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\(r\) 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. |
|
|
|
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
+ 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, |
|
|
|
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,
Anthony W. (Tony) DePrato |
|
|
|
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.
toggle quoted message
Show quoted text
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\(r\) Gary Huber - AB9M wrote: I don't believe this is a disagreement but given the size of anDXKeeper 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\(r\) 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. |
|
|
|
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 |
|
|
|
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
+ 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
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, |
|
|
|
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 6VUCC 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+ No apology is necessary, Gary. Critique and better ideas are always welcome here; in this case, I explicitly asked for comments. |
|
|