Topics

locked Multiple Grids per QSO - Grid boundaries and corners. #DXLAB


Robert Wright
 
Edited

Rovers on VHF and UHF often set up on grid boundaries (for two simultaneous grids) or corners (for four simultaneous grids).  This is allowed under ARRL VUCC rules and is implemented on LoTW.  But JTAlert does not seem to recognize multiple grid confirmations per QSO when using DXLab's DXKeeper, which has four fields for grid data for each QSO.  JTAlert will only scan the Grid1 field. (For multiple grids, the "LoTW confirmation" field will show the numbers 2, 3, and 4 in addition to "G" for the first grid confirmation.)

I did a search here and did not find a discussion on this before.  Any chance of implementing this?  Currently, JTAlert is missing about 16 grid confirmations in my log which is creating false alerts.

JTAlert is a great program (other than this, of course.  :-) )

Thanks and 73,
Bob Wright, N7ZO


HamApps Support (VK3AMA)
 

On 23/07/2019 11:21 am, Robert Wright wrote:
Rovers on VHF and UHF often set up on grid boundaries (for two simultaneous grids) or corners (for four simultaneous grids).  This is allowed under ARRL VUCC rules and is implemented on LoTW.  But JTAlert does not seem to recognize multiple grid confirmations per QSO when using DXLab's DXKeeper, which has four fields for grid data for each QSO.  JTAlert will only scan the Grid1 field. (For multiple grids, the "LoTW confirmation" field will show the numbers 2, 3, and 4 in addition to "G" for the first grid confirmation.)

I did a search here and did not find a discussion on this before.  Any chance of implementing this?  Currently, JTAlert is missing about 16 grid confirmations in my log which is creating false alerts.

JTAlert is a great program (other than this, of course.  :-) )

Thanks and 73,
Bob Wright, N7ZO

Bob,

Your correct, JTAlert doesn't support the DXKeeper 4 grid logging in a single QSO entry mechanisim. This logging technique didn't exist within DXKeeper when its support was first coded into JTAlert. I'll add this to the todo list.

de Laurie VK3AMA


Robert Wright
 

Hi Laurie,

Thank you for considering this.  If you need any information from me, please ask.  I would be happy to beta test the feature since my log contains both grid line (2 grids) and grid corner (4 grid) cases.  I'm not sure if a 3 grid case is possible, but DXKeeper handles this along with the other cases.

The fields involved are APP_DXKeeper_Grid2, APP_DXKeeper_Grid3, and APP_DXKeeper_Grid4 with the keys being the existence of a "2", "3", or "4" in the APP_DXKeeper_LoTWConfirmation field.  I determined this just by observation, so it is probably worth checking with Dave, AA6YQ, for confirmation.  I'd be happy to contact Dave if you don't mind second hand information.

73, Bob, N7ZO


Dave AA6YQ
 

+ AA6YQ comments below

Thank you for considering this. If you need any information from me, please ask. I would be happy to beta test the feature since my log contains both grid line (2 grids) and grid corner (4 grid) cases. I'm not sure if a 3 grid case is possible, but DXKeeper handles this along with the other cases.

The fields involved are APP_DXKeeper_Grid2, APP_DXKeeper_Grid3, and APP_DXKeeper_Grid4 with the keys being the existence of a "2", "3", or "4" in the APP_DXKeeper_LoTWConfirmation field. I determined this just by observation, so it is probably worth checking with Dave, AA6YQ, for confirmation. I'd be happy to contact Dave if you don't mind second hand information.

+ When I first extended DXKeeper to support VUCC by recording up to 4 gridsquares per QSO, ADIF had not yet defined a way to convey more than one grid square per QSO -- so I defined the APP_DXKeeper_Grid2, APP_DXKeeper_Grid3, and APP_DXKeeper_Grid4 fields to export and import the additional grid squares via an ADIF record.

+ ADIF eventually defined the field VUCC_GRIDS, which contains a comma-delimited list of up to 4 grid squares:

<http://www.adif.org/310/ADIF_310.htm#QSO_Field_VUCC_GRIDS>

+ for example:

<VUCC_GRIDS:19>FM42,FM43,FN32,FN33

+ I have extended the next version of DXKeeper to accept VUCC_GRIDS when importing an ADIF record. Laurie, if you'd like access to this new version, please let me know and I'll send it your way.

73,

Dave, AA6YQ


g4wjs
 

On 24/07/2019 02:07, Dave AA6YQ wrote:
+ I have extended the next version of DXKeeper to accept VUCC_GRIDS when importing an ADIF record. Laurie, if you'd like access to this new version, please let me know and I'll send it your way.

73,

Dave, AA6YQ
Hi Dave and Laurie,

I'm not sure we are talking about logging multiple grids in a QSO here, the WSJT-X protocols have no support for multiple grids from one QSO and that is unlikely to change due to the limited formats of messages. Of course QSO partners may exchange extra information as they feel fit. I imagine that such a multi-grid QSO, if made, would initially logged as a single grid QSO then the extra grids exchanged would be filled in manually in the logging application.

OTOH having JTAlert scan a logbook for multiple grids when calculating which grids are worked or confirmed such that they are reported accurately when highlighting and alerting decoded messages is a different matter, and I think is all that the OP was looking for.

