Topics

FT8/JTAlert- No Azimuth Logged

w2eck
 

When logging FT8 qsos to DXKeeper using JTAlert, The distance is being logged but not the azimuth. The correct azimuth is appearing in DXView. Has anyone run into to this issue.

73 Paul w2eck

Dave AA6YQ
 

+ AA6YQ comments below

 

When logging FT8 qsos to DXKeeper using JTAlert, The distance is being logged but not the azimuth. The correct azimuth is appearing in DXView. Has anyone run into to this issue.

 

+ DXKeeper will only log an azimuth with a QSO if DXView is reporting the last azimuth to which it rotated your antenna – the “actual azimuth”.

 

+ DXView will display the computed short-path and long path heading from your QTH to a station’s location – the “theoretical azimuths”.

 

+ Since DXView will display the “theoretical azimuths” for any logged QSO you select in DXKeeper’s Log Page Display, it is not necessary to log them with each QSO.

 

        73,

 

                 Dave, AA6YQ

w2eck
 

Dave - understand. Thanks for quick reply. 

73 Paul

HamApps Support (VK3AMA)
 

On 17/09/2019 12:51 am, w2eck wrote:
When logging FT8 qsos to DXKeeper using JTAlert, The distance is being logged but not the azimuth. The correct azimuth is appearing in DXView. Has anyone run into to this issue.

73 Paul w2eck
Paul,

JTAlert Settings window, Logging section, scroll the options down until you see the "Log bearing (heading) to ANT_AZ field" checkbox then enable it. The value logged is the value JTAlert used to calculate the logged distance.

de Laurie VK3AMA

g4wjs
 

On 16/09/2019 21:05, HamApps Support (VK3AMA) wrote:
On 17/09/2019 12:51 am, w2eck wrote:
When logging FT8 qsos to DXKeeper using JTAlert, The distance is being logged but not the azimuth. The correct azimuth is appearing in DXView. Has anyone run into to this issue.

73 Paul w2eck
Paul,

JTAlert Settings window, Logging section, scroll the options down until you see the "Log bearing (heading) to ANT_AZ field" checkbox then enable it. The value logged is the value JTAlert used to calculate the logged distance.

de Laurie VK3AMA

Hi Laurie,

isn't that a misuse of the DXKeeper ANT_AZ field since JTAlert has no knowledge of the aerial azimuth used to make the contact?


--
73

Bill

G4WJS.

HamApps Support (VK3AMA)
 

On 17/09/2019 11:38 pm, g4wjs wrote:

Hi Laurie,

isn't that a misuse of the DXKeeper ANT_AZ field since JTAlert has no knowledge of the aerial azimuth used to make the contact?


--
73

Bill

G4WJS.

Bill,

I would not classify this as misuse. The option was provided (many years ago) after numerous requests for such since JTAlert was automatically logging the Distance. Since there is no adif standard field for recording the Heading/Bearing, ANT_AZ was chosen (as being the most relevant) as it that provides an ability to isolate that data and filter the log if a user chooses.
Dumping it into the comments field was considered but rejected.

This option is disabled by default, the user has to take a deliberate conscious action to enable it.

If JTAlert defaulted to enabled to forced logging of this non-ANT_AZ data to the ANT_AZ field without option to turn disable, then it could be classified as misuse, IMO.

de Laurie VK3AMA

g4wjs
 

On 17/09/2019 20:03, HamApps Support (VK3AMA) wrote:
Since there is no adif standard field for recording the Heading/Bearing

Hi Laurie,

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 empirical.

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.


--
73

Bill

G4WJS.

Dave AA6YQ
 

+ 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
empirical.

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.

73,

Dave, AA6YQ

w2eck
 

Laurie - thanks do much for the reply. That did the trick. Az reading now being logged in DXKeeper

Tnx & 73
Paul
w2eck