View Issue Details

IDProjectCategoryView StatusLast Update
0002874Ham Radio DeluxeBugpublic2018-09-11 13:18
Reporterk2ieAssigned ToK7ZCZ 
Status closedResolutionfixed 
Product Version 
Target VersionFixed in Version6.4.0.886 
Summary0002874: Lat/Long Data Inconsistencies (Relates to API and QSO Fwd)
DescriptionHRD Logbook seems to have different methods of inserting the local station lat/long coordinates into a QSO record. It seems to depend upon how the record is entered.

I entered by the end user through ALE, the value recorded in the current "My Station" is used.

If entered via the API as used, for example, by JT Alert, it seems to disregard the value configured in "My Station" but instead derives from the grid value as sent through the API. If a four character grid value is used, the lat/long entered into the QSO record seems to be a value somewhere in the grid, but if a 6 character value is used it is more specific.

However, the configured "My Station" ought to be used in all cases for data consistency.

Steps To ReproduceConfigure a My Station description and include 6 char gridsquare and lat/long. In my case, I use:
  lat 40.396000
  long -74.208670

Enter a QSO through ALE. Stored values are lat/long as specified in My Station.

Enter a QSO from WSJT-X via JT Alert (HRD Logbook API). Stored value will be based upon gridsquare entered in JT Alert but even if 6 char grid is used will not match lat/long as manually entered. I get:

40.3958330000 / -74.2083330000

Additional InformationThis will also be an issue for the direct WSJT-X QSO forwarding interface once that is fully working. All entry points should use the same data source.

Additional related thoughts: The QSO forwarding and API should take precedence over the current My Station config for:

Locator (what is entered via the API should override lookup for example)
Power (what is entered via the API -- if entered -- should override My Station configured value)
TagsNo tags attached.
Testing Beta Successful



2018-09-06 16:54

developer   ~0006098

The data that comes in from the QSO forwarding ports isn't influenced by MyStation settings. I guess it should/could be, but I'm not positive all users will want it that way. And there's also the question of overwriting MyStation values even if the external application supplied its own.

I've added an optio nto accommodate these cases; there are now drop-down lists in the QSO forwarding settings window that can be set to "ignore" (MyStation data isn't applied), "Overlaid" (My Station data is added, even when it overwrites provided data), and "Merged" (MyStation data is supplied only when the external data source didn't supply a value).

I think this will address the concerns raised in this issue.


2018-09-06 16:54


MyStationQSO.png (27,439 bytes)
MyStationQSO.png (27,439 bytes)


2018-09-06 17:07

developer   ~0006099

Last edited: 2018-09-06 17:07

View 2 revisions

Fixed with this checkin


2018-09-07 02:50

viewer   ~0006102

Using JTAlert and WSJT-x, I entered K2DLS into the WSJT-X Log QSO box plus the locator FN20vj.
The QSO details for lon/lat and power were logged correctly.


2018-09-07 08:55

viewer   ~0006106

Mike B., what you propose is reasonable but we'll have to see how this works during testing.

However, I think there is one important case where, regardless of the setting of the drop down, you'd want the manually entered items in WSJT-X to override My Station's statically configured value. That is in the case of power. The WSJT-X screen allows power to be entered on a per QSO basis. Often, power is adjusted by the operator to make a QSO. So I'd always want power to be "Ignore" where WSJT-X supplied a value. Otherwise I'd have to keep editing the QSO record if power configured in My Station is different for that QSO.

But...I would not use "Ignore" to do this because I'd want all the other My Station data items to be applied.

Can you please give this some thought? I'm trying to ensure smooth operating over a long string of QSOs.


2018-09-07 09:15

developer   ~0006107

If you have an idea of how you'd like the UI to work, please write it up and open an enhancement request here in Mantis.


2018-09-07 09:58

viewer   ~0006109

OK, let's call this "Working As Designed" for the time being and I'll use it for a bit and then write up my request.


2018-09-07 16:28

administrator   ~0006113

If this is "working as designed"... then there was no development done here? If so, I'm going to put this into a completely different bucket (where bugs that aren't bugs go).