73
Bill
G4WJS.



--
73
Bill
G4WJS.


Robert Wright
 

Bill, G4WJS:  You are correct.  We are just talking about JTAlert's scanning of the DXKeeper log.

Dave, AA6YQ:  When importing, will the APP_DXKeeper_GridX fields be populated from VUCC_GRIDS or will you be adding a new field to the DXKeeper Database?  I'm guessing the former, otherwise you would be creating redundant data in the log. (Eventually, adding the new grid field and deprecating the original grid fields would clean things up but cause other complications with database versioning.)  How will exporting be handled?  More importantly, for Laurie, what will he see when he scans the log?

Thanks, Bob, N7ZO


Dave AA6YQ
 

+ AA6YQ comments below

Dave, AA6YQ: When importing, will the APP_DXKeeper_GridX fields be populated from VUCC_GRIDS or will you be adding a new field to the DXKeeper Database? I'm guessing the former, otherwise you would be creating redundant data in the log.

+ Correct. When importing, grids squares specified in the imported record's VUCC_GRIDS field will populate the QSO's GRIDSQUARE, APP_DXKeeper_Grid2, APP_DXKeeper_Grid3, and APP_DXKeeper_Grid4 database fields.

(Eventually, adding the new grid field and deprecating the original grid fields would clean things up but cause other complications with database versioning.)

+ Maintaining upward-compatibility for interoperating applications like JTAlert is essential. Furthermore, it is computationally more efficient to maintain each gridsquare in a separate field rather than store them all in a single comma-delimited field whose contents must be processed to extract or update one grid square.

How will exporting be handled?

+ The next version of DXKeeper exports a QSO's grid squares individually using ADIF's GRIDSQUARE, APP_DXKeeper_Grid2, APP_DXKeeper_Grid3, and APP_DXKeeper_Grid4 tags, (as did its predecessors) and in a comma-delimited list using ADIF's VUCC_GRIDS tag.

More importantly, for Laurie, what will he see when he scans the log?

+ When scanning a DXKeeper log, Laurie will continue to see the same 4 grid fields that he's seen since he developed the first version of JTAlert: GRIDSQUARE, APP_DXKeeper_Grid2, APP_DXKeeper_Grid3, and APP_DXKeeper_Grid4. This is documented in

<https://www.dxlabsuite.com/dxkeeper/Help/Items.htm>

+ The next version of DXKeeper simply

- recognizes the VUCC_GRIDS tag when importing an ADIF QSO record, and places the information recovered from that tag into existing database fields

- exports existing database fields into an ADIF QSO's record's VUCC_GRIDS tag (as well as into the record's GRIDSQUARE, APP_DXKeeper_Grid2, APP_DXKeeper_Grid3, and APP_DXKeeper_Grid4 tags).

73,

Dave, AA6YQ


Dave AA6YQ
 

+ AA6YQ comments below


On Wed, Jul 24, 2019 at 03:25 AM, g4wjs wrote:

I'm not sure we are talking about logging multiple grids in a QSO here, the WSJT-X protocols have no support for multiple grids from one QSO and that is unlikely to change due to the limited formats of messages. Of course QSO partners may exchange extra information as they feel fit. I imagine that such a multi-grid QSO, if made, would initially logged as a single grid QSO then the extra grids exchanged would be filled in manually in the logging application.
+ Operating on grid square boundaries is a popular practice in VHF and UHF contests. If you are serious about contesting support, you'll need a way to convey the fact that a station is operating from more than one grid square -- perhaps via a new MY_ADDITIONAL_GRIDS message that such a station can periodically send. WSJT-X would retain the information decoded from MY_ADDITIONAL_GRIDS messages, and employ it when logging QSOs with stations  from which it received MY_ADDITIONAL_GRIDS messages.OTOH having JTAlert scan a logbook for multiple grids when calculating which grids are worked or confirmed such that they are reported accurately when highlighting and alerting decoded messages is a different matter, and I think is all that the OP was looking for

OTOH having JTAlert scan a logbook for multiple grids when calculating which grids are worked or confirmed such that they are reported accurately when highlighting and alerting decoded messages is a different matter, and I think is all that the OP was looking for.

+ That's entirely feasible with the current version of DXKeeper, but if Laurie is going to extend JTAlert to send DXKeeper an ADIF record that specifies multiple grid squares, best that he does it using the ADIF standard VUCC_GRIDS tag than employ the DXKeeper-specific tags I defined back before ADIF added VUCC_GRIDS. If nothing else, that should enable his extension to work with logging applications other than DXKeeper.

        73,

                 Dave, AA6YQ

 


HamApps Support (VK3AMA)
 

On 25/07/2019 10:19 am, Robert Wright wrote:
Bill, G4WJS:  You are correct.  We are just talking about JTAlert's scanning of the DXKeeper log.
That's correct. I will only add multiple grids per qso support to the Log Scanning function.

There is no intention at this time to add multiple grid logging as multiple grids are not conveyed using WSJT-X and as Bill pointed out unlikely to happen with the current protocols.
It will be left to the user to manually add any additional grids to the logged QSO if that station was operating from multiple grids.

de Laurie VK3AMA