View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002874||Ham Radio Deluxe||Bug||public||2018-09-03 14:07||2018-09-11 13:18|
|Target Version||Fixed in Version||220.127.116.116|
|Summary||0002874: Lat/Long Data Inconsistencies (Relates to API and QSO Fwd)|
|Description||HRD 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 Reproduce||Configure a My Station description and include 6 char gridsquare and lat/long. In my case, I use:|
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 Information||This 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 qrz.com lookup for example)
Power (what is entered via the API -- if entered -- should override My Station configured value)
|Tags||No tags attached.|
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.
MyStationQSO.png (27,439 bytes)
MyStationQSO.png (27,439 bytes)
Fixed with this checkin
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.
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.
||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.|
||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.|
||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).|
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.
||Why was this marked "No change required" and closed? Won't that prevent it from being tested during the beta cycle?|
||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?|
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.
||Let's test the code changes that were made using the repro steps described.|
||Ignore/Overlay/Merged functionality cases each tested and working. This should be marked as validated.|
||Putting FIV back... I changed it by accident.|
|2018-09-03 14:07||k2dls||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||=> 18.104.22.1682|
|2018-09-07 02:50||g3ucq||Note Added: 0006102|
|2018-09-07 08:55||k2dls||Note Added: 0006106|
|2018-09-07 09:15||K7ZCZ||Note Added: 0006107|
|2018-09-07 09:58||k2dls||Note Added: 0006109|
|2018-09-07 16:28||WA9PIE||Note Added: 0006113|
|2018-09-07 16:43||k2dls||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 => 4 - 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||4 - 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||k2dls||Note Added: 0006161|
|2018-09-10 11:01||WA9PIE||Fixed in Version||22.214.171.1242 =>|
|2018-09-10 11:04||WA9PIE||Fixed in Version||=> 126.96.36.1992|
|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||188.8.131.522 => 184.108.40.2066|