+ AA6YQ comments below
that's not strictly true, the pair of fields MY_GRIDSQUARE and GRIDSQUARE or quadruplet of MY_LAT, MY_LON, LAT, and LON, or sane
combinations of those specify the relative bearings between QSO partners. ANT_AZ is clearly intended to contain the actual aerial
azimuth used to make the QSO. Likewise for ANT_EL which itself cannot be estimated from gridsquares unless some of the time of QSO,
the propagation path are also specified.
I think Dave will confirm that derived data is not expected to be recorded in the DXKeeper primary log fields if the fields used to
derive that data are already saved in the log.
Here's an example why duplicating such information is a problem. If a grid square is found to be incorrect, perhaps by a LoTW match
where the DX station has moved and has an updated gridsquare recorded for his QTH, it is unlikely that the DXKeeper user will update
the ANT_AZ log field since it is supposed to be the actual azimuth used for the QSO and should not be inconsistent as it is
FB that it is an option that is off by default to derive the ANT_AZ field but I'll bet most users do not think through the
consequences of enabling it.
+ Bill, you're correct; the intent is to record the "actual azimuth" rather than the "theoretical azimuth", and that's how DXLab
applications use the ANT-AZ field.
+ when importing QSOs from another source -- in real time via TCP or UDP, or via an ADIF or tab-delimited file -- DXKeeper respects
the data provided by that source on the principle that data purity is less important than data preservation. Since Laurie provides
an option controlling whether it logs the "theoretical azimuth" or not, I have no objection - particularly if the JTAlert
documentation makes the effect of the option clear.