2018-09-07 16:43

viewer   ~0006114

We can close this Mike C.

Now that 882 is working, I see that WSJT-X and Logbook are doing what they should. My observation now relates only to JT Alert which is actually sending the different data that causes the discrepancy. So I will take the issue over to Laurie. It is not on HRD to fix in my opinion.


2018-09-07 23:02

developer   ~0006130

Why was this marked "No change required" and closed? Won't that prevent it from being tested during the beta cycle?


2018-09-07 23:52

administrator   ~0006131

I changed the status based on the comments by k2dls on 2018-09-07 16:43. If the program works as designed, and the problem is related to JTAlert, then it doesn't sound like we've done any coding here. Thus, is there really any change here to test?


2018-09-08 09:44

developer   ~0006139

I made three comments above (between 2018-09-06 14:54 and 15:07) that describe the code changes made to resolve this issue. One describes the changes verbally, another shows a screenshot of the new UI, and the last links to the change set which shows the diffs.

I'm concerned that closing this issue now will not make the changes apparent to the beta testers, and the changes I have made won't get testing coverage.


2018-09-08 19:15

administrator   ~0006144

Let's test the code changes that were made using the repro steps described.


2018-09-09 20:55

viewer   ~0006161

Ignore/Overlay/Merged functionality cases each tested and working. This should be marked as validated.


2018-09-10 11:04

administrator   ~0006177

Putting FIV back... I changed it by accident.

Issue History

Date Modified Username Field Change
2018-09-03 14:07 k2ie New Issue
2018-09-06 16:54 K7ZCZ Note Added: 0006098
2018-09-06 16:54 K7ZCZ File Added: MyStationQSO.png
2018-09-06 17:07 K7ZCZ Assigned To => K7ZCZ
2018-09-06 17:07 K7ZCZ Status new => resolved
2018-09-06 17:07 K7ZCZ Resolution open => fixed
2018-09-06 17:07 K7ZCZ Testing => Not Started
2018-09-06 17:07 K7ZCZ Note Added: 0006099
2018-09-06 17:07 K7ZCZ Note Edited: 0006099 View Revisions
2018-09-06 20:16 K7ZCZ Project 1 - Backlog => 3 - Current Dev List
2018-09-06 20:17 K7ZCZ Fixed in Version =>
2018-09-07 02:50 g3ucq Note Added: 0006102
2018-09-07 08:55 k2ie Note Added: 0006106
2018-09-07 09:15 K7ZCZ Note Added: 0006107
2018-09-07 09:58 k2ie Note Added: 0006109
2018-09-07 16:28 WA9PIE Note Added: 0006113
2018-09-07 16:43 k2ie Note Added: 0006114
2018-09-07 22:11 WA9PIE Status resolved => closed
2018-09-07 22:11 WA9PIE Resolution fixed => no change required
2018-09-07 22:11 WA9PIE Project 3 - Current Dev List => 5 - Closed w/o Action
2018-09-07 23:02 K7ZCZ Note Added: 0006130
2018-09-07 23:52 WA9PIE Note Added: 0006131
2018-09-08 09:44 K7ZCZ Note Added: 0006139
2018-09-08 19:14 WA9PIE Project 5 - Closed w/o Action => 3 - Current Dev List
2018-09-08 19:15 WA9PIE Status closed => resolved
2018-09-08 19:15 WA9PIE Note Added: 0006144
2018-09-08 19:16 WA9PIE Resolution no change required => fixed
2018-09-09 20:55 k2ie Note Added: 0006161
2018-09-10 11:01 WA9PIE Fixed in Version =>
2018-09-10 11:04 WA9PIE Fixed in Version =>
2018-09-10 11:04 WA9PIE Note Added: 0006177
2018-09-10 16:51 WA9PIE Status resolved => closed
2018-09-10 16:51 WA9PIE Testing Not Started => Beta Successful
2018-09-11 13:15 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe
2018-09-11 13:18 WA9PIE Fixed in Version =>