View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3598 [3 - Current Dev List] Bug major always 2019-11-19 06:32 2019-12-09 06:15
Reporter: WA9PIE Platform:  
Assigned To: DOUG OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.7.0.256  
    Target Version:  
Module: Logbook
Sub-Module: Call lookup
Testing: Not Started
Summary: Callsign lookup is not honoring callsign prefixes
Description: This is gonna be a fun one to go through again. We did this several years ago. This is probably a messy topic.

The problem to fix here is that the prefix is not being considered correctly in the callsign lookup.

We may need to put the prefix problem in one Mantis... and the suffice problem in another Mantis. Let's call this the parent record for now and gather comments.
Tags: 6.7 defects
Steps To Reproduce: A PREFIX unconditionally modifies the Country (and therefore, the DXCC, Continent, and HRD Country Number; and probably several other fields like lat/long, locator, IOTA, CQ Zone, and ITU Zone) for a given callsign lookup. [This is an important point that I'll come back to later.]

SUFFIX - When a station is operating from an automobile it will use the suffix /M for mobile. The suffix /P may be used for portable operation, and /MM for maritime mobile. Occasionally /AM will be heard when a station is aeronautical mobile. The suffix /QQ refers to an invalid callsign (pirate station).

To describe the problem...

Callsigns 'can' have a prefix or a suffix. Using callsign WA9PIE as an example:

- WA9PIE returns the Country, DXCC, Continent, and HRD Country Number as follows:
United States, 291, NA, and 291 (this presently works perfectly)

- WA9PIE/M (or /P) should return
United States, 291, NA, and 291 (this presently works perfectly)

- VK4/WA9PIE should return:
Australia, 150, OC, and 150 (this is one of the problems)

- VK4/WA9PIE/M (or /P) should return:
Australia, 150, OC, and 150 (this is one of the problems)

ANY callsign that has a /MM suffix (with or without a prefix) should return:
Maritime Mobile, 0, <blank Continent>, 0

ANY callsign that has a /AM suffix (with or without a prefix) should return:
Maritime Mobile, 0, <blank Continent>, 0
Additional Information: Yeah, welcome to ham radio! FWIW, this is a whole lot better (from a "standards" perspective) than it used to be.

It seems to me that we would have to add some sort of 'case' to the callsign lookup logic that did this (pretty much in this order):

- parse the callsign field

- If the suffix is /MM (maritime mobile), /AM (aeronautical mobile), /QQ (invalid country or pirate)
> the DXCC=0, Country=None, HRD Country Number=0
> Continent, Lat/Long, Locator, IOTA, CQ Zone, or ITU Zone should all be Null (the user can modify these fields)
> All other callsign lookup data for the given callsign can be used
> end

- if a prefix exists (and there's no /MM, /AM, /QQ suffix)
> the prefix should be looked up using the real expression logic in the Country List lookup method
> the DXCC, Country, HRD Country Number, and Continent should come from that Country List data for the given country match
> Lat/Long, Locator, IOTA, CQ Zone, or ITU Zone should all be Null (the user can modify these fields)

- if the suffix is /M or /P, it would not modify the distilled results of the Callsign Lookup
Attached Files: Callsign Lookup Addition.docx (67,190 bytes) 2019-11-20 08:09
https://development.hamradiodeluxe.com/file_download.php?file_id=859&type=bug
DM780-CallsignLookupPane-distance_and_heading.PNG (44,632 bytes) 2019-11-27 12:12
https://development.hamradiodeluxe.com/file_download.php?file_id=873&type=bug
Logbook-CallsignLookupPane-distance_and_heading.PNG (63,705 bytes) 2019-11-27 12:12
https://development.hamradiodeluxe.com/file_download.php?file_id=874&type=bug
Country Lookup Test Results.xlsx (13,926 bytes) 2019-11-27 19:45
https://development.hamradiodeluxe.com/file_download.php?file_id=875&type=bug
Suffixes That Do Not Count for a DXCC Country.docx (75,919 bytes) 2019-11-27 21:15
https://development.hamradiodeluxe.com/file_download.php?file_id=876&type=bug
BearingDistance.PNG (23,952 bytes) 2019-11-27 21:33
https://development.hamradiodeluxe.com/file_download.php?file_id=877&type=bug
HRD6_7_0_254_Prefix.JPG (129,054 bytes) 2019-11-28 08:43
https://development.hamradiodeluxe.com/file_download.php?file_id=879&type=bug
Callsign Lookup Addition v2.docx (130,314 bytes) 2019-11-30 21:57
https://development.hamradiodeluxe.com/file_download.php?file_id=880&type=bug
1-character prefix.jpg (79,288 bytes) 2019-12-09 02:17
https://development.hamradiodeluxe.com/file_download.php?file_id=890&type=bug
2-character prefix.jpg (81,530 bytes) 2019-12-09 02:17
https://development.hamradiodeluxe.com/file_download.php?file_id=891&type=bug
Notes
(0009399)
g3ucq   
2019-11-19 07:50   
You have covered all the options.
e.g. All of my /mm QSOs show the station's home country.
With the Lookup pane open I clicked on the cluster callsign EA8/R3GG.
For a fraction of a second the Country was shown as the Canary Islands and then changed to European Russia so the prefix is being recognised.
(0009400)
WA9PIE   
2019-11-19 07:51   
Yeah, I saw this "fraction of a second" thing also. It's clearly populating the Country section twice.
(0009404)
vk2byi   
2019-11-19 19:36   
I also think you have it well covered.

Currently, I only have about 36 contacts that contain a prefix or a suffix (contains '/') which is not much of a dataset. But I do have two that are logged incorrectly - VK2NUN/LH (Lord Howe I.) and VK9MA/MM (on route to Mellish Reef) that both show Australia.

The 'correct' call today for the first would be VK2NUN/VK9L, but I guess in 1979 /LH was correct - don't remember :). I have other confirmed contacts with both Lord Howe and Mellish without prefixes/suffixes, so this hasn't been an issue for me so far.

Applying this parsing logic today, VK2NUN/LH would be unchanged and VK9MA/MM would be DXCC=0, Country=None, HRD Country Number=0, which is reasonable in both cases. I am sure that there will plenty of other non-standard prefixes/suffixes such as /LH out there to ignore as well. As you say 'welcome to ham radio'.
(0009405)
WA9PIE   
2019-11-19 21:59   
Thanks, Chris.

The way I think of this is the following:
- the UCSDB (public and private) still always need to win (determining the DXCC, Country, Continent, and HRD Country Number)
- but prior to sending the call into the optionally enabled methods (QRZ.com, HamCall, QRZCQ, Callook.info, HamQTH... and maybe some I'm missing)... we need to analyze the callsign for prefix at this stage... and - if one of the prefix/suffix criteria are met - set the location fields (DXCC, Country, HRD Country Number, Continent, Lat/Long, Locator, IOTA, CQ Zone, or ITU Zone) based on analyzing the prefix/suffix against the logic described above
- then allow the remaining lookup methods to take actions

As a result of doing it this way, a prefix in a callsign like "VK4/WA9PIE" will accurately end up with "Australia, 150, OC, and 150... and a roughly accurate lat/long... while all the rest of the non-location information is populated normally in the remaining logic of the lookup.
(0009431)
WA9PIE   
2019-11-20 08:09   
SUBMITTED FOR COMMENT

Greetings guys. I'm attaching a document that (I hope) will describe the change that needs to be made in order to solve the prefix/suffix problem.

Please review it and comment here.
(0009432)
g3ucq   
2019-11-20 08:38   
That seems to cover all options.
(0009433)
KB3NPH   
2019-11-20 08:39   
Mike, we have many users who create a call such as "KB3NPH/1" where the suffix is a single number. Some I've seen will use this instead of using the normal "prefix/callsign" or "Callsign/Suffix" as they are supposed to. Others use it as though saying "Portable 1" or "Mobile 2" as if indicating they have radios in two different HTs or two different cars and are specifying what car they were in when logging the contact. How is something like this going to be handled?
(0009434)
g3ucq   
2019-11-20 08:44   
As KB3NPH/1 is in the same Country as KB3NPH then I suppose the /1 can be ignored?
(0009435)
vk2byi   
2019-11-20 21:15   
I did some analysis on 750+ compound calls from several logs available to me, and I found the following 8 aeronautical calls indicated by the 'A' after the 'only or last slash':

        DL4JA/A, F/ON4UQ/A, G8EWG/A, GD3WOH/A, OZ0EPC/A, PI4DLZ/A, SV2ASP/A, ZL4OY/A.

In the same dataset there are **no** /AA suffices and 21 /MM suffixes,. The ratio of aeronautical to maritime (8:21) contacts seems reasonable, but zero 'AA's suggests that 'A' may be more popular. Maybe Case 2 should be changed to "MM", "AA" or "A".

Also, I believe the underlined text in Case 4 should read "not subject to Case 2 or 3".

Apart from the above, I agree that Callsign Lookup Addition.docx addresses all cases that come to mind.
(0009444)
WA9PIE   
2019-11-21 15:00   
I thought I had responded to Tim's point, but here's the response (I don't see it)...

We want to stick with a standard. Prefix is location. Suffix is "working condition" (mobile, portable, maritime mobile, aeronautical mobile, etc).

Tim's example should be W1/KB3NPH. This also allows for the possibility that he could be mobile there - W1/KB3NPH/M. (We have problem when people post it as "KB3NPH/M1"... as that's a whole different animal.) So we'll support the standard. If the suffix doesn't match the common "working conditions", then we'll basically ignore it.
(0009445)
g3ucq   
2019-11-21 16:29   
The /A suffix in the UK denotes the licensee is operating from an Alternative location, but in the same Country as normal.
(0009448)
vk2byi   
2019-11-21 17:47   
Thanks John, then Case 2 should remain as "MM" and "AA" only, and let /A be ignored then.
Thanks, I have learnt something new :)
(0009449)
vk2byi   
2019-11-21 18:59   
Corrections to both notes 9435 and 9448 above. I obviously meant "AM" for aeronautical mobile - not "AA".
(0009450)
WA9PIE   
2019-11-21 19:21   
Thanks, Chris.

Is there a complete list of common suffixes? I figure we should try to include the ones we know of.
(0009452)
vk2byi   
2019-11-21 19:38   
I found this on Wikipedia (https://en.wikipedia.org/wiki/Amateur_radio_call_signs#Secondary_prefix_or_suffix_types).

Thanks to John for the clarification on /A which can be ignored, it now seems that you have things pretty well covered.

This link does list /<digit> - which makes KB3NPH/3 OK, but not KB3NPH/1 which should be W1/KB3NPH as you have already noted.
(0009453)
WA9PIE   
2019-11-21 19:52   
Having read what Chris posted... I'll have to give this some thought. While I've seen this version of the standards before, I've not seen it in-practice for quite a bit.
(0009457)
DOUG   
2019-11-27 01:03   
Just kicked off a build with this one.
Lots a new code so probably will have some tweaks needed.

If you guys come across something that looks wrong, give me....
1. the full lookup string you used
2. What field was wrong...
3. What you expected that field to be
4. What portion of the app you were doing the lookup in (I'm not sure I know them all yet)
(0009458)
WA9PIE   
2019-11-27 12:12   
(Last edited: 2019-11-27 12:13)
6.7.0.253

From what I can tell, one thing to change for Logbook. Image attached.

Within DM-780's Callsign Lookup pane, we should adjust it to match Logbook. Image attached of what it is now. (Country section is correct. Licensee section contains info we decided to strip off.)

(0009459)
g3ucq   
2019-11-27 15:22   
VK4/WA9PIE gives Australia as the Country. Great work.
(0009460)
g3ucq   
2019-11-27 15:26   
The DM7870 Lookup panel for VK4/WA9PIE shows the IOTA as "Not Defined in DM".
The Logbook Lookup panel for VK4/WA9PIE shows the IOTA as OC-001 etc.
(0009461)
DOUG   
2019-11-27 16:27   
Just changed the logic so DM (unless there is some more DM code I don't know about yet). Should match what is in log manager. Just kicked off the build.

On the distance. It looks like that look up isn't working right now on the panes with any option. Should that just be bearing and distance (in km?). Is there a standard format for that?
(0009462)
vk2byi   
2019-11-27 19:45   
Aeronatical and Maritime Mobile (/AM, /MM) suffixes don't appear to work yet.

Single letter prefixes such as B, F, I, K, W, N don't work, although the Wikipedia article mentioned in note 9452 above suggests they should. I understand why they don't because of the ARRL prefix expressions in the country data file. E.g. F[0-9].*|F[A-FILNQUVXZ].*|H[WXY].*|T[HMPQT].* for France requires a digit (0-9) or a letter (A-FILNQUVXZ) to follow the F as per the first two patterns. I am not suggesting that the callsign lookup is wrong in this case though, but I mention this because F/G3xxx doesn't work and someone reading the article may think it should. I assume the filter expressions in the country data to be the authoritive source.

Refer to the attachment for futher details of test cases and results. Looking pretty good so far Doug.
(0009463)
WA9PIE   
2019-11-27 19:55   
Chris, thanks for posting your findings. There may be some work I need to do with the Country List in order to enable what I asked Doug to do. I'll study that in a bit. But if the worst thing is that the /MM and /AM still don't work, I may live with that a bit longer... given that we've made some overall progress.
(0009464)
WA9PIE   
2019-11-27 21:15   
After dong some testing - manually creating a Country called "None" with a DXCC value of 0...

The 6.7.0.254 build will cause the Country field to populate with "None". But the Country tab still shows it as United States and DXCC=291.

Fixing this is needed in order to resolve the related cases for this item.

I'm attaching a document to describe the options.

(I'll have another note to follow regarding the existing lookup.)
(0009465)
WA9PIE   
2019-11-27 21:33   
As for the "car icon" in the Licensee section of the Lookup pane... it DOES work properly when the callsign doesn't contain a prefix.

When the call does contain a prefix, then...

I think... the "car icon" in the Licensee section of the Lookup pane (for both Logbook and DM-780) SHOULD be populated when a prefix is used and the lat/long come from the default values in the Country List. This isn't working at the moment.

The estimated lat/long is the center point of a given country.

Pros: This will give some direction for the antenna in some cases. Particularly small countries or islands - Pitcairn for example. Since it's a small island in a sparsely populated area of the world (the South Pacific) with about 1 ham on the island, everyone will be pointing at it from outside the island.

Cons: This won't be good when the prefix is associated with a large country (United States, for example). Let's say that I live in Dallas TX... but I'm operating W1/WA9PIE during vacation to Bar Harbor, Maine. Folks see me on the DX Cluster... I've got a prefix in my call. So the lat/long from my home in Dallas won't work - as it would have people in Florida pointing to Dallas. The center of the country (Bennington, IA) isn't the right place for someone in Florida to point either. So this method has problems.

Do we give them estimated information that is often not helpful?

Is it better to give them no information and let the operator point to the state of Maine on their own?
(0009466)
vk2byi   
2019-11-27 23:18   
In most financial and IT service management databases and applications that I worked on during my working career, if something was unknown it was stored as Null in the backend. All platforms used by HRD Logbook support nullable columns, and all columns except the primary key column (COL_PRIMARY_KEY) in 'TABLE_HRD_CONTACTS_V01' are nullable. Therefore, you could simply store Null in COL_DXCC and COL_COUNTRY for unknown entities, including any other columns needed to store 'unknown' for this purpose.

I do know columns like County (COL_CNTY) store Null when unknown (e.g. non-US contacts) and they are correctly displayed as blank fields in the ALE. So there already is code in Logbook that is 'moving' Nulls and blank text (empty strings) back and forth between the database and the UI. I suspect a similar approach could be used for handling Nulls in COL_DXCC, COL_COUNTRY and others. That way you don't need a definition for an unknown country in the Country Definition.

Of course, I have no knowledge of the Logbook source code, and don't know how much effort would be required, but maybe this something the team might want to consider. Just my 2c.
(0009467)
WA9PIE   
2019-11-27 23:22   
Yeah, the issue is that the ADIF standards define a country where DXCC=0 and Entity Name=None... and it's intended to be used for cases like /MM and /AM... for the primary purpose of import/export.

We 'could' just apply that value for import/export... however... users will get confused by the fact that they need to save a QSO with a blank Country value... which leads right back to the related cases where "QSOs that aren't eligible for DXCC credit are showing up in the awards totals."
(0009468)
vk2byi   
2019-11-27 23:26   
No information is better then inaccurate information I would suggest, so I agree that the central lat/long point (centroid in GIS terms) can be unhelpful for larger countries. I vote for no info and the let the user work it out.
(0009469)
WA9PIE   
2019-11-27 23:31   
If that's the answer, then that's basically what we've got right now. We would just need to hide the "car icon" when there's no value to present.
(0009470)
vk2byi   
2019-11-27 23:34   
When I say moving the Null back and forth between the database and the UI, you could use '0' for DXCC and 'None' for Country instead of empty strings, and then it would be consistent across the user interface and ADIF import/export. I assumed that the NULL value wouldn't get counted in the SQL that is aggregating the totals, but as I say I don't have any knowledge of the code and maybe the summations are done in the front end code and not the database queries - SQL?. Just a though....
(0009471)
WA9PIE   
2019-11-28 00:01   
Actually, maybe the answer is as simple as removing the estimated coordinates and "car icon" from the Licensee section... and only populating it there when there's a valid source for the information.

I think that's the way to go... because it otherwise works perfectly.

Thoughts?
(0009472)
g3ucq   
2019-11-28 03:18   
Can I throw another spanner in the works?
There is a cluster spot for UE29DX In Kaliningrad (UA2)
The ALE and the Logbook Lookup panel both show European Russia.
Is UE2 the same as UA2? If so, then Kaliningrad is correct
(0009473)
g3ypp   
2019-11-28 08:43   
Not fixed for me in .254. EA/4Z1KD/P is showing as Israel in Lookup and ALE; and no data by car icon. See image attached.
(0009474)
g3ucq   
2019-11-28 08:48   
I see the same as David with that call sign but if I add a number to EA e.g. EA2 the Country shows correctly as Spain.
EA8/4Z1KDP/P becomes the Canary Islands.
(0009475)
g3ypp   
2019-11-28 08:57   
Ditto as per John in 9474. It works with a number in prefix.
(0009476)
WA9PIE   
2019-11-28 11:22   
While the DX clusters are showing UE29DX as Kaliningrad, all their announcements say it's Eastern Russia. So let's go with that.

As for EA/callsign... I don't think there's much we can do with that. There are 4 different DXCC entities that begin with EA. That said... here's an idea... (coding required)... if the prefix does not end with a number, then append a "1" to the end of it for the sole purpose of finding the correct country. (I don't think a call area 1 is used for areas outside of any countries.)

So with that in mind...
EA/4Z1KD/P would be treated as EA1/4Z1KD/P... and that is correctly found as Spain.
F/WA9PIE would be treated as F1/WA9PIE... and that is correctly found as France.
...and if someone enters F/ or EA/ (G/ and so on) into the Lookup pane, we'll not change the data they entered... just the data we display.

All of this works off the Regular Expression logic in the Country List. I'm certain that it's correct for all these. The problem is just that folks aren't entering numbers in with their prefixes sometimes and that's not something we want to add to the Regular Expression logic in the Country List (I don't think).
(0009477)
WA9PIE   
2019-11-28 12:12   
(Last edited: 2019-11-28 12:14)
DOUG - if you read this... hold off on doing anything with it until I post more info about this.

There are three things to sort out:
1. How to handle prefixes that don't end in a number
2. How to handle suffixes (hard-coded or modify Country List)
3. Whether or not to show estimated coordinates in the Licensee section of the Lookup pane

(0009478)
vk2byi   
2019-11-28 19:09   
I just did some spot checking with US/Alaska (K, W, N, KL, AL, NL, WL), European Russia (UA), EA, F, VK, ZL, BV9P and ZP for good measure, and appending '1' to those prefixes without a trailing digit results in the correct country lookup being returned in the ALE dialog in .244.

So, I think doing this in preparing a 1 or 2 letter prefix only, for country regular expression searches only, is workable.
(0009480)
DOUG   
2019-11-30 21:35   
I'll wait to work on any additional prefix changes until I hear from Mike. I did just check in some changes that should show distance and bearing on the lookup pane for Logbook and DM. My "station" is set to 0.0, 0.0, so it needs to be tested with a real station. It should show

Distance (in km or miles) and Bearing (in degrees)

And if you click on it, it should send the bearing to "HRDRotatorSetAzimuth" command.

Just kicked off build, so it should be ready in a few.
(0009481)
WA9PIE   
2019-11-30 21:57   
Doug,

I'm attaching an updated paper on this topic.

There are four scenarios.

#1- need to be able to allow the UCSDB (public and private) to look for the full callsign with prefix
#2 - you and I might want to discuss this. This is the scenario where the suffix is /AM or /MM. We should chat about the approach.
#3 - this is tested, validated, and complete.
#4 - I've got a suggestion in the paper for how we might deal with this case.
(0009482)
WA9PIE   
2019-11-30 22:08   
Doug,

In scenario #2 - I have validated that the regular expression that I created does work. I had to edit the XML. We'll discuss it.

Concentrate on #1 and #4.
(0009483)
g3ucq   
2019-12-01 03:33   
Not fixed for me in 6.7.0.255. EA/G3UCQ shows England but EA1/G3UCQ shows Spain.
(0009486)
g3ypp   
2019-12-02 10:13   
For me the same as G3UCQ in 9483 above. EA/G3YPP shows England whilst EA1/G3YPP shows Spain,
In addition, with EA1/G3YPP, the Lat/Long shows 40.00 deg, -4.00 deg but a distance of 2778.25 miles a and bearing of 355 deg. I don't often beam north for spain.
(0009491)
DOUG   
2019-12-08 14:53   
Just kicked off the build that will add a number to prefixes without one.
(0009492)
WA9PIE   
2019-12-08 15:20   
I've posted the 6.7.0.256 build up for us to test this issue with.
(0009493)
vk2byi   
2019-12-08 19:55   
I am not seeing any of the following work in either the ALE dialog or DM-780 - seems to be no change from .254.

VK2BYI/AM - expected None, actual Australia
VK9MA/MM - expected None, actual Mellish Reef
F/G3XXX - expected France, actual blank
(0009494)
w4elp   
2019-12-09 01:05   
Observations on 6.7.0.256:
Logbook ALE appears to be working well. 1-character prefix or suffix yields expected result. Example: G/WA9PIE = England
Logbook Lookup pane appears same as Logbook ALE.
DM780 ALE and Lookup pane require at least 2-character prefix/suffix.
Examples:
G/WA9PIE yields blank country. In ALE, name is populated in both Name and QTH fields.
GM/WA9PIE correctly displays Scotland.
G4/WA9PIE correctly displays England.
VK/WA9PIE yields blank country. In ALE, name is populated in both Name and QTH fields.
VK4/WA9PIE correctly displays Australia.
(0009495)
vk2byi   
2019-12-09 02:17   
To be clear, in the ALE the correct selection is made in the Country: drop-down list box in the upper part of the ALE in both cases of G/WA9PIE and G1/WA9PIE. However, the Country is not displayed on the Country tab in lower part of the ALE with G/WA9PIE. Refer to the attachments for further details,. This is what I meant in note 0009492 - the test case fails for one becuase it isn't correctly populating the Country tab in the ALE (and DM-780 as well).

Ed, can you retest and see if you can repeats my results as attached?

73 Chris
VK2BYI
(0009496)
g3ucq   
2019-12-09 03:24   
v6.0.7.256
G/WA9PIE shows England in the ALE box but nothing under the Country tab.
G4/WA9PIE shows England in the ALE box AND under the Country tab.
VK/WA9PIE shows Australia in the ALE box but nothing under the Country tab.
VK4/WA9PIE shows Australia in the ALE box AND under the Country tab.
VK2BYI/AM shows a blank country in the ALE but Australia under the Country tab.
VK9MA/MM shows a blank country in the ALE and Mellish Reef under the Country tab.
Not fixed yet.
(0009497)
g3ucq   
2019-12-09 03:29   
In the Lookup Panel my test callsigns above show correctly but VK9/G3UCQ shows England. (I wish!)
VK/G3UCQ Australia and VK4/G3UCQ
(0009498)
vk2byi   
2019-12-09 04:29   
VK9 is not a legal prefix and does not represent an Australian administered entity per se. Therefore, I woiuld argue that VK9/G3UCQ is not a valid test case. The recognised prefixes are VK9C (Cocos (Keeling) Is.), VK9L (Lord Howe I.), WK9M (Mellish Reef), VK9N (Norfolk I.), VK9W (Willis I.) and VK9X (Christmas I.) which all work correctly.

So, in summary for the Australian call areas and administered entities, the valid prefixes for use with test cases would be VK0 for the Antarctic division, VK1 - VK8 for each of the States or Territories (ACT, NSW, VIC, QLD, SA, WA, TAS, NT), VK9C, VK9L, WK9M, VK9N, VK9W and VK9X. And I suppose VK by itself for a station lost in the 'outback' somewhere and not sure just what state or territory they are in... :)

There is also Heard I. and Macquarie I. that are listed in the ARRL DXCC Entity list as VK0, but calls are assigned for approved operation there such as VK0EK (Robert Schmieder's 2016 Heard I. DXpedition) and VK0AI (a VK5 currently operating on Macquarie I.

So, I think all of the prefixes mentioned here are valid for VK and the country lookup appears to work correctly.
(0009499)
WA9PIE   
2019-12-09 06:15   
From what I can see, case 3 and 4 are good. Case 1 and 2 still to close.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3608 [1 - Backlog] Bug minor unable to reproduce 2019-12-02 04:01 2019-12-06 12:32
Reporter: PD9FER Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rotator
Sub-Module: Rotators
Testing: Not Started
Summary: Green Heron RT-20 Main screen Azimuth does not move
Description: From customer:
I have checked the connect box and both the azimuth and mouse boxes. Rotor turns perfectly when I click on desired location via map but nothing on the azimuth.

Tags:
Steps To Reproduce: Connect a Green Heron RT-20 controller plus suited rotor.
Select the Green Heron from the Rotor Protocol list.
Click Connect
Make sure Refresh is set to 1
Select a location on the world map
Notice that the Rotor moves, but the Azimuth indicator is not moving.

When selecting Hy-Gain DCU 1 it does work... but do note some errors generated for both protocols in the 2 attached Log files.

Additional Information: Ticket #690752
Attached Files: HRD Rotator Logfile 01.txt (4,055 bytes) 2019-12-02 04:01
https://development.hamradiodeluxe.com/file_download.php?file_id=882&type=bug
HRD Rotator Logfile 02.txt (2,559 bytes) 2019-12-02 04:01
https://development.hamradiodeluxe.com/file_download.php?file_id=883&type=bug
Capture_RotorControl.PNG (199,340 bytes) 2019-12-02 16:34
https://development.hamradiodeluxe.com/file_download.php?file_id=886&type=bug
Notes
(0009487)
KC7FPF   
2019-12-02 16:34   
Updated information:
OS ticket 882038
Receive the attached error when trying to operate. Using RT-21 controller but will only connect using HyGain DCU1
(0009490)
KC7FPF   
2019-12-06 12:32   
Also please refer to ticket 256975 for additional information.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3616 [1 - Backlog] Bug minor always 2019-12-06 08:16 2019-12-06 08:16
Reporter: PD9FER Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Various
Testing: Not Started
Summary: Mode DIGITALVOICE gets trunkated
Description: When importing an ADIF with MODE DIGITALVOICE, Logbook stores it as DIGITALVOI
Tags:
Steps To Reproduce: Import a ADIF with DIGITALVOICE as mode
Export the QSO as ADIF and see that it changes into DIGITALVOI
Additional Information: Ticket #399437
Attached Files: HRD ADIF.txt (1,558 bytes) 2019-12-06 08:16
https://development.hamradiodeluxe.com/file_download.php?file_id=888&type=bug
Imported ADIF.txt (215 bytes) 2019-12-06 08:16
https://development.hamradiodeluxe.com/file_download.php?file_id=889&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3615 [3 - Current Dev List] Bug major have not tried 2019-12-05 18:29 2019-12-05 18:39
Reporter: WA9PIE Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Label
Testing: Not Started
Summary: Parent issue for QSL labeling issues
Description: I'm creating this just to have a place to track the overall QSL labeling issues.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3480 [1 - Backlog] Bug feature always 2019-10-05 09:39 2019-12-05 18:39
Reporter: KC7FPF Platform:  
Assigned To: DOUG OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: (select)
Testing: Not Started
Summary: Label Printing 2 qso's on one label
Description: Using a Brother QL-570 label printer. It prints the labels ok but for one problem. I worked A82X on 20m and 17m. When I print the label it shows 2 qso's on 17m and doesn't print the 20m qso.

Please refer to the OS ticket 349849.
Tags:
Steps To Reproduce:
Additional Information: I have also noticed this as well in the beta 6.7.231 as well will follow with details
Attached Files: print label1.JPG (127,941 bytes) 2019-10-05 11:28
https://development.hamradiodeluxe.com/file_download.php?file_id=770&type=bug
print label2.JPG (51,025 bytes) 2019-10-05 11:28
https://development.hamradiodeluxe.com/file_download.php?file_id=771&type=bug
75241045_2503329019765728_6325578939641102336_o.jpg (273,174 bytes) 2019-11-10 04:41
https://development.hamradiodeluxe.com/file_download.php?file_id=831&type=bug
Notes
(0008750)
KC7FPF   
2019-10-05 09:55   
Steps to reproduce:
1. Have the logbook open as normal.
2. Highlight the number of contacts you wish to print a label for.
3. Select the print option in logbook.
4. Ensure the you have the label type and size you wish to use.
5. Select the print option.
(0008756)
KC7FPF   
2019-10-05 11:28   
Enclosed you will see that in the log book there are 4 contacts 3 of them are on 20 meters and one is on 40 meters. However when you go to print the label with all four of the contacts selected you only see listing for 20 meters.
(0009224)
PD9FER   
2019-11-10 04:41   
Also when making 2 QSO's with the same station (Like on a different band or mode)
You want to print those 2, however it prints the 1st QSO twice.
See attachment.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3442 [3 - Current Dev List] Bug minor have not tried 2019-08-28 02:19 2019-12-05 18:38
Reporter: PD9FER Platform:  
Assigned To: DOUG OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Label
Testing: Not Started
Summary: Label Printing uses wrong data for Callsign
Description: When printing a QSL card, it's using the Callsign associated with the key rather than the Callsign associated with the QSO.
So... if you imported QSOs from way back when your Novice call was WN9PIE... and the Callsign in the QSO is WN9PIE... then the QSL card says, WA9PIE.
That's a bug.
Tags:
Steps To Reproduce: N/A
Additional Information: On Request from WA9PIE pse assign to Doug
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3167 [1 - Backlog] Bug minor always 2019-02-07 07:28 2019-12-05 18:38
Reporter: PD9FER Platform:  
Assigned To: DOUG OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Label
Testing: Not Started
Summary: Printing label, output garbled when adding QSL VIA
Description: When trying to print a label with the field QSL Via added the output is garbled.
See atached screenshots
Tags:
Steps To Reproduce: Select a existing QSO which have the QSL Via field filled
Right click the entry
Select File > Print > Label
Set it up as in Good.jpg
Layouts looks ok.

Now add the QSL Via (as in Bad.jpg
Layout is mismatched.
Additional Information: Ticket 431814
Attached Files: Bad.jpg (56,114 bytes) 2019-02-07 07:28
https://development.hamradiodeluxe.com/file_download.php?file_id=681&type=bug
good.jpg (57,861 bytes) 2019-02-07 07:28
https://development.hamradiodeluxe.com/file_download.php?file_id=682&type=bug
Notes
(0007803)
WA9PIE   
2019-03-30 05:49   
We accidentally removed this (before Doug got involved in it). We need to put this back. I'll gather more detail about the requirement.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2918 [1 - Backlog] Bug minor have not tried 2018-10-17 07:44 2019-12-05 18:38
Reporter: KB3NPH Platform:  
Assigned To: DOUG OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Label
Testing: Not Started
Summary: Power field in QSL Label Printing
Description: Ticket #758903 - When printing the QSL labels there is a field for TX Watts. HRD puts in a value of 50.000

The 3 extra zeros after the decimal makes it look like 50,000. Is there a way to change this?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1933 [Ham Radio Deluxe] Bug major always 2016-08-22 17:28 2019-12-05 18:37
Reporter: WA9PIE Platform:  
Assigned To: DOUG OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.7.0.244  
    Target Version:  
Module: Logbook
Sub-Module: Label
Testing: Not Started
Summary: Printing direct on QSL cards is microscopic
Description: Print on a card... the fonts are so small that any reasonable person would need a microscope to read it.
Tags: ParityGap
Steps To Reproduce: select a QSO to print a card for
in LB, go to the print QSL card dialog...
Print on card (without the background and all that)
feed QSL card into the envelope slot of a printer

observe microscopic font
Additional Information: I find this happening with the following:

HP LaserJet 2200 with the latest HP print driver for that printer.

I have also created a custom paper size in Windows and I select that... because Windows otherwise has no idea what size paper is being used (and this may be part of the problem... there's no QSL-sized paper in Windows by default).

I print directly on a QSL card purchased from cheapQSLs.com using style 122. I've asked them to print my cards WITHOUT their box on the front of the card.

SO... it's exactly the same as if we printed on the blank backside of the QSL card in the middle.
Attached Files: WA9PIE blank card stock.jpg (1,793,176 bytes) 2016-08-29 12:27
https://development.hamradiodeluxe.com/file_download.php?file_id=89&type=bug
WA9PIE printed card.jpg (1,961,882 bytes) 2016-08-29 12:28
https://development.hamradiodeluxe.com/file_download.php?file_id=90&type=bug
Box of envelopes.jpg (2,577,132 bytes) 2016-08-29 12:28
https://development.hamradiodeluxe.com/file_download.php?file_id=91&type=bug
Notes
(0003010)
WA9PIE   
2016-08-29 12:33   
After testing this, it's clear that the printer "thinks it's getting a "8.5 x 11" sheet of paper when trying to print the QSL card. For my printers (DeskJet 3632 and LaserJet 2100), there was no paper size defined for the 3.5" x 5.5" QSL card.

With the LaserJet, I created a custom card size. I haven't done that yet with the DeskJet.

So... for the DeskJet, I'm using a pre-defined paper size that says "6 3/4 Envelope" and that works sometimes... it's a bit unpredictable. I have also found that small envelopes are an effective test for this - even though the size doesn't exactly match.

SEE MY IMAGES:
Notice my "WA9PIE blank card stock"
Successful image of printed card (fonts are a tad too big now)
(0009072)
WA9PIE   
2019-10-29 05:43   
I believe this is fixed. Needs testing.
(0009075)
g3ucq   
2019-10-29 05:52   
Printing onto QSL cards is not available to me. The option was removed some time ago.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1894 [3 - Current Dev List] Enhancement feature have not tried 2016-03-29 08:35 2019-12-05 18:37
Reporter: KB3NPH Platform:  
Assigned To: DOUG OS:  
Priority: low OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Label
Testing: Not Started
Summary: Printing extra items on a label
Description: Ticket#322140
Two lines print Ok but if I add extra items such as Rig, Ant etc then the new items just extend the first two lines beyond the label boundries of the specified label.
There is plenty room on the label; to add more lines for items but the software does not provide for a line feed.
Tags:
Steps To Reproduce:
Additional Information: This guy wants to print on labels what is normally printed on pre-printed QSL cards. I think he is asking too much to be printed on the labels which isn't necessary.
Attached Files: QSL Label.jpg (66,363 bytes) 2016-03-29 10:20
https://development.hamradiodeluxe.com/file_download.php?file_id=78&type=bug
Notes
(0000746)
KB3NPH   
2016-03-29 10:17   
Customer send an image of the type of label he wanted to print with HRD. Please see attachment.
(0007795)
WA9PIE   
2019-03-30 05:32   
I'll consider this at a later point.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1834 [3 - Current Dev List] Enhancement feature have not tried 2015-12-03 09:15 2019-12-05 18:37
Reporter: KB3NPH Platform:  
Assigned To: DOUG OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module:
Testing: Not Started
Summary: Selectable Date Format in QSL Labels
Description: Ticket# 101724
I would like to print QSL labels in the format "01 DEC 2015" instead of the default "12/1/15".
I tried changing my system prefs, which changed the format in Logbook to show 01-DEC-15, but when trying to print a QSL label, it shows the date as "01-15-00" Is there a method to have date show the month in text instead of numeric; and to show the full year?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0000680)
KB3NPH   
2015-12-03 12:35   
By way of further explanation, US format is MM/DD/YY, while most of the rest of the world indicates DD/MM/YY. 12/1/15 can be interpreted as 12 January 2015 or 1 December 2015. Common recommendations for QSLS are to format date as DD/MMM/YY to avoid confusion, with the month being text rather than numeric. I would appreciate either ran enhancement or workaround that allows me to print labels in that manner.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1800 [3 - Current Dev List] Bug minor have not tried 2015-10-15 06:03 2019-12-05 18:36
Reporter: user47 Platform:  
Assigned To: DOUG OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Label
Testing: Not Started
Summary: Dymo label print issue
Description: I get a wrong format for my choosen label

Your size is DYMO 99012 = 83.8mm x 25.4mm

The warning is : Defined Labels are larger than the paper size

It must be DYMO 99012 = 89mm x 36mm ( so it wrinten on the official box in the Netherlands )

after changing it the program it still say my label won't fit ....

I can print ( Dymo 330 Turbo ) but i need to change it every time

Where can change te size so i wont get a warning ???


Thanks 73 Rene PA3CQF
Tags:
Steps To Reproduce: Try to print - gets error message -Defined Labels are larger than the paper size.
Additional Information: .. ticket 115866
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1649 [3 - Current Dev List] Bug minor have not tried 2014-06-10 18:35 2019-12-05 18:36
Reporter: user36 Platform:  
Assigned To: DOUG OS:  
Priority: high OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Label
Testing: Not Started
Summary: Logbook - Problems with Brother QL-700 and DK-11201 Labels
Description: Trying to print in this combination locks up Logbook and requires a restart of Logbook to continue.
Tags:
Steps To Reproduce: See Additional Information.
Additional Information: Refer to ticket 483836.

QSL Label Printer Issues
Release date 05/15/2014
Version 6.2.3.271
Operation system Windows 8.1. 64 bit
Printer Brother QL-570 & QL-700 with labels DK-11201
Label Printing Issue still with HRD v6.2 RC 2 – 267
I’m still having issues printing QSL labels with the latest release. I was hoping that this would have been
sorted with this latest release Version 6.2.3.271.
OK here are the problem issues I have found when trying to print labels.
Deleting the LabelDefs.xml has no effect.
In Logbook – Print Setup. If you have more than one printer on your system your selection is not saved and next time you start the logbook program the setting reverts to the computers selected default printer not
HRD’s.
In Logbook – Print Labels – Print Tab - Selecting Label Printer. This does not save the selected printer if more than one printer is installed on the computer. The selection field always reverts back to the computers
default printer each time the print labels are selected from start-up. My label printer is not the default
printer.
File – Print Labels – Print Tab – select my label printer (QL-570 or QL 700 which is a single label printer) – the
right label section shows 4 labels where it should be one.
When I try to print an Address or QSL label I see at the top of the window “Labels (Not Responding)” the
window greys out and locks up the logbook program and I have to restart the logbook program again to use it.
When you open active printers is showing that it is spooling continues.
I have copied the old settings from version v6.1.4.189 release 6.1.4 that works on my Windows 8.1. 64 bit.
When v6.2 RC 2 – 267 version of the program with these settings entered still have the same issue.
I seem to remember that there were issues with HRD some time ago regards the US and UK windows installation. I wonder if this is happening here.
I have tried installing over the old versions and uninstalled everything and installed the latest version and this does not resolve the issue with Version 6.2.3.271.
I can still only run v6.1.4.189 release 6.1.4 on the computer when installed to enable me to have the label
printing facility.
I don’t think it’s the printer driver as it worked with v6.1.4.189 release 6.1.4 and other programs that use the printer so I assume that this is OK.
If any of the HRD programmers need a computer with the Brother QL-700 printer attached with the DK-11201 labels to experiment I will be very happy to give them full control of the computer via remote access.
---
06/03/2014 9:29 pm Jason Boyer
Hello Ian,

If you're up to reinstalling 6.2 again, I suggest backing up your logbook, and saving your settings per the Archive function as detailed in the HRD Manual. Once that is complete, rename or delete the folder C:\Program Data\HRDLLC and reinstall HRD 6.2. That will force HRD to use default settings for labels and
may resolve your printer issues.
---
06/10/2014 12:50 pm
As you asked me to do I did uninstall my old version (6.1.4.189) from my computer and done a fresh of HRD
6.2.3.271 but it was no good as it made any difference.
I also checked my Brother Ql-700 printer driver was up to date; it was as I checked on the Brother website.
Deleting the LabelDefs.xml has no effect. When you open active printers is showing that it is spooling continues. When I try to print an Address or QSL label I see at the top of the window “Labels (Not Responding)” the window greys out and locks up the logbook program and I have to restart the logbook program again to use it.
I have tried all that I can.
I know what I am at, as I am a computer tech and fix Home computer for a living.
There seems to be something wrong with the HRD label printing. If any of the HRD programmers need a computer with the Brother QL-700 printer attached with the DK-11201 labels to experiment I will be very happy to give them full control of the computer via remote access.
Just let me know and I will take 6.1.4.189 off again and put 6.2.3.271 for them to work at. I have Skype and TeamViewer on my pc.
Attached Files:
Notes
(0000625)
WA9PIE   
2015-10-01 13:41   
The following trouble ticket is related to this bug.

http://tickets.hrdsoftwarellc.com/scp/tickets.php?id=1377

It was assigned to Erik. I'm closing the trouble ticket and sending the bug tracking number.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2298 [3 - Current Dev List] Enhancement feature N/A 2017-12-22 16:35 2019-12-05 18:27
Reporter: KC7FPF Platform:  
Assigned To: KC7FPF OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Functional
Testing: Not Started
Summary: Option to print qsl label via another call
Description: When will it be possible to print on a label that qsl via a other call
When this option QSL Via is used in the logbook.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: QSL via1.jpg (49,804 bytes) 2017-12-22 16:35
https://development.hamradiodeluxe.com/file_download.php?file_id=269&type=bug
Notes
(0009489)
WA9PIE   
2019-12-05 18:27   
Kevin - I need more information. What's the use-case here?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3330 [3 - Current Dev List] Bug minor have not tried 2019-06-07 08:33 2019-12-05 18:26
Reporter: K7ZCZ Platform:  
Assigned To: DOUG OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.6.0.214  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: SW License Mgmt
Sub-Module: SW License Client
Testing: Not Started
Summary: Soraco Licenser assigns bogus version number to shared memory license structure
Description: Data of an incorrect format is being set to a shared structure in the MyStation shared memory. Maybe this doesn't lead to trouble, but it should be investigated -- I don't believe the code can possibly be correct.
Tags:
Steps To Reproduce: This warning appears in builds of the 6.6 tree:

c:\hrd66\hrdstation\hrdsoracolicenser.cpp(179): warning C4244: '=': conversion from 'double' to 'DWORD', possible loss of data


Investigating the warning, we find this code:

   g_pSharedMemory->sm_License[0].lic_dwMaxVersion = 6.5;


lic_dwMaxVersion is a DWORD, so it can't possibly accept a floating point value. This field typically uses a packed representation of the version number, where some bits have the major version number and some bits have the minor version number. Other references to this field in the project show that it's packed and unpacked.

This new warning should be investigated and fixed so we can be sure that it isn't causing trouble, or setting a trap for the future.

Additional Information:
Attached Files:
Notes
(0008034)
DOUG   
2019-06-10 23:13   
Yeah that shared memory code is all over the place so I didn't want to mess with it much. I guess I just defaulted it to a bad value, and ignored the compiler warning. I don't think that value is something to we have to worry about any more. So I am just setting it to HRDVER now.
(0008035)
K7ZCZ   
2019-06-10 23:23   
Is the shared memory mechanism something we can disconnect altogether?
(0008038)
DOUG   
2019-06-10 23:45   
That was the first approach I took. Then I realized that it would require touching a bunch of code across a lot of the projects. I then decided to leave it so my changes were confined to HRDStation.dll.
(0008183)
DOUG   
2019-06-23 17:07   
I am going to resolve this one, I fixed the original bug, and getting rid of the shared memory code is not something we are going to do in this version.
(0008553)
WA9PIE   
2019-09-14 02:23   
How do we test this?
(0008576)
DOUG   
2019-09-22 14:04   
This was primarily getting rid of a compiler warning and the variable in question isn't used. So I would say as long as the program runs and allows you to license, this one is fixed.
(0009123)
WA9PIE   
2019-11-04 03:36   
Accepted as validated.
(0009125)
K7ZCZ   
2019-11-04 07:23   
This isn't adequately fixed. If the field isn't used, it should be removed and the surrounding code simplified.
(0009126)
K7ZCZ   
2019-11-04 07:29   
Aside from copying passed values around, it looks to me like the only reads of the field are in HRDStationIsDeveloper() and HRDIsValidLicense(), where different license types (of the LIC_TYPE enum) are identified.

HRDStationIsDeveloper() is never called. Why can't it be removed?

HRDIsValidLicense() is called, but only ever chekced for a true/false response. This seems closely related to 3450, which identifies more license client code that seems obsolete.
(0009205)
WA9PIE   
2019-11-08 02:21   
Not sure what to do with this. I took the FiV off it until we sort it out.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3437 [3 - Current Dev List] Bug crash always 2019-08-24 12:56 2019-12-05 18:23
Reporter: KB3NPH Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Functional
Testing: Not Started
Summary: Immediate crash and minidump when you start HRD
Description: Ticket #516291 - Customer installed HRD and when he tries to run it immediately crashes indicating a minidump was created. There's no splash screen, no nothing except the error screen indicating that it created a minidump.

I pulled the minidump and it's attached.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files: HamRadioDeluxe_20190824_173317.mdmp (472,598 bytes) 2019-08-24 12:56
https://development.hamradiodeluxe.com/file_download.php?file_id=734&type=bug
Notes
(0008435)
PD9FER   
2019-08-25 02:42   
Set this to Private Please!
(0008449)
K7ZCZ   
2019-08-26 15:08   
This dump is from build 6.6.0.237.

Looks like something is failing in the new licensing code. The callstacks are here. The HRESULT from the QLM call looks like E_POINTER, but I'm not positive that the args match the sources I have completely. I don't see ProductID on the stack, for example.

Doug should take a look.

0:000> .ecxr
eax=0039c7dc ebx=0039c880 ecx=00000003 edx=00000000 esi=728d520c edi=72911e8c
eip=74bbc5af esp=0039c7dc ebp=0039c82c iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
KERNELBASE!RaiseException+0x58:
74bbc5af c9              leave
0:000> kb
  *** Stack trace for last set context - .thread/.cxr resets it
 # ChildEBP RetAddr  Args to Child              
00 0039c82c 7286b8da e06d7363 00000001 00000003 KERNELBASE!RaiseException+0x58
01 0039c870 728690a4 0039c880 72911e8c 728d3314 HRDStation!_CxxThrowException+0x66 [d:\agent\_work\3\s\src\vctools\crt\vcruntime\src\eh\throw.cpp @ 129] 
02 0039c890 72868c91 80004003 008c7a5c 046e0034 HRDStation!_com_raise_error+0x24 [d:\agent\_work\3\s\src\vctools\compiler\cxxfe\sl\vccom\comraise.cpp @ 18] 
03 0039c8ac 726fdb45 80004003 046e0034 728e2660 HRDStation!_com_issue_errorex+0x91 [d:\agent\_work\3\s\src\vctools\compiler\cxxfe\sl\vccom\comsupp.cpp @ 66] 
04 0039c8e0 726ffd8f 046e0034 00000000 00000006 HRDStation!QlmLicenseLib::IQlmLicense::DefineProduct+0x85 [c:\hrd66\hrdstation\release\qlmlicenselib.tli @ 2675] 
05 0039c95c 726f1a90 6c2c3142 ffffffff 00027060 HRDStation!LicenseValidator::LicenseValidator+0x22f [c:\hrd66\hrdstation\licensevalidator.cpp @ 134] 
06 0039d6a8 726f5f74 00000000 6c2c309a 013b1590 HRDStation!HRDSoracoLicenser::CheckLicense+0xe0 [c:\hrd66\hrdstation\hrdsoracolicenser.cpp @ 61] 
07 0039d770 726f30e8 00c3d7af 6c0db96b 013b1590 HRDStation!_HRDInitStation+0x2a4 [c:\hrd66\hrdstation\hrdstationlicense.cpp @ 320] 
08 (Inline) -------- -------- -------- -------- HRDStation!CHRDStationApp::InitializeStation+0xc7 [c:\hrd66\hrdstation\hrdstation.cpp @ 160] 
09 0039d774 00c3d7af 6c0db96b 013b1590 00c3d620 HRDStation!InitializeStation+0xc8 [c:\hrd66\hrdstation\hrdstation.cpp @ 129] 
0a 0039fd4c 0115725f 00000000 014c885c 7efde000 HamRadioDeluxe!CHamRadioDeluxeApp::InitInstance+0x18f [c:\hrd66\hamradiodeluxe\hamradiodeluxe.cpp @ 260] 
0b 0039fd64 00e9f443 00b80000 00000000 007e1a7e HamRadioDeluxe!AfxWinMain+0x5f [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\winmain.cpp @ 37] 
0c (Inline) -------- -------- -------- -------- HamRadioDeluxe!invoke_main+0x1a [d:\agent\_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 118] 
0d 0039fdb0 766b343d 7efde000 0039fdfc 772a9802 HamRadioDeluxe!__scrt_common_main_seh+0xf8 [d:\agent\_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 
0e 0039fdbc 772a9802 7efde000 7702d5e3 00000000 kernel32!BaseThreadInitThunk+0xe
0f 0039fdfc 772a97d5 00e9f4c7 7efde000 00000000 ntdll!__RtlUserThreadStart+0x70
10 0039fe14 00000000 00e9f4c7 7efde000 00000000 ntdll!_RtlUserThreadStart+0x1b
0:000> kp
  *** Stack trace for last set context - .thread/.cxr resets it
 # ChildEBP RetAddr  
00 0039c82c 7286b8da KERNELBASE!RaiseException+0x58
01 0039c870 728690a4 HRDStation!_CxxThrowException(void * pExceptionObject = 0x0039c880, struct _s__ThrowInfo * pThrowInfo = 0x72911e8c)+0x66 [d:\agent\_work\3\s\src\vctools\crt\vcruntime\src\eh\throw.cpp @ 129] 
02 0039c890 72868c91 HRDStation!_com_raise_error(HRESULT hr = <Value unavailable error>, struct IErrorInfo * perrinfo = <Value unavailable error>)+0x24 [d:\agent\_work\3\s\src\vctools\compiler\cxxfe\sl\vccom\comraise.cpp @ 18] 
03 0039c8ac 726fdb45 HRDStation!_com_issue_errorex(HRESULT hr = 0x80004003, struct IUnknown * punk = 0x046e0034, struct _GUID * riid = 0x728e2660 {41791E5A-1B22-40F0-A7B2-322F361DFFBC})+0x91 [d:\agent\_work\3\s\src\vctools\compiler\cxxfe\sl\vccom\comsupp.cpp @ 66] 
04 0039c8e0 726ffd8f HRDStation!QlmLicenseLib::IQlmLicense::DefineProduct(class _bstr_t productName = class _bstr_t, long majorVersion = 0n6, long minorVersion = 0n6, class _bstr_t encryptionKey = class _bstr_t, class _bstr_t persistenceKey = class _bstr_t)+0x85 [c:\hrd66\hrdstation\release\qlmlicenselib.tli @ 2675] 
05 0039c95c 726f1a90 HRDStation!LicenseValidator::LicenseValidator(void)+0x22f [c:\hrd66\hrdstation\licensevalidator.cpp @ 134] 
06 0039d6a8 726f5f74 HRDStation!HRDSoracoLicenser::CheckLicense(int bForceDlg = 0n0)+0xe0 [c:\hrd66\hrdstation\hrdsoracolicenser.cpp @ 61] 
07 0039d770 726f30e8 HRDStation!_HRDInitStation(void)+0x2a4 [c:\hrd66\hrdstation\hrdstationlicense.cpp @ 320] 
08 (Inline) -------- HRDStation!CHRDStationApp::InitializeStation+0xc7 [c:\hrd66\hrdstation\hrdstation.cpp @ 160] 
09 0039d774 00c3d7af HRDStation!InitializeStation(void)+0xc8 [c:\hrd66\hrdstation\hrdstation.cpp @ 129] 
0a 0039fd4c 0115725f HamRadioDeluxe!CHamRadioDeluxeApp::InitInstance(void)+0x18f [c:\hrd66\hamradiodeluxe\hamradiodeluxe.cpp @ 260] 
0b 0039fd64 00e9f443 HamRadioDeluxe!AfxWinMain(struct HINSTANCE__ * hInstance = 0x00b80000, struct HINSTANCE__ * hPrevInstance = 0x00000000, wchar_t * lpCmdLine = 0x007e1a7e "", int nCmdShow = 0n1)+0x5f [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\winmain.cpp @ 37] 
0c (Inline) -------- HamRadioDeluxe!invoke_main+0x1a [d:\agent\_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 118] 
0d 0039fdb0 766b343d HamRadioDeluxe!__scrt_common_main_seh(void)+0xf8 [d:\agent\_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 
0e 0039fdbc 772a9802 kernel32!BaseThreadInitThunk+0xe
0f 0039fdfc 772a97d5 ntdll!__RtlUserThreadStart+0x70
10 0039fe14 00000000 ntdll!_RtlUserThreadStart+0x1b

(0008450)
DOUG   
2019-08-26 21:52   
ProductID is hard coded to 3.

First off, we can "fix" the crash, meaning that it won't crash happen any more. But this is a symptom that QLM in general is not working. All these QLM calls throw com exceptions when they fail, but for the most part we have not been catching them (as Mike B. has noticed before). There really aren't supposed to fail even the QLM sample code doesn't catch these either. This call "DefineProduct" pretty much does nothing to crazy, this is hidden in the dll but with process monitor I can tell it is not accessing any file or registry when I step over it.

So the fix would be to just catch it and return some generic error message. The similar exceptions I have caught from QLM before is just "Unknown Error".

So while I have no magic cure for this one, here is what I can tell from the dump.
The crash on the first call after loading the dll. So this probably means that there is some general compatibility issue here.
If I had to guess this would be an issue with a dll the QLM is dependent on (I believe is uses a bunch of .net assemblies). There is also a slight possibility that they have an old version of the dll installed and registered on that machine.

One thing that jumps out at me is that this appears to be a Windows 7 machine, While this shouldn't be a problem, it probably increases the likelihood that some required dll is not there. I would ask user the make sure all updates are applied and the latest .net framework updates are installed.

What is the normal protocol for trying to support users with a crash like this?
(0008451)
PD9FER   
2019-08-27 06:03   
The procedure I use resolves the issue at 99% of the time.
Just by letting the customer do a full Windows Update, reboot and Install Ham Radio Deluxe again on top of the existing install.
(0008452)
K7ZCZ   
2019-08-27 09:53   
In the source code, I can see the magic number "3" hard coded as the first parameter to IQlmLicense::DefineProduct().

However, it's absent from both the kp and kb call stacks. This seems really strange, as digging through the disassembly I don't see how the parameter value 3 is developed or passed to the DefineProduct() method. It's as if the parameter doesn't exist. Given the HRESULT is E_POINTER, I'm trying to figure out why the first parameter in the kb dump shows 0x00000000 (before 0x00000006) in the DefineProduct() call.

Indeed, it's a Windows 7 host. The dump shows version 4.0.30319 of mscoreei.dll and the mscorelib.ni modules. Is that too old?
(0008566)
KB3NPH   
2019-09-19 07:56   
(Last edited: 2019-09-19 08:00)
This issue has been resolved. It turns out to be that MS .NET Framework 4.5 or newer has to be installed on the computer due to the QLM additions to the HRD software. So, we can mark this Mantis issue resolved with no action required, although as an afterthought, it might be a good idea to put a check in the installer and if .NET 4.5 or newer is not found on the computer, it should be downloaded and installed in our installer.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2926 [4 - Business Priorities] Maintenance tweak always 2018-10-30 08:05 2019-12-05 17:50
Reporter: PD9FER Platform:  
Assigned To: DOUG OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: IOTA
Testing: Not Started
Summary: New and altered IOTA data in Logbook
Description: https://www.iota-world.org/info/new_groups_2018.pdf

There are some changes/additions in the IOTA designators (see link above)
Customer worked a station in IOTA NA-249P but it is not in the list.
Tags:
Steps To Reproduce: Open ALE
Open the IOTA List dropdown
Look for NA-249 It is not there.

Additional Information: Ticket #874915

Changes where made, use the link https://www.iota-world.org/info/new_groups_2018.pdf
for those.

The file was provided by the IOTA site on RSGB in XML format (filename: fulllist.xml). Periodically, we downloaded it and made the update. It seems that there are new entries to this list.

Attached Files: response.json (1,356,459 bytes) 2019-12-02 00:24
https://development.hamradiodeluxe.com/file_download.php?file_id=881&type=bug
Notes
(0007401)
WA9PIE   
2019-02-15 11:02   
We've had a few more tickets on this topic and we should address it.
(0007724)
KB3NPH   
2019-03-23 07:26   
Ticket #827216 just received about when and how the IOTA in HRD would be updated.
(0007845)
K7ZCZ   
2019-04-09 11:18   
Where can I find documentation on the suggested API?
(0007846)
K7ZCZ   
2019-04-09 12:05   
I've dug around on their site a bit, and this is all I can find:
https://www.iota-world.org/management-news/896-calling-software-developers.html

so I've written the email address given there to request information about their API, licensing, and acceptable use.
(0007847)
K7ZCZ   
2019-04-11 05:18   
I got in touch with the IOTA team. A given API key is good for only 1000 queries per day, so we'll need to build a reflector -- in the same way we have for the solar weather data. We'll need to decide how that works, how often it updates, and how it is monitored.

Architecturally, we'll need to figure out how to handle the format change; the existing code expects an XML format for IOTA data, while the new format is JSON. Does the forwarding service provide XML, or JSON, or a completely new format? It's not much fun parsing JSON in C++, so it seems like we should stick with XML or invent our own format -- seems like CSV would be fine, and simpler and faster than XML. Either way, if we're not sending JSON to the applications, then we need to have code translate the JSON into the redistributed format rather than simply serve a specific file.

I'm not sure how these decisions should/would be addressed by the team.
(0007929)
WA9PIE   
2019-05-10 18:31   
Doesn't this API essentially build the list? And if so, can't we build the list once... at the time we compile code?
(0007931)
K7ZCZ   
2019-05-12 20:52   
If we build the list when the code is complied, then we won't pick up changes until the next version is compiled. Customers won't pick up the changes until the next time they install a new version. Building new versions of code to accommodate changes in external data doesn't seem like a good pattern to me.

Plus, as I detail above, the API produces data in a format that we're not prepared to consume.
(0007932)
K7ZCZ   
2019-05-13 12:57   
Attached are the IOTA docs I was sent. They're very scant--in particular, no meaningful definitions for each field in the data that's provided by the API.

On our side, we don't have any documentation for the existing IOTA XML format, or for any of the IOTA features themselves. This means we have to go through the code to figure out what the data does and what it's used for. Then, we'll need to get data from the new IOTA API and compare it to what we can infer about the old XML format to see if there's a direct replacement or not ... or if some translation is needed.
(0007933)
K7ZCZ   
2019-05-13 12:58   
second try at the attachment ...
(0007934)
K7ZCZ   
2019-05-13 12:59   
Looks like attachments aren't working right for me :(
(0009479)
PD9FER   
2019-11-29 04:27   
Ticket # 244581

Customer comment:
If maintaining the IOTA list is considered an enhancement it would be nice if I could manually enter this information. Otherwise I can't maintain an accurate log.

Also, here are more IOTA's that are missing from the list.
EU-192 OJ9, SM Kataja/Inakari Island

NA-249 KP3, 4 Puerto Rico's Coastal Islands
NA-250 KL Yakutat Borough group

OC-297 FO Morane Atoll
OC-298 FO Tatakoto Atoll
OC-299 V6 Yap East Group
OC-300 T31 McKean and Nikumaroro Atolls

SA-101 CE0 Juan Fernandez Archip (Alejandro Selkirk)
(0009484)
WA9PIE   
2019-12-02 00:24   
Going back to the post I made regarding the API key, I'm attaching the resulting json file.

We need to add this to the build script so that this is pulled and updated whenever we do a build. We just need to figure out how to ingest the json file as attached.

This replaces a file in resource called something like iota.xml.

Mike
(0009488)
WA9PIE   
2019-12-05 17:49   
(Last edited: 2019-12-05 17:50)
Basically, one of these things is what needs to happen:

Option 1:
- at the time of build, we hit this URL with this API key
- obtain the json file
- reformat it into the format currently in Logbook - OR modify Logbook to consume the json file directly
- add it into the build as a resource
- done

Option 2:
- we modify Logbook so that it can consume the json file directly
- we let Logbook update the IOTA file in a similar way as how the Country List gets updated now
- done
(this gets the updates to the users more quickly without the need for a new build; the downside is that it could expose our API key)

I'm not sure I have a preference. But option 2 has an added benefit.

Thoughts?



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3607 [1 - Backlog] Maintenance major random 2019-11-28 08:24 2019-12-05 14:31
Reporter: PD9FER Platform:  
Assigned To: OS:  
Priority: urgent OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Call lookup
Testing: Not Started
Summary: Lookups take longer then normal
Description: V6.7.0.254
Lookups take over 5 seconds whilst previously it was almost direct.
I had some with over 45 seconds lookup, that was fixed by a reinstall.

Those with the 5 second delay will not be fixed as it seems.
Tags:
Steps To Reproduce: In the Enabled methods put only QRZ and country list
On Test do a lookup.
Also do an ALE lookup.


Additional Information: Ticket #109669
Log file attached.
Attached Files: HRD Logbook Logfile 2019-11-28 091310.txt (1,163 bytes) 2019-11-28 08:24
https://development.hamradiodeluxe.com/file_download.php?file_id=878&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3614 [1 - Backlog] Enhancement minor always 2019-12-04 07:38 2019-12-04 07:38
Reporter: PD9FER Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rotator
Sub-Module: Interfacing
Testing: Not Started
Summary: Add Support for Radant rotator Controler.
Description: From customer:
Would like to connect Radant AZ-2000(http://www.povorotka.ru/produkciya/povorotnye_ustroystva/povorotnoe_ustrojstvo_az2000_srednee/) rotator to HRD. this one does support Yaesu GS-232 protocol, it supposes to work. however it's not true. have tried with A and B options under Rotator app. it cannot connect formally
Tags:
Steps To Reproduce:
Additional Information: Could you please contact the manufacturer via ua3apa@mail.ru (Vladzimir Ruchko)? have had discussion about the rotator and HRD compatibility issue and he will be happy to work with you to get it supported. feel free to make a reference to me Dmitry (EU1TL).
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3613 [1 - Backlog] Bug feature unable to reproduce 2019-12-03 15:46 2019-12-03 15:46
Reporter: KC7FPF Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Label
Testing: Not Started
Summary: QSL Labeling printing
Description: Selecting the Dymo label there is no print on the label I went to a larger label to see if it was just off the address label but no print. Label printer does work with other software.

When selecting a different size font it will print. However it printed content is small. See the attached photos.

Reference OS ticket 300669
Tags:
Steps To Reproduce: I have attempted to recreate the issue with printing label. However I am not able to reproduce the issue on two different PC's
Additional Information:
Attached Files: label issue.jpeg (1,822,447 bytes) 2019-12-03 15:46
https://development.hamradiodeluxe.com/file_download.php?file_id=887&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3612 [1 - Backlog] Enhancement minor have not tried 2019-12-03 11:25 2019-12-03 11:25
Reporter: KB3NPH Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: All
Sub-Module: Rig Control
Testing: Not Started
Summary: Add support for the JRC JST245
Description: Ticket #224270 - A request has been made to add the JRC JST245 radio to our supported radios.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3611 [1 - Backlog] Bug minor random 2019-12-02 09:25 2019-12-02 09:49
Reporter: PD9FER Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Label
Testing: Not Started
Summary: Selecting contacts and try to print Label crashes Logbook
Description: When trying to print labels a LB crash follows
Tags:
Steps To Reproduce: Select 3 QSO's
Right click
Select File > Print > Label
LB Crashes
Additional Information: Ticket #372631

Dump files in the related Mantis # folder in Google Drive/dumps
Attached Files:
Notes
(0009485)
PD9FER   
2019-12-02 09:48   
Other customer with the same.
Ticket #886379


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3610 [1 - Backlog] Bug minor always 2019-12-02 08:26 2019-12-02 08:26
Reporter: KB3NPH Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Satellite Tracking
Sub-Module: Functional
Testing: Not Started
Summary: V6.7.0.244 manual tuning delay not working
Description: In HRD Satellite Tracking Options > Manual Tuning tab, the time delay settings between +3 to -3 are not do not effect the switching as they should. There are instructions on the tab that explains how this feature is supposed to work, so I don't believe a more detailed description here is really necessary since all the information is on the tab itself.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3609 [1 - Backlog] Bug minor always 2019-12-02 05:14 2019-12-02 05:14
Reporter: PD9FER Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: IOTA
Testing: Not Started
Summary: IOTA field in My Station can't be empty
Description: From customer:
There is no possibility to leave IOTA (My IOTA) field in My Station window empty if once it was chosen for another location. The value of this field is automatically moved to the location where I would like to have it 'none'.

(see attachments)
Tags:
Steps To Reproduce: Open Tools > Configure > My station
Add a location that has an IOTA designator and select the correct IOTA field.
Now Add a 2nd location (non IOTA)
The previous IOTA number is still displayed instead of saying "None"
Additional Information: Ticket #213559
Attached Files: My_station_1.jpg (117,104 bytes) 2019-12-02 05:14
https://development.hamradiodeluxe.com/file_download.php?file_id=884&type=bug
My_station_2.jpg (120,571 bytes) 2019-12-02 05:14
https://development.hamradiodeluxe.com/file_download.php?file_id=885&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3606 [1 - Backlog] Bug feature always 2019-11-25 11:38 2019-11-25 11:38
Reporter: KC7FPF Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Label
Testing: N/A
Summary: QSL label multi-QSO printing broken
Description: This problem ONLY happens when the "QSL Modern" label format is selected. When i switch to "QSL Traditional" multiple QSOs are listed correctly. Hope this helps.

Please refer to OS Ticket: 171096

 
Tags:
Steps To Reproduce: Have logbook open:
Select multi contacts to print QSL labels.
Select File:
Select Print: labels
As noted in issue. If QSL Modern is selected. the contact information for the contact is incorrect. However if QSL Traditional is selected it will print the contact information correctly.

Additional Information: I have tested this and I do get the same result.
Attached Files: Annotation 2019-11-22 130425.jpg (269,741 bytes) 2019-11-25 11:38
https://development.hamradiodeluxe.com/file_download.php?file_id=872&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3300 [Ham Radio Deluxe] Bug minor have not tried 2019-04-16 18:38 2019-11-24 22:41
Reporter: K7ZCZ Platform:  
Assigned To: K7ZCZ OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.7.0.244  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: Get IC-9700 working with Satellite Tracker
Description: Some work is necessary to make sure the Satellite Tracker app works with the IC-9700 radio. This is a cool new duplex VHF/UHF radio (plus 23 cm ...) so we should put it through its paces in Satellite Track and make sure it's working right.
Tags: IC-9700, ICOM
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0007875)
K7ZCZ   
2019-04-23 12:11   
fixed in the 6.7 branch with this checkin:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4962
(0008605)
g3ucq   
2019-09-23 06:04   
Unable to test
(0009455)
KB3NPH   
2019-11-23 10:17   
(Last edited: 2019-11-24 22:41)
HRD V6.7.0.244 - Ticket#696228 - Reports on the 9700 and Satellite tracking indicate that HRD is having issues when splitting repeater satellites between UHF/VHF. It appears the 9700 does NOT handle the split as most other radios do using VFO-A as RX and VFO-B as TX. When the 9700 is put into "Split" mode, it is using the VFO-A MAIN for RX and VFO-A SUB for the TX. It doesn't appear that HRD is handling the split in this way and is causing problems with tracking.

The same customer reports that there are problems with other areas of HRD where the two receivers in the 9700 are not displayed. HRD never shows both receivers in the 9700 correctly when just connecting to it. Unlike the 7610 that does.

In the Main display on HRD, if you select Rec 1 or 2 either VFO, it displays the selected one. But the sub is either wrong or not displayed.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3604 [1 - Backlog] Bug minor random 2019-11-23 07:51 2019-11-23 11:20
Reporter: PD9FER Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Call lookup
Testing: Not Started
Summary: Lookup Pane returning incorrect Data
Description: This is not happening every time.
But When I enter WA9PIE or KB3NPH in the Callsign Lookup pane, the Licensee info stays empty.
When entering K3LR I get the wrong info... see attached screenshots
Tags:
Steps To Reproduce: Have lookup order set to QRZ.com > Logbook > Country list
Enter one of the above calls and review the results against the results.
Additional Information: Version 6.7.0.252
Attached Files: Lookup Wrong 1.jpg (136,048 bytes) 2019-11-23 07:51
https://development.hamradiodeluxe.com/file_download.php?file_id=867&type=bug
Lookup Wrong 2.jpg (80,473 bytes) 2019-11-23 07:51
https://development.hamradiodeluxe.com/file_download.php?file_id=868&type=bug
Lookup Wrong.jpg (61,910 bytes) 2019-11-23 07:51
https://development.hamradiodeluxe.com/file_download.php?file_id=869&type=bug
Knipsel.JPG (65,428 bytes) 2019-11-23 11:20
https://development.hamradiodeluxe.com/file_download.php?file_id=871&type=bug
Notes
(0009456)
PD9FER   
2019-11-23 11:20   
These are my Test results


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3605 [1 - Backlog] Bug minor always 2019-11-23 07:54 2019-11-23 07:54
Reporter: PD9FER Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Rotators
Testing: Not Started
Summary: Selecting Heading from Lookup Pane turns Rotor to 0 degrees
Description: When clicking the Heading (next to the Car icon) in the Lookup pane, the rotor turns to 0 degrees.
Tags:
Steps To Reproduce: Have a Demo or real rotor connected and the Rotor app running
In Logbook select View > Rotator and click connect

In the Lookup pane type K3LR
Watch the results.
Click on the Heading next to the Car icon.
Watch Rotor goes 0 degrees.
Additional Information:
Attached Files: Rotor zero.jpg (61,060 bytes) 2019-11-23 07:54
https://development.hamradiodeluxe.com/file_download.php?file_id=870&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3603 [1 - Backlog] Bug feature always 2019-11-22 15:32 2019-11-22 15:32
Reporter: KC7FPF Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: DM780
Sub-Module: (select)
Testing: Not Started
Summary: Program Options /Soundcard shortcut
Description: When setting up the DM780 in Program Options:
Item Soundcard: When adjusting the soundcard options : Input (Receive) and Output (Transmit) The small tab located under the device space to the right was a short tab that would allow the user to access the sound option for the windows OS. Recent releases for HRD indicate that this option is now deactivated.
Tags:
Steps To Reproduce: Digital Mater is open:
Select Program Options:
Select Soundcard; Once here click on the tab located under the device option lower right.
No action results.

Additional Information: Action to reproduce was confirmed my myself, Tim, and Ferry
Attached Files: Dm780soundcard.JPG (160,999 bytes) 2019-11-22 15:32
https://development.hamradiodeluxe.com/file_download.php?file_id=866&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3602 [1 - Backlog] Bug minor always 2019-11-22 15:08 2019-11-22 15:08
Reporter: KC7FPF Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: (select)
Testing: Not Started
Summary: HRD Logbook Printout Cover page
Description: The cover page on my QSO printout shows a wrong "from" date.
When attempting to print a actual printout of the HRD logbook. On the cover page it will display the incorrect From Date.
Please refer to OSTicket #534865

Tags:
Steps To Reproduce: Open logbook:
Select File/Print:
Select the continue tab:
Select the OK tab to print the document

Additional Information: The issue was tested and confirmed both Ferry and I
Attached Files: Logbook printout.JPG (59,552 bytes) 2019-11-22 15:08
https://development.hamradiodeluxe.com/file_download.php?file_id=865&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2306 [1 - Backlog] Bug minor always 2018-01-10 05:05 2019-11-22 04:05
Reporter: PD9FER Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Awards
Testing:
Summary: /MM (Maritime Mobile) QSO added to DXCC Awards count
Description: Working an /MM station the qso is added to the Awards tracking page.
This whilst /MM contacts must be ignored.

User Manualy set LotW & QSL Sent & Received to Ignore but the entry still appears in Award tracking.
Tags:
Steps To Reproduce: Open ALE
Log an contact with /MM suffix
Set QSL and LoTW status to Ignore to Send and received

Additional Information:  Ticket #595585 (all info is in there)
Attached Files:
Notes
(0009451)
WA9PIE   
2019-11-21 19:32   
Ferry... there was already a bug open on this topic.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3582 [3 - Current Dev List] Bug minor always 2019-11-13 02:20 2019-11-21 19:32
Reporter: PD9FER Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: ALE Window
Testing: Not Started
Summary: No eQSL and LoTW indication in ALE
Description: Some versions ago the ALE showed if the contact uses eQSL and/or LoTW
These indicators no longer work (They do work in the Lookup pane VIEW > LOOKUP)
Tags:
Steps To Reproduce: Open ALE
Do a Call lookup on a station known having eQSL and/or LoTW
Watch the indicaters (see attached picture)
Additional Information: Ticket #623620
Attached Files: Capture.JPG (49,565 bytes) 2019-11-13 02:20
https://development.hamradiodeluxe.com/file_download.php?file_id=840&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3596 [1 - Backlog] Bug minor unable to reproduce 2019-11-18 15:31 2019-11-21 17:28
Reporter: KC7FPF Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: (select)
Sub-Module: (select)
Testing: Not Started
Summary: QSL Labeling printing
Description: - If printing more than one QSO with different dates every QSO is printed on a new label (enclosure 1).
- If printing only one call with 4 QSO's on different date only one date is printed on the four lines . The same date were marked as in
See atachments

In earlier versions of HRD same calls at different date were combined at one label (which save QSL cards and labels)
Tags:
Steps To Reproduce: I can not reproduce the error I have attempted
Additional Information: This is issue is inconsistent for customer to customer.
Attached Files: HRD Labelprinting bug-1.pdf (1,273,635 bytes) 2019-11-18 15:31
https://development.hamradiodeluxe.com/file_download.php?file_id=855&type=bug
HRD Labelprinting bug-2.pdf (669,626 bytes) 2019-11-18 15:31
https://development.hamradiodeluxe.com/file_download.php?file_id=856&type=bug
Notes
(0009446)
WA9PIE   
2019-11-21 17:25   
Adding a thread from Forums regarding this:

https://forums.hamradiodeluxe.com/node/51467
(0009447)
WA9PIE   
2019-11-21 17:28   
Here's another related item: https://forums.hamradiodeluxe.com/node/51629


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3191 [3 - Current Dev List] Bug major always 2019-02-22 08:40 2019-11-21 16:50
Reporter: KB3NPH Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Functional
Testing: Not Started
Summary: V6.5.0.195 BETA "Logbook > File > Edit Selections > Manager"
Description: When opening the selections menu and choosing TOP 100, TOP 200.... etc, the filter allows only the most recent 100, 200, etc logbook records to be displayed as it should.

If you select a year it appears to display ALL records. Also if you attempt to edit one of the yearly filters, and enable it. Once you close the Selections menu and reopen it, the filter you just enabled will be disabled, so apparently the dialog is not permitting the filter to be saved to the xml file.

Ticket #189417 - n the Logbook, under Log Book Display, under config, the Selection for All, 100, 500, 1000, 2019, 2018, 2017, 2016, and so on .

The years do not work when I clic on them I get 0 QSOs.

ssb and cw and the all, 100, 500, 1000, work just find.

If I am missing 2018 QSOs can I find them on LOTW and down load them to the HRD logbook?
I had a computer change the old one was replace with a new one. I cannot believe that I have no 2018 QSOs.
Tags:
Steps To Reproduce: Ticket #417924 - Seth posted 02/19/2019 2:35 PM
I am unable to enter the fields for a new selection in HRDLogbook. To reproduce the problem:
1) On main menu go to Logbook/File/Edit Selection/Manager
2) Create a new selection (or copy an existing one)
3) Click on the Fields tab, select enable and enter some criteria. I tried several, all of them exhibited the issue. For this example, set Country not equals United States.
3) Select OK.
4) Pick the selection just created. All countries will show, including United States.
5) Edit the selection that was just created and the field selecting Country will no longer be selected.

I have been able to create and use selections in prior versions of HRD. Looking at the query saved in the LogbookQueries.xml file I see that the information in the Match Field tag wasn't saved for my new query. If I edit the file by hand I can get the query I desire. If I use the UI to modify the query the XML is unchanged. It appears that the fields information is not being saved.
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3601 [1 - Backlog] Bug feature unable to reproduce 2019-11-21 08:53 2019-11-21 08:53
Reporter: KC7FPF Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: (select)
Sub-Module: (select)
Testing: Not Started
Summary: HRD Rotor module problems.
Description: The ROTOR Log File is CONTINUOUSLY being written to as long as the module is running, EVERY SECOND, with the message "Protocol 0x4 not supported" which can create a really large log file real quick. My rotor IS working ok. Please see the attached document for more specific and precise information.
Since I also have an MDS RC-1Y controller I tried it again using the MDS RC-1 Rotator selection and have attached the Logfile for it in text format. The Protocol 0x4 not supported is gone but there are other constant GET STATUS messages being received. Now the RC-1Y that I have is for Yaesu controllers and the rotator selection in HRD is for the RC-1 controller which may have a different set of protocols. It took almost a minute and a half when I selected the configuration for modifications for it to bring up the window..

Please reference OS ticket 167064

Tags:
Steps To Reproduce:
Additional Information: Customer indicated that the issue is not that the HRD rotor is not working. When connected it will continue to write to the Log file the whole length of time it is connected. Customer indicates that it does it with both of the rotors he has.
Attached Files: HRD Rotor Module Problem. (1).odt (7,120 bytes) 2019-11-21 08:53
https://development.hamradiodeluxe.com/file_download.php?file_id=861&type=bug
HRD Rotator Logfile 2019-11-13 162029.txt (4,062 bytes) 2019-11-21 08:53
https://development.hamradiodeluxe.com/file_download.php?file_id=862&type=bug
HRD Rotor Module Problem..odt (20,022 bytes) 2019-11-21 08:53
https://development.hamradiodeluxe.com/file_download.php?file_id=863&type=bug
HRD Rotor desktop.jpg (406,825 bytes) 2019-11-21 08:53
https://development.hamradiodeluxe.com/file_download.php?file_id=864&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3600 [1 - Backlog] Enhancement minor have not tried 2019-11-21 06:47 2019-11-21 06:47
Reporter: KB3NPH Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Functional
Testing: Not Started
Summary: Add "Comment" Field
Description: Ticket #733090 - In the Logbook "Filter" configuration there is no way to filter for items in the "Comment" field. Requests have been made to add the "Comment" field to the filter dropdown menu selections as indicated in the attached image.
Tags:
Steps To Reproduce: 1. Open the HRD Logbook
2. On the logbook toolbar, click on "Filter"
3. In the Filter tool, select one of the options that has the filter dropdown
4. Check dropdown to see there is NO "Comment" filter option which allows entering of a string search.

See Attached Image
Additional Information:
Attached Files: Add Comment Field to Filter Dropdown.jpg (72,636 bytes) 2019-11-21 06:47
https://development.hamradiodeluxe.com/file_download.php?file_id=860&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3584 [3 - Current Dev List] Bug major always 2019-11-13 06:34 2019-11-20 18:29
Reporter: KB3NPH Platform:  
Assigned To: DOUG OS:  
Priority: high OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Data
Testing: Not Started
Summary: FT4 Contacts not logged properly in Logbook to allow confirmations from LoTW
Description: FT4 has been designated as a submode of MFSK by the ADIF board. This puts the FT4 mode in the ADIF3 category which HRD Logbook does not currently support. Mike C and I have discussed this and here are Mike C's recommendations.

1 - create a new field in the database called COL_SUBMODE
2 - we add SUBMODE to the ALE under the existing "Mode" field
3 - correctly save data to Logbook coming from WSJT-X logging via the "QSO Forwarding" function.
4 - update the matching criteria for LOTW so that anything downloaded with MFSK as MODE and FT4 as SUBMODE will match

Tags:
Steps To Reproduce:
Additional Information: After we test the above, we can do this:
* - Modify the table that contains MODE to include SUBMODES as defined by the ADIF:
       http://www.adif.org/310/ADIF_310.htm#Mode_Enumeration

These values should be provided in a drop-down list for the Submode field as Modes are currently.
Attached Files: Submodes.xlsx (11,807 bytes) 2019-11-16 03:55
https://development.hamradiodeluxe.com/file_download.php?file_id=851&type=bug
Submodes.png (79,059 bytes) 2019-11-16 03:55
https://development.hamradiodeluxe.com/file_download.php?file_id=852&type=bug
Notes
(0009317)
WA9PIE   
2019-11-14 06:24   
(Last edited: 2019-11-14 06:31)
Eliminating irrelevant QSO fields... I'm going to explain what needs to be done in order to fix this problem:

Here is the data that comes from WSJT-X to Logbook via "QSO Forwarding":
<mode:4>MFSK <submode:3>FT4

Here's what we need to do with that data:
We need to store MFSK into the COL_MODE field (this already happens)
We need to store FT4 into a new field called COL_SUBMODE (ADIF is <submode:x> where x is the number of characters of text in the field; in the case of FT4, it's <submode:3>FT4)

On LOTW upload, here what we need to do:
We need to include the ADIF field "<submode>" in the LOTW upload. The resulting uploaded data would be:
<mode:4>MFSK <submode:3>FT4

Once these fields are uploaded to LOTW, the QSO Mode appears as "FT4" in LOTW.

On LOTW download, here's what we need to do:
Here is the data that comes down from LOTW to Logbook during LOTW Download when both the MODE and SUBMODE were uploaded:
<mode:4>MFSK <submode:3>FT4

During the LOTW download process in HRD Logbook, we need to add an additional matching criteria for <submode> - only IF IT EXISTS in the downloaded data. (Generally, the data downloaded from LOTW will not include a field where there is no data. So - effectively - both sides are "NULL" in that case and - therefore - match.)

(0009318)
WA9PIE   
2019-11-14 06:28   
Doug... take this on after we get the upcoming 6.7 maintenance release out.
(0009331)
WA9PIE   
2019-11-16 03:55   
To fix this completely, we'll need a table of Submodes that map to Modes. I'm attaching that.

I'm also attaching a mock-up of a "Submodes Editor" (fashioned to be similar to the "Modes Editor").

The Submodes are enumerated here: http://www.adif.org/310/ADIF_310.htm#Submode_Enumeration


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3504 [3 - Current Dev List] Bug major always 2019-10-18 06:41 2019-11-20 18:29
Reporter: PD9FER Platform:  
Assigned To: DOUG OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Functional
Testing: Not Started
Summary: Using QSO Forwarding FT4 is put in the log as MFSK
Description: The problem lies in using QSO forwarding with WSJT-X

WSJT-X Sends ADIF Data as Mode:MFSK Submode:FT4
This causes Logbook to add the QSO as MFSK
Need a workaround so Logbook looks at the Submode string send over via QSO Forwarding.

So logging with JTALERT-X sends Mode FT4
QSO<EOH><CALL:4>LY5O<QSO_DATE:8>20190923<TIME_ON:6>165100<TIME_OFF:6>165300<FREQ:8>14.08084<FREQ_RX:8>14.08084<BAND:3>20m<BAND_RX:3>20m<MODE:3>FT4<RST_SENT:3>-03<RST_RCVD:3>-07<QSL_SENT:1>N<QSL_RCVD:1>N<NAME:7>Bronius<QTH:8>Amerikos<CQZ:2>15<ITUZ:2>29<PFX:3>LY5<CONT:2>EU<DXCC:3>146<COUNTRY:9>Lithuania<GRIDSQUARE:6>KO14wv<DISTANCE:4>1247<TX_PWR:1>5<A_INDEX:1>0<K_INDEX:1>0<SFI:1>0<COMMENT:33>Tnx for FT4 Contact, 73 de PD9FER<MY_GRIDSQUARE:6>JO22OQ<MY_CQ_ZONE:2>14<MY_ITU_ZONE:2>27<STATION_CALLSIGN:6>PD9FER<OPERATOR:6>PD9FER<QSO_COMPLETE:1>Y<EOR>


But WSJT-X via QSO Forwarding produces MFSK
 <call:4>LY5O <gridsquare:4>KO14 <mode:4>MFSK <submode:3>FT4 <rst_sent:3>-03 <rst_rcvd:3>-07 <qso_date:8>20190923 <time_on:6>165138 <qso_date_off:8>20190923 <time_off:6>165337

We need to add some code that monitors QSO Forwarding .
When something with Submode FT4 is seen, then set Mode to FT4 (rewrite the Mode)
Tags:
Steps To Reproduce: In Logbook set Tools > Configure > Modes to Defaults
Run some FT4 QSO's with WSJT-X via QSO Forwarding.

Note that they will be Logged as MFSK but should be FT4.
Additional Information: Comment from Tim:

What I'm seeing here we are chasing our tails. We have people using JTAlert and JTAlert logs to LB and logs the MODE as FT4. Here is an ADI from JTAlert. Take note of the <MODE:3>FT4 field with NO <submode> field.

 <CALL:4>LY5O<QSO_DATE:8>20190923<TIME_ON:6>165100<TIME_OFF:6>165300<FREQ:8>14.08084<FREQ_RX:8>14.08084<BAND:3>20m<BAND_RX:3>20m<MODE:3>FT4<RST_SENT:3>-03<RST_RCVD:3>-07<QSL_SENT:1>N<QSL_RCVD:1>N<NAME:7>Bronius<QTH:8>Amerikos<CQZ:2>15<ITUZ:2>29<PFX:3>LY5<CONT:2>EU<DXCC:3>146<COUNTRY:9>Lithuania<GRIDSQUARE:6>KO14wv<DISTANCE:4>1247<TX_PWR:1>5<A_INDEX:1>0<K_INDEX:1>0<SFI:1>0<COMMENT:33>Tnx for FT4 Contact, 73 de PD9FER<MY_GRIDSQUARE:6>JO22OQ<MY_CQ_ZONE:2>14<MY_ITU_ZONE:2>27<STATION_CALLSIGN:6>PD9FER<OPERATOR:6>PD9FER<QSO_COMPLETE:1>Y<EOR>

 Here is the very same contact being logged using QSO FWD. Note that <mode:4>MFSK <submode:3>FT4. This is completely different from the way it's logged from JTAlert.

 <call:4>LY5O <gridsquare:4>KO14 <mode:4>MFSK <submode:3>FT4 <rst_sent:3>-03 <rst_rcvd:3>-07 <qso_date:8>20190923 <time_on:6>165138 <qso_date_off:8>20190923 <time_off:6>165337 <band:3>20m <freq:9>14.080840 <station_callsign:6>PD9FER <my_gridsquare:6>JO22OQ <tx_pwr:2>15 <comment:33>Tnx for FT4 Contact, 73 de PD9FER <operator:6>PD9FER <eor>

 The way QSO FWD is handling the <mode:4>MFSK <submode:3>FT4 is the correct way this should be handled, however, since we don't have a "submode" field in our logbook, we need the qso to be logged so that the <submode:3>FT4 shows up in the "Mode" column of the HRD Logbook when we are logging using the QSO FWD. This way both the logging from JTAlert AND QSO FWD are logging the same in our logbook.

 In our Logbook, when the contact is logged, we need it to show as "FT4" in the Mode field for 2 reasons. #1 - Since we don't have the "Mode" and "Submode" fields, we need to have "FT4" indicated in the "Mode" field so we can identify the contact as an FT4 contact at a later date. #3 - If our log shows these FT4 contacts as "MFSK" in the Mode column, if we have logged contacts we actually work in the MFSK mode, and have that logged for those contacts, in the future when we look at our logbooks, how are we going to tell which are FT4 contacts and which are true MFSK contacts?

 For more evidence that we are logging incorrectly, please see the test Ron Whitsel and I did in OSTicket #803567.
Attached Files:
Notes
(0008996)
WA9PIE   
2019-10-23 21:38   
I pulled this over from the backlog. This is the issue that customers are complaining about.
(0009079)
g3ucq   
2019-10-29 09:04   
I can confirm this issue.
(0009080)
g3ucq   
2019-10-29 09:25   
With an FT4 QSO forwarded from WSJT-X as MFSK, a LOTW download does not match
(0009092)
K7ZCZ   
2019-10-29 16:45   
Here, it seems like the term "QSO Forwarding" is being used to describe the Logbook listening for QSOs broadcast by other software. I'd call this "QSO Listening". These actions are from the point of view of the Logbook. If the Logbook is forwarding, it's sending to other apps. If the Logbook is listening, it's listing from other apps.

With that in hand, it seems like the report involves the QSO Listener being sent, from WSJT-X, an ADIF record that contains a submode and a mode. Because we don't support SubMode, we just ignore the SubMode value. For FT4 QSOs, ignoring the SubMode value isn't desirable because we'll record "MFSK" as the mode. The complaint is that, instead, we really want to record a mode of "FT4" so that such records can participate in workarounds elsewhere in the product.

Further, it seems like we're saying that JTAlert sends a QSO to the Logbook QSO Listener that has a value of "FT4" for the Mode field and no value for the SubMode field. Sounds like we're fine with that behaviour and no fix is necessary.

With the above interpretations, then, my understanding is that we want to augment the QSO Listener in the Logbook so that when records are received with a value of "MFSK" in the Mode field, and a value of "FT4" in the SubMode field, they're mapped to a record with no SubMode value and a Mode value of "FT4".

Is this correct?

Pursuing this fix isn't difficult to implement. But this path would have us making records in customer databases that aren't exactly much better than they are today because they don't map to the reality we want to model in the scope of the database. We lose fidelity. There are about 100 submodes in the ADIF spec, and this approach addresses only one. Ignoring all others, like USB and LSB being SubModes of SSB.

The product only unmaps Mode/SubMode when trying to match LotW records and not when dealing with any other QSL service. And not when exporting or importing from any other data srouce or file type. And not when restoring or writing our own backup for our own product. Or in any other circumstances.

Is this pollution of customer data and asymmetric mapping acceptable? I would assume not, since it probably makes future fixes precarious. At the very least, we should investigate symmetrical mappings for other services and reason out what our path might be when updating the product to address SubMode fully.

When we do accept such a record from QSO Listening and add it to the Logbook, we're obliged to forward it in the QSO forwarding feature for other listening applications. If the described mapping is implemented, should that forwarded record contain a value of "FT4" for the Mode field and no value for SubMode; or should it have the Mode value of "MFSK" and the SubMode value of "FT4", as originally received?
(0009093)
WA9PIE   
2019-10-29 16:49   
As I understand it, I believe that is correct.

This is a reasonable work-around until we can support submodes.
(0009095)
g3ucq   
2019-10-29 17:03   
Today I made some FT4 qsos.
Having been forwarded from WSJT-X the qsos appeared as MFSK in the Logbook.
I uploaded them to LOTW.
The LOTW download showed the Mode as DATA and there were no matches to my FT4/MFSK qsos.
I changed the Mode in the Logbook from MFSK to FT4 and then the LOTW download reported matches.
After the download, the FT4 qsos did not have "Verified (match)" against them. I had to do that manually.
Is that acceptable?
(0009096)
K7ZCZ   
2019-10-29 17:42   
This shelf set contains what should be a fix, given the description above.
https://hrdsoftware.visualstudio.com/HRD/_versionControl/shelveset?ss=workaround%20in%20UDP%20Listener%20for%20FT4%20mode%3Bmikeblas%40msn.com

I have strong reservations about this approach so I won't be checking it in. Any of the other developers can review the code and, if they'd like, check add it to the product.
(0009097)
WA9PIE   
2019-10-29 18:32   
Given your reservations, do you have a better idea?
(0009098)
PD9FER   
2019-10-30 03:00   
Mike B, you are correct.
Same way as I had in mind.
(0009131)
KB3NPH   
2019-11-04 11:17   
I got off the phone with Ron Whitsel this morning and here is exactly what needs to be done with this FT4 issue.

The biggest problem is with the ADIF that comes in via QSO Forwarding directly from WSJT-X. I'll get to that in shortly.

The major thing is we MUST have the mode shown in our Logbook as "FT4", and not MFSK, Not DATA nothing but FT4 should show as the mode in our logbook and it should be uploaded as FT4 to LoTW, not MFSK, not DATA but FT4.

Here is the first hurtle we need to jump over, go through or around. Customers who are using JTAlert have two options available for logging FT4 contacts which are used in the ADIF that's sent from JTAlert to the HRD Logbook. The FIRST and CORRECT way is to set the JTAlert so that it creates an ADIF with the "Mode = FT4". There is NO sub mode, no MFSK no nothing, just a simple Mode = FT4 and FT4 is what shows up as the mode in the HRD Logbook. First and foremost, in the Modes table in the HRD Logbook, we MUST have it set to "Mode = FT4" and "ADIF = FT4". This should be the default in the modes table in HRD Logbook.

Now for the actual logging of the contact. This is where we MUST communicate with our customers who are using JTAlert that JTAlert has TWO ways of logging the FT4 contacts that are used when creating the ADIF that is transferred to the HRD Logbook. There is a setting in the JTAlert software where you can configure it so that the MODE = FT4. There is NO sub mode mentioned and no submode in the ADIF that is transferred from JTAlert to the HRD Logbook. When it's written to the HRD Logbook it shows the mode as FT4 in our logbook database. We need to STRESS to our customers who are using JTAlert that THIS is the proper setting to select.

The other option in JTAlert creates an ADIF that logs the Mode = MFSK and a Submode = FT4. This is the option we want OUR customers to ignore and not use when using JTAlert to log between WSJT-X and the HRD Logbook. We really need to thank Laurie for providing the JTAlert users with this option so that JTAlert will be compatible with OUR logbook and also with those who are fully ADIF3 complient and support the logging of sub modes.

Now that we have FT4 being logged as the mode in the HRD logbook from JTAlert, we need to look at the ADIF being sent to the HRD Logbook by WSJT-X for the users who select to use our QSO Forwarding instead of JTAlert to log the contacts to the HRD Logbook.

When we work a contact in WSJT-X and receive the popup that sends the record to the HRD Logbook, the mode in the popup says "FT4". When the ADIF is sent from WSJT-X to the HRD Logbook, it has the "Mode = MFSK" and "Submode = FT4". Here's what we have to do in this case. When our clients are using the QSO Forwarding, we need to intercept this ADIF and have our code change the "Mode = MFSK" to "Mode = FT4, and then log it to the HRD Logbook with the Mode FT4 in the Logbook record.

Now, if we can get the loging from JTAlert and the logging via QSO Forwarding direct from WSJT-X to BOTH create a record in the HRD Logbook with the "Mode: FT4".... we have half the battle won.

The NEXT battle comes when we uplaod these FT4 contacts to LoTW. They should be uploaded to LoTW so that when they land on the LoTW website, the Mode is FT4, which will happen if the mode is FT4 in all of these HRD Logbook records. This is the way it SHOULD be.

The next part of this battle is when we download from LoTW and get the FT4 contacts downloaded from LoTW to MATCH the FT4 contacts in the HRD Logbook. If we REVERT back to the code that was in Beta Build 227 than handled the downloads from LoTW, the FT4 contacts in the ADIF downloaded from LoTW DID MATCH the FT4 contacts in the HRD Logbook. This was proven by a test Ron and I did and reported it earlier in this bug ticket.

If we can somehow do EXACTLY as I have written this note, we will have this FT4 issue resolved to the point where we can release 6.7 and this should satisfy our customers that this has been resolved.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3599 [2 - Next Dev List (Holding Area)] Bug minor always 2019-11-20 07:45 2019-11-20 07:45
Reporter: g3ucq Platform: PC  
Assigned To: OS: Windows  
Priority: normal OS Version: 10 64 bit Home  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Call lookup
Testing: Not Started
Summary: Issues with the Lat/Lon links in the Lookup Pane
Description: The Lat/Lon displayed in the Licensee panel in the Lookup pane does not open Google Earth as expected.
The Lat/Lon displayed in the Country panel does open Google Earth.
Tags:
Steps To Reproduce: Open the Logbook and then the Lookup Pane.
With the Logbook and Lookup pane open -
Click on a Cluster spot or enter a call sign into the Callsign box.
The panels will be populated.
Mouse over the Lat/Lon link in the Licensee panel which will show "the station's latitude and longitude, click to open with Google Earth"
Clicking on the link has no effect.
Now click on the Lat/Lon in the Country Panel.
Nothing happens but you may get a request to choose an app for this action.
In that case, if you have Google Earth installed, browse to its .exe file and select it.
Now clicking on that link will open Google Earth and place a marker in the middle of the Country.
It does not put the marker on the Lat/lon coordinates.
Additional Information:
System Description
Attached Files: Lookup.JPG (24,574 bytes) 2019-11-20 07:45
https://development.hamradiodeluxe.com/file_download.php?file_id=858&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3403 [1 - Backlog] Bug minor always 2019-07-26 09:12 2019-11-19 16:25
Reporter: PD9FER Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: ALE Window
Testing: Not Started
Summary: Logbook.. adding a QSO Start and End times are the same
Description: The Logbook shows the Date, (F2) Start and (F3) all greyed out.
When i log a contact it always puts in the end time the same as the start time and I cannot change it to a Start Time and and end Time which are up to date. The Start time is set to Current Time and the end Time is set to Current time also - this would normally produce a different Start and end Time but it currently will only log them as Identical times (always the Start and end time are the same)
Tags:
Steps To Reproduce: Open Logbook
Configure the Layout to display Time On and Time OFF

Open ALE
Select Options > Date/Times > Start and set it for Current Time
Repeat for End

Enter a call and do the lookup
Wait a few minutes
Add the QSO

Now in Logbook you will see the Start and End times are the same.
There should be a difference
Additional Information: Ticket #175406
Attached Files:
Notes
(0009039)
k2ie   
2019-10-28 14:03   
I think that this may be the same issue that I raised in the following thread: https://forums.hamradiodeluxe.com/node/51150
(0009060)
g3ucq   
2019-10-29 05:03   
I confirm this issue.
(0009401)
k2ie   
2019-11-19 11:14   
Interestingly, DM780 still follows the former, desirable behavoir. I tested today while going through 6.7.0.250. Entering a new callsign and then hitting tab sets the start time to the time that that tab was hit.
(0009402)
g3ucq   
2019-11-19 14:01   
If the Start and End times are both set to the Current Time then surely they will be the same when the QSO is logged.?
I use Start Time "Set by the User" and End Time "Current Time".
(0009403)
k2ie   
2019-11-19 16:25   
I also use Start Time "Set by the User" and End Time "Current Time".


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3125 [1 - Backlog] Bug minor always 2019-01-27 15:24 2019-11-19 06:33
Reporter: WA9PIE Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Data
Testing: Not Started
Summary: QSOs with stations that aren't in a valid DXCC country show up in the awards totals for a country and should not
Description: QSOs with stations with a /MM suffix are maritime mobile stations and they should not count towards a country.

Over the years, there have been many reports of this. This is the latest report:

https://support.hamradiodeluxe.com/scp/tickets.php?id=26378

For example, if a QSO is with a station with a callsign of FT5WQ/MM was operating from a boat and outside the boundaries of a country. This QSO should not count for any DXCC country. Per the ADIF standards, it should count for "None" with a DXCC numeric value of 0 (zero).

http://www.adif.org/309/ADIF_309.htm#DXCC_Entity_Code_Enumeration

We need to add the DXCC Country of "None" and assign it DXCC=0.

Besides /MM, there may be other suffixes that should map to "None".

This should be factored into updates to callsign lookup and needs to apply to the DX cluster pane.

(On a related note - DX clusters use a suffix of /QQ to designate it as a "Pirate" station. This should also go into the "none" bucket.)
Tags:
Steps To Reproduce: Open Logbook
Login to a DX cluster (like WA9PIE-2)
Dropdown "Show" to "Console"
Send the following command to the cluster from the command field in the upper left: "sh/dx RA0LQ/MM" without the quotes and hit "Enter"
You'll see that the cluster shows these incorrectly as "Asiatic Russia (UA9)"
Right-click the spot and select "New ALE Window" to the log. It incorrectly shows up as "Asiatic Russia (UA9)"
In both cases, it should say, "None".
Additional Information: There's some work we need to do here with the Country List to accommodate this for logging and import/export.

I can add the country ("None") into the Country List and try to identify the adverse impacts of doing so. Then we can fix them.
Attached Files: MaritimeMobile.PNG (50,807 bytes) 2019-01-27 15:28
https://development.hamradiodeluxe.com/file_download.php?file_id=659&type=bug
MaritimeMobileALE.PNG (79,458 bytes) 2019-01-27 15:29
https://development.hamradiodeluxe.com/file_download.php?file_id=660&type=bug
Notes
(0007088)
WA9PIE   
2019-01-27 15:28   
Additional images
(0007090)
WA9PIE   
2019-01-27 15:29   
Another


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3597 [2 - Next Dev List (Holding Area)] Bug major have not tried 2019-11-19 04:17 2019-11-19 04:17
Reporter: g3ucq Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: ALE Window
Testing: Not Started
Summary: Testing the various issues with the Logbook Lookup caused a minidump to be created
Description: With Rig Control and the Logbook open I as testing the various Lookup issues.
After about 45 minutes the Lookups started to slow and not all data was populated.
I closed the Logbook which created the attached minidump file.
Tags:
Steps To Reproduce: Difficult to reproduce the steps as I was making virtually random Key presses but mainly using the Tab key.
Additional Information:
Attached Files: HRDLogbook_20191119_101043.mdmp (852,269 bytes) 2019-11-19 04:17
https://development.hamradiodeluxe.com/file_download.php?file_id=857&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3593 [1 - Backlog] Bug major always 2019-11-17 20:35 2019-11-18 11:02
Reporter: vk2byi Platform: Windows 10  
Assigned To: OS: Windows 10 Pro  
Priority: normal OS Version: 1903  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Import Export
Testing: Not Started
Summary: QRZ.com Upload Fails with Date Range Error
Description: All attempts to upload QSOs to QRZ.com result in an ‘add_qso: outside date range’ internal error when using either v6.7.0.244 or v6.7.0.245 beta.

After reverting to v6.6.0.237, all attempts at QRZ.com uploads work as expected.

I verified that my start and end QSO dates in my logbook properties in QRZ.com are current and valid (1978-11-27 through 2020-12-31).

It may be relevant that I am located in Australia and do not use US date format at the OS level. Instead, I use ISO date format (yyyy-mm-dd).
Tags:
Steps To Reproduce:     1. Install either v6.7.0.244 or v6.7.0.245 beta;
    2. Select a QSO in HRD Logbook and upload it to QRZ.com;
    3. It doesn't matter if a new contact, or an existing contact already in QRZ.com is selected for upload, all attempts fail with an ‘add_qso: outside date range’ internal error.
Additional Information: I have reproduced this in both my normal and testing (VM) environments.

After reverting to v6.6.237, uploading a new contact works, and uploading an existing contact results in a duplicate contact error as expected.
Attached Files: QRZ Upload.jpg (114,048 bytes) 2019-11-17 20:35
https://development.hamradiodeluxe.com/file_download.php?file_id=853&type=bug
QRZ Logbook Properties.jpg (101,832 bytes) 2019-11-17 20:35
https://development.hamradiodeluxe.com/file_download.php?file_id=854&type=bug
Notes
(0009352)
vk2byi   
2019-11-18 04:45   
I spent time making sure I wasn't creating a duplicate before I created this ticket and didn't find 0003565. But that was because I had a filter set with Hide Status set to Closed (and above), hence hiding it from me.

I see that 0003565 was closed with the issue being fixed in 6.7.0.247. I thought we were testing 6.7.0.245, and so I went looking for 6.7.0.247 only to find 6.7.0.249 is now available for test I presume. Maybe 0003565 (or 0003593) should remain open until beta testing off 6.7.0.249 is done. Just my 2c worth.

I will download 6.7.0.249 now and test.
(0009371)
w4elp   
2019-11-18 11:02   
6.7.0.249: Confirm QRZ.com Log upload working.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3595 [1 - Backlog] Bug major have not tried 2019-11-18 06:41 2019-11-18 06:41
Reporter: KB3NPH Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Functional
Testing: Not Started
Summary: IC-7800 Power ON feature from HRD not working
Description: The IC-7800 supports the software turning the radio on and off. With the recent releases of HRD, the software will turn the radio off when shutting down Rig Control, but when restarting HRD it will not turn the radio back on.

HRD shuts the rig off leaving stand by power verified by the pulsing led above the power switch but when starting HRD it doesn't turn the radio back on.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3592 [1 - Backlog] Enhancement minor always 2019-11-17 03:26 2019-11-17 03:26
Reporter: PD9FER Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Panadapter
Testing: Not Started
Summary: Missing Documentation for the PanAdapter
Description: Getting multiple customer request on some documentation for the Panadapter.
This must consist in 4 parts.
A: Radio type and connection requirements.
B: How to start the Panadapter
C: Configuration, settings and how to operate Panadapter
D: Troubleshooting.

Tags:
Steps To Reproduce: N/A
Additional Information: Ticket #568110
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2801 [3 - Current Dev List] Enhancement minor always 2018-07-04 17:16 2019-11-15 08:46
Reporter: K7ZCZ Platform: Intel i7-5960X  
Assigned To: K7ZCZ OS: Windows 10 Professional x64  
Priority: normal OS Version: 16299  
Status: assigned Product Version: 6.4.0.846  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: ALE Window
Testing: Not Started
Summary: Logbook: ALE "worked" indicators don't appear predictably
Description: The "W" worked indicators on the Logbook ALE/ELE window are not made visible in a sensible manner. Maybe some design work is needed here, or perhaps we want to make them completely invisible (always) until their meaning and use can be sorted out.
Tags:
Steps To Reproduce: The "W" worked indicators on the Logbook ALE/ELE window are not made visible in a sensible manner. Maybe some design work is needed here, or perhaps we want to make them completely invisible (always) until their meaning and use can be sorted out.

1) Fire up the logbook
2) No particular database is required, but one must be opened
3) Press the (+) Add button in the toolbar to open an ALE window
4) Note that "Call", "Locator", and "Country" have "Worked" controls next to them; a white "W" on a bronze background.

BUG#1) There's a "W" button loating in space near the LoTW field, but the LotW field isn't there. What I see is in the FloatingWBug image, attached. Seems like, if the LoTW field is gone, its matching Worked indicator s hould be invisible, too. Does it make sense to show the LoTW worked indicator when we dont' know which LoTW setting applies?

6) Use any command in the "Show:Fields" menu to make a field disappear or reappear.

BUG#2) The field you've edited appears or disappears correctly, but all the "W" buttons have disappeared. What I see is in the GoneWBug image.

BUG#3) At this point, I don't think there's aw ay to get the "W" buttons to reappear without closing and re-opening the ALE.

7) Close the ALE
8) Double-click an existing logbook entry to open the ELE.

BUG#4) There are no "W" buttons. Why not? No way to make them appear.
Additional Information:
System Description
Attached Files: FloatingWBug.png (38,445 bytes) 2018-07-04 17:16
https://development.hamradiodeluxe.com/file_download.php?file_id=465&type=bug
GoneWBug.png (39,854 bytes) 2018-07-04 17:16
https://development.hamradiodeluxe.com/file_download.php?file_id=466&type=bug
Notes
(0005610)
WA9PIE   
2018-07-05 10:39   
(Last edited: 2018-07-05 10:40)
Rather than fix the "W"... I'd rather see us use the same WSI convention and put the X, check, or yield there.

Also need to use the same logic for WSI in DM-780.

(0005617)
K7ZCZ   
2018-07-06 14:12   
Is documentation available that describes the behaviour you'd like implemented?
(0005831)
WA9PIE   
2018-07-26 00:22   
The most concise documentation about how WSI is intended to work is found here:

https://wiki.hamradiodeluxe.com/index.php?title=Logbook#WSI

This same method (or "function") should be used within the ALE (as described here) and also in DM-780's ALE and/or waterfall.

That said... if the ALE is blank, there should be no WSIs there.

Happy to answer any additional questions.
(0005874)
K7ZCZ   
2018-07-28 13:47   
The linked documentation has its own issues; see 2680.

I guess you're saying that the WSI indicator in the ALE that's next to the "Call" entry field should work like the WSI indicator in the "C" column of the DX Cluster. I'm not sure that gives me everything I need, though; the lookups are based on the call, band, and country (and anyhting else?) not just the call. Isn't that correct?

There is a WSI indicator in the ALE near the IOTA fields. I don't see a match for it in the WSI documentation you've linked. How is it meant to work?
(0006548)
WA9PIE   
2018-12-08 10:14   
No. The "C" column in the DX Cluster stands for "Country" (rather than call).

I'm going to see if I can gather an image to describe how this should work.
(0007963)
K7ZCZ   
2019-05-30 16:53   
Switched to "enhnacement" per the team call on 2019-05-30
(0008102)
WA9PIE   
2019-06-16 17:11   
If we're going to do anything with this at all, these WSIs need to be changed so they follow the convention used in the DX cluster (and referenced here: https://wiki.hamradiodeluxe.com/index.php?title=Logbook#WSI). [Green check-mark, yellow yield sign, red X = confirmed, worked, and not worked respectively]
(0009330)
PD9FER   
2019-11-15 08:46   
comment from Ronald:

Actually the more I think about it these indicators are kind of redundant. Obviously if you have worked the station before you have also worked the grid, country and Iota. Maybe just the station symbol is all that is necessary. Maybe they should all be removed.

The idea of using the actual "WSI" symbols instead seems like a good idea but is it useful? Also not everybody is running a super computer and as things are added the timely nature of the ALE window to populate quickly may be lost.
Other station are always amazed at how fast I come up with their first name and previous contacts at the start of a QSO. Often they ask what logging software I am using.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3573 [1 - Backlog] Bug major unable to reproduce 2019-11-11 02:37 2019-11-15 08:03
Reporter: PD9FER Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Rig Control
Testing: Not Started
Summary: IC-7100 filter switch is switching Mode instead of Filter
Description: Filter selection not working correctly. When I click on any Filter link, it changes my mode to CW and to USB, it no longer changes the Filter to 1/2/3. Previous version (Ham Radio Deluxe v6.6.0.237) worked fine.
Tags: IC-7100, IC-7200, ICOM
Steps To Reproduce: In Rig Control click the filter selection.
 notice it switching mode and not the selected filter.
Additional Information: Ticket #956341
Attached Files:
Notes
(0009328)
PD9FER   
2019-11-15 07:27   
Also now reported for the IC-7200
Ticket #72509

Looks There is an issue on the CI-V table for Icom
(0009329)
PD9FER   
2019-11-15 08:03   
Confirming this with other Icom radios also


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3572 [1 - Backlog] Bug major unable to reproduce 2019-11-11 01:33 2019-11-15 07:56
Reporter: PD9FER Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Rig Control
Testing: Not Started
Summary: IC-7851 filter switch is switching Mode instead of Filter
Description: FILTER switching as instead of switching the designated filter from fl1 - fl2 - fl3 to a certain bandwidth filter like 1.8Khx - 2.4Khz - 3.0 Khz it will switch MODE.(AM/USB/…)
Tags: IC-7851, ICOM
Steps To Reproduce: In Rig Control click the filter selection.
notice it switching mode and not the selected filter.
Additional Information: Ticket #129819
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3586 [1 - Backlog] Maintenance minor random 2019-11-14 02:59 2019-11-15 04:08
Reporter: PD9FER Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Panadapter
Testing: Not Started
Summary: PanAdapter has no smooth display
Description: From customer using IC-7300:
When I open the new panadapter display the window displays very slowly. The display starts and stops, and sometimes is overlaid with a white rectangle. If I attempt to change any settings there is a long delay and after I make a change some of the setting changes back by themselves. The USB port on my radio is set to 115,200 baud
Tags: IC-7300, ICOM
Steps To Reproduce: Use the recommended settings for using the Panadapter.
Additional Information: Ticket #524587
Included some diagnostic data
Attached Files: DxDiag.txt (142,286 bytes) 2019-11-14 02:59
https://development.hamradiodeluxe.com/file_download.php?file_id=845&type=bug
Notes
(0009325)
PD9FER   
2019-11-15 04:08   
I placed a Video (panadapter.mp4) in the related Mantis folder on Google Drive\Dumps


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3583 [3 - Current Dev List] Maintenance minor always 2019-11-13 02:32 2019-11-14 20:21
Reporter: PD9FER Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: confirmed Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: ALE Window
Testing: Not Started
Summary: (W)orked indicators are gone
Description: As discussed in the meetings earlier (I can't find the Mantis# for it), the W icon has gone for Callsign, IOTA, Country and Locator
Tags:
Steps To Reproduce: Open ALE
Lookup an call in a Country, IOTA or Locator you worked before
(See screenshot)
Additional Information: Ticket #643901
Attached Files: Capture.JPG (32,843 bytes) 2019-11-13 02:32
https://development.hamradiodeluxe.com/file_download.php?file_id=841&type=bug
wkrd.JPG (118,118 bytes) 2019-11-13 07:24
https://development.hamradiodeluxe.com/file_download.php?file_id=844&type=bug
Notes
(0009320)
K7ZCZ   
2019-11-14 18:31   
In the team call on 2019-08-29, it was agreed that these indicators would be removed until a good design could be put together for how they'd work.
(0009321)
WA9PIE   
2019-11-14 20:09   
I think that when we've recorded a customer's "bug report" that we should refrain from moving it to "Resovled" and "Won't fix"... when it's a case where we're saying that we do intend to address this when a "good design can be put together for how this will work."

To that end... I've reopened it, marked it confirmed, and assigned it to me we come up with this good design.
(0009322)
K7ZCZ   
2019-11-14 20:21   
I resolved this won't fix because the team had deliberately decided to remove the feature from the product, per the related issues.

If the team has deliberately decided to reverse that decision and undo the work done to carry it out, then it should do so with clarity and clear intention.

At best, this issue is a duplicate and should remain resolved since you document your intention to come up with a design in 2801.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3589 [1 - Backlog] Bug major always 2019-11-14 11:55 2019-11-14 11:55
Reporter: KB3NPH Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Functional
Testing: Not Started
Summary: Icom IC-9700 Panadapter won't connect and issues with 2m buttons on GUI.
Description: Ticket #912614 - Customer has an IC-9700 and is running a 6.7.0.245 BETA build and the Panadapter will NOT connect to the radio. Customer tried both versions of firmware available. He down graded the firmware from 1.20 to 1.13 just to see if the firmware made a difference.

The radio was configured with CI-V USB Port (Default: Link to [REMOTE])" Set this option to "UNLINKED and CI-V USB Baud Rate (Default: Auto) Set this option to 115200. If there were any other menu settings in the radio that needed to be configured we were not aware of them and only configured what seemed logical from working with the IC-7300. If there were any other configuration settings developers should have provided us with some documentation on the settings.

When selecting the "Panadapter (Main) from the Tools menu the display shows up completely blank as in the image attached.

Customer also reports and I witnessed erratic button functions when selecting different 2m buttons on the GUI. Frequencies would "flicker" in and out of the display and at times were not stable.

Customer has other software, icom RS-BA1 ver 2, SATPC32 and the RT Systems programmer, all connect up just fine and operate the radio just fine.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: 9700 Panadapter bug display.png (58,171 bytes) 2019-11-14 11:55
https://development.hamradiodeluxe.com/file_download.php?file_id=850&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3585 [1 - Backlog] Bug minor unable to reproduce 2019-11-13 14:37 2019-11-13 14:37
Reporter: KC7FPF Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: (select)
Sub-Module: (select)
Testing: Not Started
Summary: Selected font size does not stay set in label printing
Description:  set it for 9 and want to leave it at 9 but if I try to print again, the software has reverted back to AUTO and I reset it to 9 and adjust it but when I adjust again I must change the font size back to 9 from AUTO... it will not remember what I had set it to

Please see ticket 951386
Tags:
Steps To Reproduce:
Additional Information: I have attempted to recreate the issue. However it does go back to auto. But why would you want to change the size of the font if you want to allow all the contact information to fit on the label.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3581 [1 - Backlog] Enhancement minor unable to reproduce 2019-11-12 14:20 2019-11-12 14:20
Reporter: KC7FPF Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: General
Testing: Not Started
Summary: TS590S NB
Description: The Kenwood TS590S, with firmware version 2.04, the operator has the ability to select receiver NB1 or NB2 individually, or to use NB1/NB2 concurrently by pressing and holding the front panel NB button down for 1 second.

In HRD Rig Control, version 6.7.0.244, there appears only the option to select either NB1, or NB2, but not both together. Selecting NB1/NB2 concurrent operation by pressing and holding the transceiver front panel NB button results in correct radio operation (i.e. NB12 is displayed), however then in HRD Rig Control display, both NB1 and NB2 soft buttons are dimmed out.

Tags:
Steps To Reproduce: As a test I've attempted the long-click of NB1 or NB2 buttons on the software screen to no avail. Workaround is to just use the button on the front panel of the radio.
Additional Information: Please refer to OS ticket 474112
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3528 [1 - Backlog] Bug tweak always 2019-10-30 14:04 2019-11-12 11:48
Reporter: n4fn Platform:  
Assigned To: DOUG OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Label
Testing: Not Started
Summary: Label Date protocol not followed
Description: Another label issue....the date in my pc and in my log is: 30-Oct-19 I prefer this since it is the international standard of Day-Month- Year.
The fixed format in the label is correct as dd-MMM-yy, Hover the label program ignores the format and shows for example 30-10-19 when it should follow and show OCT (MMM) rather than 10 The format is correct in Windows and my PC
 
Tags:
Steps To Reproduce: Verified with several labels
Additional Information:
Attached Files: Capture.PNG (12,371 bytes) 2019-10-30 14:04
https://development.hamradiodeluxe.com/file_download.php?file_id=801&type=bug
74181958_1379610042215755_7471386264713822208_o.jpg (61,774 bytes) 2019-11-10 04:34
https://development.hamradiodeluxe.com/file_download.php?file_id=830&type=bug
Notes
(0009223)
PD9FER   
2019-11-10 04:34   
Prefer to get lost of the (dd-MMM-yy) to save space.
Suggest to notate the date as like "10 Nov 2019"

Got some relevant info attached.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3580 [1 - Backlog] Bug major always 2019-11-12 11:44 2019-11-12 11:44
Reporter: g3ucq Platform: PC  
Assigned To: OS: Windows  
Priority: normal OS Version: 10 64 bit Home  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Call lookup
Testing: Not Started
Summary: The Lookup Pane not always reporting a country
Description: With the Lookup pane open, some countries are not being populated when a station is operating from another country
Tags:
Steps To Reproduce: With the Logbook open, open the Lookup pane.
Add a call sign e.g. WA9PIE. The Country is correctly shown as the United States.
Now change to VK/WA9PIE and the Country is blank.
Now change to DL/WA9PIE and the Country is shown as Rep. of Germany.
Now change to G/WA9PIE and no Country is shown.
Some Country prefixes work, some do not.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3579 [1 - Backlog] Bug major have not tried 2019-11-12 10:29 2019-11-12 10:34
Reporter: KB3NPH Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Satellite Tracking
Sub-Module: Radio Support
Testing: Not Started
Summary: Old issue with the IC-9100 and Satellite Tracking
Description:  Ticket #346602 - There is an issue with the IC-9100 when used for Satellite Tracking. I have contacted and talked to Rick and Greg from Icom and apparently this is a known issue where when operating over Satellite Repeaters, normally VFO A is configured for TX and VFO-B is configured for RX. With the 9100, the only split that is available is to use VFO-A for RX and VFO-A sub for TX.

Several years ago we had a technician who worked part time for HRD who was avid with Satellite Tracking. He used an IC-9100. HRD could not, at that time work with the 9100, so this tech and RR got together and wrote up a kludge so that the 9100 could be used for Sat. Tracking. All I do know is that at that time, they had the 9100 working in some way for Sat. Tracking. I don't know if they found a way to make our software use VFO-A for RX and VFO-A Sub for TX or whether they were doing what most radios doe where VFR-A is RX and VFO-B is TX when put into split operation.

We need to get this figured out and get the 9100 working with our software for Satellite tracking. I have also been informed that the same problem will rear it's ugly head if someone tries to use the 9700, however, when I spoke with the two different support techs at Icom, they tell me the problem with the 9100 for satellite work has been resolved in the 9700, therefore there shouldn't be a problem with the 9700.

Hopefully this can be resolved soon.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0009289)
PD9FER   
2019-11-12 10:34   
That Tech was me..
And no, it never worked as should
would love to see a fix for this


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3578 [1 - Backlog] Enhancement minor always 2019-11-12 10:26 2019-11-12 10:26
Reporter: PD9FER Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: DM780
Sub-Module: Winkeyer
Testing: Not Started
Summary: Winkeyer in microHAM MKIII poor connection
Description: During investigative work with Jozef @ Microham as to why I was having issues connecting to winkeyer Jozef discovered the following issues,
Now Winkey:

Winkey support is much harder problem because is not properly implemented in HRD.
WK chip is configurable external CW keyer, its behaviour is set by special commands. Some of these commands defines pinout of chip, some sets parameters. Parameters which could have influence to WK chip operation are filtered in Router (replaced by correct one) to match electrical implementation of the chip in MKIII, and settings on Winkey tab in the Router.

To communicate with WK chip, host (HRD) has to issue specific commands in specific sequence. First command which has to be issued is opening host mode, command 00 02. Here are instruction for use 00 02 command by K1EL WK chip author from WK manual:

 "Upon power-up, the host interface is closed. To enable host mode, the PC host must issue the Admin:open command. Upon open, WK3 will respond by sending the revision code back to the host. The host must wait for this return code before any other commands or data can be sent to WK3. Upon open, WK1 mode is set."


Only after WK chip sends response, host can issue any other command, for example 15 what is status request.

To close communication with chip (should be used right before host (HRD) exits) should be used command 00 03. Again, command description from WK manual:

 "Use this command to turn off the host interface. WK3 will return to standby mode after this command is issued and standby settings will be restored."

Hope up to now it is clear.

Problem is that HRD issues this startup sequence:

1359344328: Port opened
1359344843: H-TX: 13 [Null Command]
1359344843: H-TX: 13 [Null Command]
1359344843: H-TX: 13 [Null Command]
1359344843: H-TX: 13 [Null Command]
1359345359: H-TX: 00(--) 02(00 02) 15 00(--) 03(--) [Admin: HostOpen] [Request WinKey Status] [Admin: HostClose (discarded)]

string of 13 (null commands) are fine here, they are recommended by K1EL. But than there is 00 02 15 00 03 string of data sent at once. What means 00 02 to open host interface, than without waiting for response is immediately issued command 15 (status request) and at the same time 00 03 what is closing host mode. Using such command sequence is nonsense and won't work with any WK chip other than implemented in MKII/MKIII, because 00 03 command is discarded by the Router. In addition, sending open host (00 02) and poll for status (15) at once without prior waiting for response may lockup chip (requiring power off/on MKIII to reset WK chip) and it is just coincidence when it starts to operate.

HRD guys must fix their WK support, I believe Steve, K1EL will be glad to help them.
My recommendation to you is to not use WK facility in HRD, rather other method of CW keying until issue is resolved. If you still want to use it, cycle power of MKIII after any unsuccessful attempt to connect to WK, because chip can be locked by wrong initialization sequence.

Hope it make this issue more understandable.

73 Jozef OM7ZZ

 Kind regards

Frank G3YQA
Tags:
Steps To Reproduce: N/A
Additional Information: Ticket# 868015
Attached Files: wk4.txt (6,216 bytes) 2019-11-12 10:26
https://development.hamradiodeluxe.com/file_download.php?file_id=839&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3577 [1 - Backlog] Enhancement minor always 2019-11-12 10:23 2019-11-12 10:23
Reporter: PD9FER Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: TS-990 commands not correct
Description: During an investigation with Jozef @ Microham on why the Microham Microkeyer 3 would not initiate correctly in HRD the following cat command issues were observed:
Neither log shows anything harmful, but there are a lot of HRD commands which are not issued correctly or are not implemented in the TS-990S, to which radio responds with ?; response. These commands waste bandwidth but don't cause any lock up. Looks like driver is just copy/paste from some single receiver Kenwood radio.

Below you can find cut from log you've sent, problem is everywhere where is shown (Syntax error (or busy) comment. I'm attaching command reference manual of TS-990S for your review.

Improperly implemented commands are:

AP0; (wrong command syntax)
SA; (invalid command, doesn't exist)
BC; (wrong command syntax)
FS; (wrong command syntax)
NB; (invalid command, doesn't exist)
TO; (wrong command syntax)
CA; (wrong command syntax)
SC; (invalid command, doesn't exist)
RA; (wrong command syntax)

1359566750: H1-TX: (0) PA1;
1359566765: A-RX: (1) PA11;
1359566781: H1-TX: (0) AP0;
1359566781: A-RX: (1) ?; (Syntax error (or busy))
1359566796: H1-TX: (1) XT;
1359566812: H1-RX: (1) XT0;
1359566812: H1-TX: (1) AM;
1359566828: H1-RX: (1) AM0;
1359566828: H1-TX: (1) SA;
1359566828: H1-RX: (1) ?; (Syntax error (or busy))
1359566828: H1-TX: (1) BC;
1359566843: H1-RX: (1) ?; (Syntax error (or busy))
1359566843: H1-TX: (1) BC;
1359566843: H1-RX: (1) ?; (Syntax error (or busy))
1359566843: H1-TX: (1) BC;
1359566859: H1-RX: (1) ?; (Syntax error (or busy))
1359566859: H1-TX: (1) TS;
1359566875: H1-RX: (1) TS0;
1359566875: H1-TX: (1) FS;
1359566875: H1-RX: (1) ?; (Syntax error (or busy))
1359566875: H1-TX: (1) NB;
1359566875: H1-RX: (1) ?; (Syntax error (or busy))
1359566875: H1-TX: (1) MF;
1359566890: H1-RX: (1) MF0;
1359566890: H1-TX: (1) TO;
1359566906: H1-RX: (1) ?; (Syntax error (or busy))
1359566921: H1-TX: (1) VX;
1359566921: H1-RX: (1) VX0;
1359566921: H1-TX: (1) CA;
1359566937: H1-RX: (1) ?; (Syntax error (or busy))
1359566937: H1-TX: (1) PR0;
1359566953: H1-RX: (1) PR00;
1359566968: H1-TX: (1) BY;
1359566984: H1-RX: (1) BY10;
1359566984: H1-TX: (1) BY;
1359567000: H1-RX: (1) BY10;
1359567000: H1-TX: (1) MF;
1359567015: H1-RX: (1) MF0;
1359567015: H1-TX: (1) SC;
1359567031: H1-RX: (1) ?; (Syntax error (or busy))
1359567031: H1-TX: (1) RA;
1359567046: H1-RX: (1) ?; (Syntax error (or busy))
1359567046: H1-TX: (1) SA;
1359567046: H1-RX: (1) ?; (Syntax error (or busy))
1359567062: H1-TX: (1) SA;
1359567062: H1-RX: (1) ?; (Syntax error (or busy))
1359567062: H1-TX: (1) CA;
1359567078: H1-RX: (1) ?; (Syntax error (or busy))
1359567078: H1-TX: (1) RA;
1359567078: H1-RX: (1) ?; (Syntax error (or busy))
1359567078: H1-TX: (1) FT;
1359567093: H1-RX: (1) FT0;
1359567093: H1-TX: (1) FT;
1359567109: H1-RX: (1) FT0;
 If you require any more information please don't hesitate to ask, I will create a new fault report for the Winkeyer issue.
Kind regards
Frank G3YQA

Tags:
Steps To Reproduce: N/A
Additional Information: Ticket# 360474
Attached Files: file.pdf (792,347 bytes) 2019-11-12 10:23
https://development.hamradiodeluxe.com/file_download.php?file_id=838&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2823 [1 - Backlog] Maintenance minor always 2018-07-31 05:00 2019-11-12 09:41
Reporter: PD9FER Platform:  
Assigned To: KB3NPH OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: DM780
Sub-Module: QSO Window
Testing: Not Started
Summary: Digital Master - Worked status in receive window not showing
Description: In Digital master's receive window there should be a Station worked icon behind the received Call sign.
Problem:

When running digital master on first start and decoding a signal, it does not show the V checkmark when there is a call in the decodeing window that has been worked before.
If you restart digital master the icon does show up.
Tags:
Steps To Reproduce: Start Rig control
Start Logbook
Start Digital Master

In Digital Master decode some signals and observe if you see one that you have worked before.
When it does, there should be a V icon behind the Call sign. (which does not happen)

Restart Digital Master and repeat the step.
You now will see the Icon appearing behind the worked station's Call sign.
Additional Information: Ticket #303249

Video showing the issue: https://www.facebook.com/kees.vanengelen/videos/2017592451598050/
 
Attached Files: 37971865_2016650745025554_8599019001881821184_n.jpg (2,119 bytes) 2018-07-31 05:00
https://development.hamradiodeluxe.com/file_download.php?file_id=489&type=bug
Notes
(0006438)
PD9FER   
2018-11-21 09:13   
Another report from Ticket #785491
(0008430)
K7ZCZ   
2019-08-22 14:34   
We looked at this in the 2019-08-22 meeting. The description isn't particularly clear, so I'm not able to understand the issue. Please augment the description with step-by-step instructions that clearly show the issue.
(0008433)
PD9FER   
2019-08-24 09:31   
The video says enough to me.
The worked status in the received window of DM is not consistent.

Not sure what steps to show...
Just have a properly Configed Logbook and Digital Master and tune in to any signal of a worked before station (one confirmed in Logbook)
(0008469)
K7ZCZ   
2019-08-29 17:26   
We revisited this issue in the team call on 2019-08-29. I was able to extract this information:


  • The "receive window" is reachable by using the "New Window" command in the "QSO" menu; or the "QSO" button on the toolbar. The "receive window" is actually the borderless pane at the top of the per-mode QSO tab that appears after using these commands. Some configurations might have this tab visible by default; mine doesn't.

  • The desired behaviour is that any call sign which appears in the stream of decoded text should be checked against the Logbook. (Thus, the Logbook app must be started and have a Logbook database open.) If the call sign is not found in the Logbook, it appears in the receive window's text stream without augmentation. If the call sign is found in the Logbook, it appears in the text stream with a check mark graphic next to it.

  • It's this behaviour that doesn't work reliably. In the call, it was revealed that the issue is intermittent. In particular, Ferry said that it will fail until DM780 is restarted, then after a restart it will work fine.

  • The issue is reproducible with any scheme that we can decode; RTTY, PSK, CW, and so on.



To repro the issue, we can:


  1. Start up the Logbook. Use a Logbook database with some entries.

  2. Start up DM-780. If necessary, use the "QSO" tool bar button to open a receive window

  3. Set DM-780 to use the sound card for input and output; we don't need a radio and can have DM-780 decode itself as it transmits.

  4. Enter text, including a call sign, in the transmit window

  5. As it's decoded, the call sign should appear in the receive pane.

  6. Entering (and thus receiving) a call sign previously logged should show a check mark decoration in the receive window.



Exercising the feature this way is expected to make it easy to exercise the feature and demonstrate the problem.

In the call, we discussed using the scheduled ARRL Bulletin as a reliable source for some encoded text which might be useful for reproducing the issue. While feasible, The Bulletin isn't particularly desirable, as the transmissions are done only once a day and reception might not be reliable. There are a few RTTY stations active near me which I might be able to utilize, but they're not even as reliable as the Bulletin.

The above process seems feasible, but Tim further offered to provide some recordings which included call sign transmissions to use for testing. This issue is presently assigned to him as a reminder to provide those recordings, though I might be able to make progress without them using the sound card loop-back.
(0008470)
PD9FER   
2019-08-30 03:59   
Those Repro steps looking okay to me.
One thing to make as a variable though.
Do test it with an MS Access DB as well an MySQL DB
(0008656)
K7ZCZ   
2019-09-25 08:26   
In the team call on 2019-09-19, this issue was identified as a minor problem and not a priority.
(0008670)
KB3NPH   
2019-09-25 14:47   
I don't believe anything has changed and I don't believe we totally de-prioritized this issue. It still requires fixing, but, I believe we do have a few other high priority issues to be resolved before attention is focused on this and I believe we wanted this prioritized by Mike B so he could just "work it into" his schedule of higher priority issues. I don't know, but this may be a major PITA, that's why we wanted Mike B to set his own priority on this one.
(0009288)
PD9FER   
2019-11-12 09:41   
Another customer having this issue
Ticket #676477


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3260 [1 - Backlog] Bug minor always 2019-03-26 10:10 2019-11-12 07:51
Reporter: PD9FER Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rotator
Sub-Module: Appearance/UI
Testing: Not Started
Summary: Rotator application, Gauge is not letting it resize
Description: When it the Rotator application with the Gauge(s) displayed, it was revisable in the past.
Now it wont let you drag it to a bigger size.
Tags:
Steps To Reproduce: Start rotator application
Try dragging one of the borders to resize the Gauge.
It looses focus and won't resize.
Additional Information: Ticket 631822
Attached Files: rotator.jpg (130,283 bytes) 2019-03-26 10:10
https://development.hamradiodeluxe.com/file_download.php?file_id=703&type=bug
Notes
(0009283)
PD9FER   
2019-11-12 07:51   
Ticket #245164 is a bit upset that this still is not done.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3576 [1 - Backlog] Bug minor always 2019-11-12 07:04 2019-11-12 07:04
Reporter: PD9FER Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: ALE Window
Testing: Not Started
Summary: Adding a call in ALE directly via [ENTER] takes a long time to populate im Logbook
Description: 1) when adding a CALL into the ADD screen and immeditaly hit TAB(all QRZ BIO / Rst 5/9,... will appear) and ENTER the call(e.g. PD9FER) will instantly be added to the logbook. This is is ofcourse the way to go as during contest and running a pile up this is an absolute MUST...

2) When adding a CALL into the add screen and immeditaely clicking ENTER it will take 4-8 seconds before it will be uploaded.

And even worse in both scenarios as seen above when a call is NOT into any QRZ database it will take ages before the call will be added to your logbook. You can imagine when running a pile up, contest, etc... this is VERY annoying.
Tags:
Steps To Reproduce: Set the enabled Lookup functions to: QRZ > Logbook > Country List
Open ALE
Put in a call and push TAB or click Lookup
Hit Enter
(result: taking a long time to add to logbook)

Do the same again but now Click F7 you notice a huge timing difference. (much faster)

It gets even worse when a call is not found on QRZ
Additional Information: Ticket #411474
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3575 [1 - Backlog] Bug minor always 2019-11-12 06:44 2019-11-12 06:44
Reporter: PD9FER Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Call lookup
Testing: Not Started
Summary: ALE Callsign lookup wrong with / country prefix
Description: Looking for PJ2/KB7Q is put in as USA bit in fact it is Curacao
Tags:
Steps To Reproduce: Open Tools > Configure > Callsign Lookup
In the Enabled methods have QRZ.com > Country List

Open ALE and enter PJ2/KB7Q
Look what country is returned.
Additional Information: Ticket #948866
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3549 [3 - Current Dev List] Bug minor always 2019-11-04 07:20 2019-11-10 19:00
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: SW License Mgmt
Sub-Module: SW License Client
Testing: Not Started
Summary: station info structure not initialized when debugging without QLM Developer license
Description: I'm able to debug the application on my laptop without a QLM developer license, but the station info data is not initialized in this case. This makes accurate debugging impossible since the station info includes settings and data used throughout the application. Since I do about 25% of my work for this project on my laptop, my productivity is impaired.

Tags:
Steps To Reproduce: 1) Start the Logbook under the debugger without a QLM dev license installed
2) Press OK On the "No QLM dev license" message
3) once the Logbook starts, open the "My Station" dialog

BUG#1) It's full of garbage. With the license check failure, the STATIONDATA and SharedMemory data structures are almost completely uninitialized and the program's function is impacted.
Additional Information:
Attached Files:
Notes
(0009173)
k8jhd   
2019-11-06 07:51   
unable to test on win 10 laptop-K8JHD


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3526 [3 - Current Dev List] Bug major always 2019-10-29 08:53 2019-11-09 09:06
Reporter: g3ucq Platform: PC  
Assigned To: OS: Windows  
Priority: high OS Version: 10 64 bit Home  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: ALE Window
Testing: Not Started
Summary: Adding a call sign previously worked error in ALE
Description: Adding a callsign that has previously been worked, pressing Partial or Exact does not populate the Logbook tab in ALE.
Only under certain circumstances.
Tags:
Steps To Reproduce: Open the Logbook and enter a call sign that has previously been worked.
Press the Logbook tab and either the Partial or Exact should be pressed.
Press the Lookup button.
Data is added to the ALE pane but no data shows under the Logbook tab.
Press the 'Find' button.
Previous QSOs will then show under the Logbook tab.
Press the Reset (F4) button to remove all the data.
Now re enter the same call sign as before and press Lookup.
Now press either the Partial or Exact buttons. The Logbook will be populated.
Now press Cancel to close the ALE.
Reopen the ALE and add the same call sign as before.
Press the Lookup button and the ALE pane is populated.
Press either the Partial or Exact buttons again and the Logbook is not populated.


Additional Information: This shows that the Logbook lookup ONLY works after the Find button is used but not after the Lookup button is used.
Is that the way it should be? I think not.
System Description
Attached Files:
Notes
(0009113)
w4elp   
2019-11-02 06:59   
Confirm G3UCQ's findings. Populating the Logbook tab with previous QSOs was automatic prior to v6.7, or perhaps the FIND button was persistent once clicked.. Having to click FIND each time a call is entered is very annoying.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3560 [1 - Backlog] Bug minor always 2019-11-08 13:33 2019-11-08 13:33
Reporter: w4elp Platform: PC  
Assigned To: OS: Win 10  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: (select)
Sub-Module: (select)
Testing:
Summary: HRD V6.7.0.xxx Logbook API query involving call sign causes Logbook to crash.
Description: I am using a separate program which uses the Logbook API to gather data on previous QSOs with the station in the ALE. Upon sending the API query, the Logbook crashes every time.
This worked prior to v6.7. Using Access database.

Tags:
Steps To Reproduce: Open HRD Logbook
Using PuTTY or similar program, open port 7826.
Send "db" and Enter - you get "Unrecognized Command" - that's ok.
Send "db list" and Enter - you get a list of the databases - That's ok.
Send "db get {CALL="W1AW"}" and Enter - No API response and Logbook immediately crashes.
Additional Information: I realize the Logbook API is not a priority, but it might be good to prevent Logbook from crashing in the event a query is received. Perhaps a "Not Available" response or something similar, if it is intended that the API will not be supported going forward.
Minidump attached below.
Attached Files: HRDLogbook_20191108_191126.mdmp (735,568 bytes) 2019-11-08 13:33
https://development.hamradiodeluxe.com/file_download.php?file_id=822&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3459 [Ham Radio Deluxe] Enhancement feature N/A 2019-09-25 10:40 2019-11-08 02:32
Reporter: g3ucq Platform: PC  
Assigned To: K7ZCZ OS: Windows  
Priority: normal OS Version: 10 64 bit Home  
Status: resolved Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version: 6.7.0.244  
    Target Version:  
Module: Rig Control
Sub-Module: Panadapter
Testing: Not Started
Summary: Add a frequency scale under the signals to the Panadapter window
Description: Add a frequency scale under the signals.
Tags:
Steps To Reproduce: Open Rig Control/Tools/Panadapter(Main)
There is no frequency scale under the signals, just frequencies at either end of the window.
See the image from N1MM+
Additional Information:
System Description
Attached Files: N1MM.jpg (81,450 bytes) 2019-09-25 10:40
https://development.hamradiodeluxe.com/file_download.php?file_id=755&type=bug
panadapter.jpg (55,644 bytes) 2019-10-23 03:24
https://development.hamradiodeluxe.com/file_download.php?file_id=795&type=bug
Notes
(0008663)
g3ucq   
2019-09-25 10:50   
Also please make the font for the frequencies larger as for N1MM+.
(0008674)
K7ZCZ   
2019-09-25 17:19   
John, please open a separate Mantis issue for the font suggestion. It's important to keep mantis issues as atomic as possible to facilitate tracking of the work.
(0008793)
K7ZCZ   
2019-10-12 18:40   
fixed with this checkin:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5203
(0008910)
g3ucq   
2019-10-23 03:24   
I do not see a frequency scale as the N1MM version. Just a frequency at either end of the window.
(0008953)
WA9PIE   
2019-10-23 07:13   
Fixed... or not fixed?
(0008955)
g3ucq   
2019-10-23 07:15   
Not fixed for me. Frequencies should be along the scale as for the N1MM window.
(0008963)
WA9PIE   
2019-10-23 07:38   
Validation failed per G3UCQ (thanks John)
(0008981)
K7ZCZ   
2019-10-23 11:14   
The capture in note 8910 here clearly shows the scales added. The top scale appears below the live waveform and above the frequency axis legend. The bottom scale appears below the spots area and above the waterfall.

If it's really more labels in the frequency axis that were desired, then I think it would be best to issue a separate Mantis issue with details of the specific request and what is expected. The request here, for scales on the frequency axis, has been implemented and appears to be working.

(0008983)
g3ucq   
2019-10-23 11:33   
I provided the N1MM+ image to illustrate how I would like the frequency scale to look.
I do not see why another Mantis is required.
(0009081)
WA9PIE   
2019-10-29 16:25   
The stated purpose of this Mantis issue is to "Add a frequency scale under the signals to the Panadapter window". Have we done that? It was in the original mock-ups in the functional spec.

As for the font size topic... that seems like a different topic and we probably should have another Mantis for it.
(0009094)
g3ucq   
2019-10-29 16:52   
There are divisions under the signals but surely the frequency should appear along the scale at intervals as on the measurements on a ruler. I have already created a Mantis for font sizes and that has been addressed.
(0009153)
g3ucq   
2019-11-06 04:02   
Is it necessary to have the frequency to 3 decimal places?
Should I open another Mantis for that?
(0009159)
K7ZCZ   
2019-11-06 04:41   
Yes, please


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3371 [Ham Radio Deluxe] Enhancement minor have not tried 2019-06-24 09:28 2019-11-08 02:32
Reporter: KB3NPH Platform:  
Assigned To: KB3NPH OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.7.0.244  
    Target Version:  
Module: Logbook
Sub-Module: Label
Testing: Not Started
Summary: Info for adding Brother PTouch P700 label printer to label printing options
Description: Ticket #694417

I use a Brother PTouch P700 label printer. Pretty standard for labels. It uses a tape cartridge that is identified as 24mm TZe tape, laminated.

 

The HRD “context” menu brings up a print dialog box. It permits me to select this printer (presumably because it is in my windows printers file, not because of anything unique to HRD). The dialog box permits me to change font styles, but not sizes. I assume it is somehow auto-sizing. There are numerous labels to choose from (the list seems to be duplicated many many times), but does not appear to have the label type I have and need.

 

I went to the “Create New” option and attempted to create a label. Given the limited menu choices in the dialog box, that is easier said than done. Each time I would try a setting, if I wanted to change a parameter, I had to delete the label and create a new label – because the edit label option only permitted changing (i) side margin, (ii) top margin, (iii) horizontal gap, and (iv) vertical gap. I could not edit the (a) label brand, (b) type, (c) width, (d) height, or (e) page type or orientation. In other words, there were limited (at best) items that could be edited. Further, when I selected address (as contrasted with QSL), I could not change the content of what was printed (i.e., I don’t like printing the call sign prior to the name and if in the US, I don’t usually print United States). The only items that were shown related to the QSL and not the address.

 

So, it appears that HRD has some work left.

 

I am providing the details, not because I’m upset, but in hopes it helps the development team.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0008230)
K7ZCZ   
2019-07-13 19:41   
I don't think it's realistic to support these devices without having them available for testing and development. The PTouch PT-P700 is about $65, and the PT-P750 is around $125. The devices take tapes for printing; the one-inch-wide tapes are about $10 each. I don't think we should offer support for smallter tape widths, since they're unlikely to be used by operators for QSL cards.
(0008574)
WA9PIE   
2019-09-22 02:52   
Tim - have you checked to see if Doug has added this in the 6.7 beta?

I purchased a Brother label printer... but Doug already has one. I'm not sure if it's exactly the same model. But I think he has added the ability to connect to the printer if it's installed.
(0009073)
WA9PIE   
2019-10-29 05:44   
With the most recent changes made, this should be fixed. Needs testing.
(0009076)
g3ucq   
2019-10-29 05:55   
Unable to test
(0009196)
g3ypp   
2019-11-07 08:32   
Unable to test


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3342 [Ham Radio Deluxe] Bug minor always 2019-06-11 08:32 2019-11-08 02:32
Reporter: K7ZCZ Platform:  
Assigned To: DOUG OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.7.0.244  
    Target Version:  
Module: SW License Mgmt
Sub-Module: SW License Client
Testing: Not Started
Summary: LicenseValidator constructor uses hard-coded product version number
Description: I noticed this code in the constructor for LicenseValidator (in LicenseValidator.cpp)

            license->DefineProduct (3, _bstr_t("HRD Software"), 6, 5, _bstr_t(""), _bstr_t("{f3712df5-2e48-4152-9dd2-a2bdd6ef2062}"));


I'm not sure what these numbers are used for, but it looks like "6, 5" is for the version number of the product. If so, to avoid surprises in the future, it seems like we should fix this code to use the macros defined in the hrdver.h header.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0008057)
DOUG   
2019-06-12 16:16   
I think if we change this it will not be backwards compatible with existing keys that exist in QLM. I will test it out, but I might recommend not changing automatically. If so I will just change the 6 and 5 to a better named #define for the min version key.
(0008170)
WA9PIE   
2019-06-22 11:22   
Sounds like we should discuss this to that we all understand it.

This doesn't look like a "show-stopper". It looks like something we could change at a later date. As such, I may remove its relationship to 1990.
(0008333)
WA9PIE   
2019-08-07 02:50   
Has this been added to a build?
(0008825)
K7ZCZ   
2019-10-15 17:23   
Looks like this checkin was made: https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5046

I don't really think this is a fix. It made some of the literal numbers into preprocessor macros, but not others. (Why?) Added a vague comment about "need to be really sure", but doesn't explain what we need to be sure of. Maybe a link to some documentation describing these parameters would be good. When should (or must) they be changed? Doesn't seem particularly maintainable, which is my main concern.
(0008838)
DOUG   
2019-10-16 22:52   
I think this is a bit confusing since we are using the same version number as the release, but in reality we don't want to tie QLM to a version. If we were starting over, based on Mike C's requirements I would have made this hard coded to 1,0 .

https://support.soraco.co/hc/en-us/articles/207611763-QlmLicense-DefineProduct

So essentially this line is hey, I need to check QLM and make sure it is ok if I run version 6.6. QLM will return valid as long as you have a valid key that expires after the publish date of the 6.6 product we have on QLM.

From a QLM perspective, it is designed so you can rev this line as you rev your product. Meaning, you an lock old keys out of the new product.
Mike C doesn't want that model so we need to leave it as is, unless we decide to change the licensing model in the future. With that background I hope my comment makes more sense. If you want I can add a 4th "really" :)


//
// IMPORTANT!!!!!
// The product version the licensing key is associated with is 6.6, if we change this
// all QLM licenses that are set to 6.6 and have an expired maintenance interval will
// no longer work with this version. This should not be changed unless we are really
// really really sure
//
(0008859)
K7ZCZ   
2019-10-18 05:21   
What's needed is clear guidance on what to be sure about. The comment doesn't provide that. Your explanation here might mean that we don't want to change the version numbers used here unless we want to completely expire the existing licenses, but I'm still not sure -- and I doubt anyone else reading that comment would feel any better about what the numbers might mean.
(0009154)
g3ucq   
2019-11-06 04:04   
Unable to test


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3443 [Ham Radio Deluxe] Maintenance minor have not tried 2019-08-28 10:02 2019-11-08 02:32
Reporter: K7ZCZ Platform:  
Assigned To: K7ZCZ OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: duplicate  
Projection: none      
ETA: none Fixed in Version: 6.7.0.244  
    Target Version:  
Module: Logbook
Sub-Module: Call lookup
Testing: Not Started
Summary: CLookupFieldComputer can mostly be removed
Description:
The CLookupFieldComputer class was an early cut at combining the copy-pasted call sign lookup code. It's now obsolete with the CCallsignLookupComponent implementation and can be removed. There are a few static functions that need to stay.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0008724)
K7ZCZ   
2019-09-30 19:26   
oops -- opened a duplicate for this work


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1645 [Ham Radio Deluxe] Enhancement feature always 2014-06-04 00:25 2019-11-08 02:32
Reporter: user36 Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.7.0.244  
    Target Version:  
Module: Logbook
Sub-Module: Label
Testing: Not Started
Summary: Logbook - Add option to select default label printer
Description: When printing labels, Logbook defaults to the default windows printer. Suggest adding an option to select either the Windows Default Printer or another installed printer of the user's choosing, such as a dedicated label printer.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0008423)
DOUG   
2019-08-18 21:34   
It looks like progress on this one was already made, it currently always remembers the last printer you used from log manager. Does that approach work for you?

One thought, it will use the last one used for both QSL and labels. Do we want an individual setting for both?
(0008604)
g3ucq   
2019-09-23 06:03   
Unable to test


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
560 [Ham Radio Deluxe] Bug block always 2013-12-21 18:56 2019-11-08 02:32
Reporter: W4PC Platform: Acer V5-471 (w/8GB RAM)  
Assigned To: PD9FER OS: Windows 8 (64 bit)  
Priority: normal OS Version: Pro  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.7.0.244  
    Target Version:  
Module: Rotator
Sub-Module: (select)
Testing: Not Started
Summary: HRD Rotator incompatible with Azimuth & Elevation range of Yaesu model G-5500 rotator
Description: HRD Rotator does not currently support 450 degree azimuth range of the Yaesu model G-5500 azimuth rotator. The maximum azimuth range choice currently provided in HRD Rotator presently is 360 degrees ("stop" at North); a maximum "stop" at 450 degrees East is needed. Also, HRD Rotator does not currently support 180 degree elevation range of the Yaesu G-5500 elevation rotator. The maximum elevation range setting found in HRD Rotator presently is 90 degrees; a maximum range choice of 180 degrees is needed in the rotator configuration.

This prevents proper operation of HRD Rotator when using SatTrack with Yaesu G-5500 rotators for those instances where satellite paths move outside the HRD Rotator path limits of 360 deg azimuth & 90 deg elevation, and where otherwise a loss of communications with the satellite results from the rotator swinging azimuth back around to pick up an elevation track that is interrupted.

HRD Rotator Logfile tab does show current elevation position values that exceed 90 degrees being received from the GS232B rotator controller device, but those values do not seem to be used by HRD Rotator or HRD Satellite Tracking, which is required to avoid loss of satellite position tracking and therefore radio communications with satellites whose path requires azimuth beginning <360 deg and ending >90 deg values.

Note that increasing the elevation range in HRD Rotator will require a change in the displayed elevation gauge in both Rotator and SatTrack to display 180 degrees. Note also that increasing the azimuth range in HRD Rotator should also require the displayed azimuth gauge in both Rotator and SatTrack to display 450 degrees via an "overlap" area marked adjacent to the 0-90 degree scale.
Tags:
Steps To Reproduce: (1) Connect any computer using either standard DB9 serial COM port, or USB-serial adapter cable, to a Yaesu GS232A or GS232B rotator (or emulator) device that is in turn connected to a Yaesu model G-5500 az-el antenna rotator.
(2) Configure HRD Rotator settings for Protocol= GS232A Az-El or GS232B Az-El.
(3) Make sure that "Gauges" are turned on/displayed in Rotator's main screen (button on right, display on left pane).
(4) Select "Stop Position" setting drop-down list; notice there is no choice displayed for 450 degrees East to match the capabilities of the Yaesu G-5500 rotator.
(5) Notice there is no configuration selection displayed anywhere for 180 degree elevation range for elevation rotator control. My recommendation is that a "Elevation Stop Position" be added to the rotator settings (including the preset profiles in Tools-Options-Configuration), and that the present "Stop Position setting drop-down list be renamed to "Azimuth Stop Position".
Additional Information: Tim kb3nph of HRD Support witnessed this during a remote control support session on Tue 8 Oct 2013.

The Yaesu G-5500 is the most popular antenna rotator (marketshare and installed base) for satellite tracking applications. It is also a popular rotator for EME (moon bounce), meteor scatter, APRS-GPS balloon tracking, and other az-el applications.

It is likely IMO that there are several other make/model antenna rotators in the market capable of 180 degrees elevation range and >360 degree azimuth range, besides the popular Yaesu G-5500 rotator, as such range requirements would be common for satellite & other sky object tracking.

I have read a report on an internet forum that this same problem prevents full compatibility of HRD with the Yaesu model G-5400 rotator. I cannot confirm, as I do not possess a G-5400.
Attached Files:
Notes
(0000277)
user19   
2014-01-31 20:32   
I have a G-5400 and can confirm the limitation. Jim
(0000641)
ag6hq   
2015-10-12 13:03   
The Yaesu G-800DXA, ‎G-1000DXA and the G-2800DXA rotors all have 450° rotation, and all can be controlled by a Yaesu and other brands of interfaces.
(0007516)
WA9PIE   
2019-02-26 18:08   
I understand the point here... but I don't think it's a big problem. We'll keep this on the list, but may decide we've got it covered by other methods.
(0008483)
PD9FER   
2019-09-01 02:51   
Got another one asking for a fix Ticket 831417
(0008522)
WA9PIE   
2019-09-07 08:44   
Ferry - give the beta to the customer and see if he can validate it.
(0008539)
PD9FER   
2019-09-08 02:37   
Beta given to customer, awaiting reply.
(0008544)
WA9PIE   
2019-09-13 23:42   
That was five days ago. Do we have an update?
(0008599)
g3ucq   
2019-09-23 05:57   
Unable to test
(0008613)
PD9FER   
2019-09-23 13:28   
No info as is
(0008626)
WA9PIE   
2019-09-24 00:16   
Ferry, please try to gather info. I won't be holding the release for the validation of this one.
(0008828)
PD9FER   
2019-10-16 07:54   
Sorry, customer won't reply
(0008845)
PD9FER   
2019-10-17 14:08   
Customer uses an arduino.
This is not a supported device, but just emulates it.

This should be closed
(0008846)
KB3NPH   
2019-10-17 14:16   
Since this is based on R3 ARDUINO we can't support it since it's a homebrewed controller emulating the GS-232A/B controller. Closing this issue.
(0009040)
WA9PIE   
2019-10-28 16:31   
This is not unique to any Arduino hardware. I've spoken to customers who have reported this as well. We'll get it tested at some point. I'm not holding the release for validating this.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3402 [Ham Radio Deluxe] Enhancement minor have not tried 2019-07-24 13:34 2019-11-08 02:31
Reporter: K7ZCZ Platform:  
Assigned To: K7ZCZ OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.7.0.244  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: Implement support for panadapter display in Kenwood TS-890
Description:
The Kenwood TS-890 has a panadapter display that is made avaialble over the serial port control interface as quantized power data for the selected frequency range. We can alter Rig Control to subscribe to that data and display it graphically to the user, then invent a UI that aids operators in tuning, spotting, and setting the radio.

The TS-890 uses a different protocol and data representation than the Icom radios, though the visible end result is quite similar. It looks like the TS-990 uses the same protocol for its waterfall; and maybe other Kenwood radios do, too. But we don't have access to those radios and for now can only attempt to implement support for the TS-890 because we have one on loan.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0008262)
K7ZCZ   
2019-07-24 13:42   
This check in to the 6.7 branch separates the Icom-specific code from the existing panadapter implementation and lays the framework for other radios. Some connections are made to that framework for the TS-890, but the panadapter feature for that radio does not yet work.

https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5089
(0008282)
K7ZCZ   
2019-07-26 10:19   
With the major refactoring done, this checkin does a bit more fine tuning and starts getting the Kenwood dialog hooked-up.
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5090
(0008294)
K7ZCZ   
2019-07-29 13:01   
This fixes a deadlock condition; gets the "speed" dropdown, "span" dropdown, and "ref level" slider working. all in the 6.7 branch:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5096
(0008295)
K7ZCZ   
2019-07-29 13:53   
Add control for bandscope attenuator:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5097
(0008297)
K7ZCZ   
2019-07-29 16:34   
Range drop down now works:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5098
(0008298)
K7ZCZ   
2019-07-29 16:50   
This is pretty much working, so I'm marking this resolved. We can start tracking bugs and feature requests from here on ...
(0008302)
K7ZCZ   
2019-07-30 14:31   
Ref Level range is configurable in CRadioCAps class
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5099
(0008607)
g3ucq   
2019-09-23 06:16   
Unable to test


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3378 [Ham Radio Deluxe] Bug minor always 2019-07-05 15:17 2019-11-08 02:31
Reporter: K7ZCZ Platform:  
Assigned To: K7ZCZ OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.6.0.236  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.7.0.244  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: Rig control: several radios don't correctly handle input and output processor slider settings
Description: The code in Rig Control to handle the Yaesu/Kenwood "PL" command isn't working correctly. Several variants of this command set the input and output processor strength settings in the same command. For example, "PL033055" would set the input level to 33 and the output level to 55.

Since the Rig Control UI wants to offer one control for each side, it will need to read the existing values from both sides, change the value for the side of interest, and then write the commanmd out.

The code to perform this function for almost all radios is badly broken and doesn't work. For most radios that have a single setting (PLnnn, which sets only the output processor), the code works fine.

Tags: FT-950, FT-991A, FTDX-1200, FTDX-3000, FTDX-5000, Kenwood, TS-2000, TS-480, TS-590, TS-890S, Yaesu
Steps To Reproduce:
1) Start up Rig Control, connected to one of the listed radios
2) Set the radio to view the input and output preprocessor levels. On the TS-890 ...
3) Make sure you're in a phone mode, like USB
4) Press and hold the bottom soft menu button labelled "PROC OFF" or "PROC ON" to reveal the speach processor settings
5) Assure that the "Speech proc. in" and "Speech proc. out" sliders are visible
6) Exercise the sliders.

BUG#1) The radio doesn't show the input or output level changing, an the slider snap back to the previous setting.

7) Use the + (F5) or - (F4) buttons on the radio's front panel to adjust either setting.

BUG#2) The radio changes it setting, but the change is not reflected in Rig Control's sliders

Additional Information: As far as I can tell, the involved radios are these:

Yaesu FT-950
Yaesu FT-3000
Yaesu FTDX-991
Yaesu FT-891
Yaesu FTDX-1200
Yaesu FT-1200
Yaesu FTDX-9000
Yaesu FTDX-5000
Kenwood TS-480
Kenwood TS-590
Kenwood TS-2000
Kenwood TS-890
Kenwood TS-990
Kenwood TS-870
Attached Files:
Notes
(0008196)
K7ZCZ   
2019-07-05 15:43   
fixed in the 6.7 branch with this checkin:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5050

(0008608)
g3ucq   
2019-09-23 06:17   
Unable to test


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3293 [Ham Radio Deluxe] Bug minor always 2019-04-14 19:38 2019-11-08 02:31
Reporter: K7ZCZ Platform:  
Assigned To: K7ZCZ OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.5.0.207  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.7.0.244  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: "OVL" indicator for IC-7610 in Rig Control doesn't work correctly
Description:
The "OVL" indicator should indicate a front-end overload, just as the same indicator on the radio does. It doesn't work right.
Tags: IC-7610, ICOM
Steps To Reproduce:
1) Start up Rig Control.
2) Connect to your IC-7610
3) Tune to a strong station. Attenuator off, RF gain up. This should get the OVL indicator in the radio flashing.

BUG#1) In Rig Control, the OVL indicator is on solid. If squelch is closed, OVL goes out. Seems like OVL directly follows the SQL indicator -- it shouldn't, they're correlated but independent.
Additional Information:
Attached Files:
Notes
(0007877)
K7ZCZ   
2019-04-23 12:14   
fixed with this checkin in the 6.7 branch:
Changeset 4953: first cut at IC-9700 support (Mantis 3189)
(0008606)
g3ucq   
2019-09-23 06:15   
Cannot see the OVL indicator on the Rig Control screen. Not many strong signals so used a broadcast station which was 40db over S9.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1663 [3 - Current Dev List] Enhancement major have not tried 2014-07-02 22:09 2019-11-08 02:28
Reporter: WA9PIE Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Data
Testing: Not Started
Summary: Satellite QSOs do not contain the correct fields for LOTW and not recognized
Description: Ticket #705520

I talked to Mike WA9PIE at Dayton about my problem. He gave me his card but his email address does not work as I get the email back undelivered. The problem is that when I upload QSOs to LOTW the satellite QSOs do not arrive. Refer to the attachment and you can see there are 5 QSOs that do not get accepted. There are no error reports from LOTW. I talked to the LOTW booth at Dayton and they said it is a HRD issue. I showed the problem to Mike using an example of how I do my log and he said for me to remind him after Dayton.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0004275)
PD9FER   
2017-10-29 02:59   
More alike tickets coming in

Ticket #830370
COL_BAND_RX was populated in the past, but not for all recent QSOS. Now COL_FREQ_RX is correctly populated with the frequency but COL_BAND_RX is empty instead of having 70cm or 2m etc.
Propagation should be SAT, I believe, for EQSL and other purposes, not "Satellit"

Ticket #662847
Eqsl upload as also LOTW etc. Should bring uplink frequency as main frequency to be uploaded for the QSO. HRD instead uploads downlink RX frequency and this can result in no matching QSOs. Also the field propagation type shouldn't be written by HRD with the statement 'Satellit' which I think can be wrong for LOTW and EQSL
For these two reasons QSO may go on direct QSO instead of SAT and on wrong band /mode
(0004289)
PD9FER   
2017-12-12 04:16   
Also reported via Ticket #113565

PROP_MODE not Being SAT whilst it is Entered,
(0004330)
PD9FER   
2018-02-28 07:11   
Another one.. Ticket #138950
(0006336)
PD9FER   
2018-10-23 06:23   
And once more Ticket #152674
(0007960)
K7ZCZ   
2019-05-30 16:52   
Switched to "enhnacement" per the team call on 2019-05-30
(0009012)
K7ZCZ   
2019-10-25 03:35   
There's just some incomplete notes here -- nothing clear or directly actionable. The description mentions attachments and there are no files here.

Maybe this is a dupe of 3142, but it's nothing that can be approached now due to the lack of detail and clarity in the report.
(0009015)
PD9FER   
2019-10-25 05:07   
I agree 3142 is Duplicate but has more information in it.
(0009207)
WA9PIE   
2019-11-08 02:28   
I'll take this until we sort out the detail.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3512 [3 - Current Dev List] General major always 2019-10-23 00:34 2019-11-08 02:22
Reporter: WA9PIE Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Call lookup
Testing: Not Started
Summary: Redesign of the Callsign Lookup's Enable tab UI
Description: In the 6.7.0.235 beta build, the Callsign Lookup dialog box contains a list of things that are meant to be re-ordered with things that are not meant to be re-ordered (meanwhile, I was able to move things that were not meant to be moved). I think this will confuse customers.

The purpose of this change request is to suggest a change in the UI that is intended to provide better clarity for the users about how the dialog box and feature works.
Tags:
Steps To Reproduce: - Launch Logbook
- Go to Tools, Configure, Callsign Lookup... Enable tab
- Observe how this could be confusing (those things that aren't meant to be reordered are among things that are meant to be reordered)
Additional Information:
Attached Files: CallsignLookupEnabledMethods.png (51,012 bytes) 2019-10-23 00:34
https://development.hamradiodeluxe.com/file_download.php?file_id=793&type=bug
Notes
(0009037)
K7ZCZ   
2019-10-28 12:19   
I don't think we have any evidence that this is confusing to our customers; we also haven't yet had a build where the implementation has been completely bug-free. It is thus hasty to discard hours of work until we have some concrete feedback from customers who've had a chance to use the completed implementation. If we find evidence that there are misunderstandings caused by the UI, I think we can come up with changes or enhancements to the existing design based on that feedback before we entertain a redesign.

With this reasoning, I'm resolving this as won't fix.
(0009206)
WA9PIE   
2019-11-08 02:22   
Reopened for further/future conversation.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3472 [3 - Current Dev List] Enhancement minor have not tried 2019-09-27 03:59 2019-11-08 02:18
Reporter: g3ucq Platform: PC  
Assigned To: g3ucq OS: Windows  
Priority: normal OS Version: 10 64 bit Home  
Status: feedback Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Panadapter
Testing: Not Started
Summary: settings for brightness and contrast in waterfall
Description: Please add controls to adjust Brightness and Contrast for the waterfall.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: N1MM.jpg (78,825 bytes) 2019-11-06 04:13
https://development.hamradiodeluxe.com/file_download.php?file_id=816&type=bug
Notes
(0008711)
K7ZCZ   
2019-09-27 09:08   
For now, the value reported from the radio is mapped to a range of 0..255. The color is chosen by using the mapped value for the red and green components of the color. The blue component is chosen by taking three times the mapped value, capped at 255. Thus, no signal strength maps to black, and full signal strength maps to white. Intermediate signals map to other colors with a stronger blue component; 50% signal strength is shown with #8080FF, for example.

Mathematically, the color is chosen by:

scale = 255 * (sample / fullScale)
color = RGB(scale, scale, max(255, scale * 3))


where sample is the given sample value in the radio's scale and fullScale is the radio's documented full-scale value.

The existing function, then, already has 100% dynamic range as it uses the full range of colors for the full intensity of the radio's scale; an since that range is drawn on a black background, it already has maximum contrast.

There are any number of different ways to convert signal strength into a visual representation, including color and intensity. I don't know of any standardized algorithms or transforms. Since this is largely a matter of preference, I think we should explore different mappings and keep those that seem particularly popular or effective. It will take time to collect feedback and suggestions and test.

Until then, the easiest way to adjust the display is with the base-line reference setting either in the panadapter window or on the radio.
(0008811)
K7ZCZ   
2019-10-13 14:29   
With the color settings available, I'm resolving this fixed. If you have some specific idea of how you'd like to mathematically define "contrast" and "brightness" as quantities in the context I've supplied, please do let me know and we can consider it.
(0008973)
WA9PIE   
2019-10-23 08:12   
Any word on the disposition of this item?

Code needed? Or not?
(0008974)
g3ucq   
2019-10-23 08:14   
Which ever way is implemented, the waterfall is too dark with poor contrast.
(0009156)
g3ucq   
2019-11-06 04:13   
N1MM+ has a contrast control so I can match the waterfall to that on my IC-7610.
(0009183)
WA9PIE   
2019-11-06 16:31   
I'm taking this out of Resolved status. It's clearly not "resolved."

It may be something we take-on after the initial 6.7 release.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3421 [3 - Current Dev List] Bug major always 2019-08-10 22:28 2019-11-08 02:17
Reporter: WA9PIE Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Website
Sub-Module: Functional
Testing: Not Started
Summary: Fix the entitlement issue when PayPal is used (UltraCart)
Description: We have a number of support tickets where customers attempt to purchase a renewal and they receive the following error during checkout:

"An existing software entitlement for HRDSMS can not be located on your customer profile. Please contact customer service for assistance renewing this software entitlement."

Tags:
Steps To Reproduce: Basically, the scenario works like this...

User puts HRDSMS (or a kit containing it) in his cart, clicks on Checkout... then they select either Express Checkout or an Existing Profile (it makes no difference)... after that choice is made, there is definitely a step here where the entitlement is checked. It passes this time because they're using the same email address that's in their UltraCart profile.

Then they choose form of payment - credit card or PayPal.

If they choose credit card, it's all fine.

If they choose PayPal... they get redirected to PayPal (to login and authorize the payment)... that brings them back to checkout... there's a box they need to check to accept the terms... then they click on submit (or whatever button is the final purchase button; I'm not going through it right now).

When that happens (my theory is)... the email address associated with the PayPal account gets checked now for entitlement (rather than the email address in the UltraCart profile). Because they don't match, the user gets that error.

I watched a guy do this tonight (N4MAV@arrl.net)... watched him get the error... asked him to change his form of payment from PayPal to credit card and it worked perfectly.
Additional Information: I have contacted UltraCart with this information.
Attached Files:
Notes
(0008419)
WA9PIE   
2019-08-18 02:44   
I'm working to verify, but the error may be gone, but there's another problem related to which email address is being sent to QLM and which UC profile is being updated.
(0008977)
WA9PIE   
2019-10-23 08:20   
Updating this...

Jonathan at UltraCart made a change that may have resolved the problem. We just need to watch for a bit to determine if it actually did resolve the problem (repro cases are difficult.)
(0009119)
WA9PIE   
2019-11-03 01:41   
I reopened this based on the comments in the following support ticket: #835944 (HRDLL-201910311956-422477)

I've sent the detail to UltraCart.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3557 [3 - Current Dev List] Bug minor always 2019-11-06 16:25 2019-11-07 10:09
Reporter: WA9PIE Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Call lookup
Testing: Not Started
Summary: Add DXCC Country as the last row in the address field for HamCall.net
Description: Because the address field is used for the mailing label, and because our customers are International, we should add the DXCC country as the last row in the address field.

(The address field is correctly being placed here for all other lookup methods except Hamcall; separate Mantis issue for it.)
Tags:
Steps To Reproduce: 1 - Launch Rig Control
2 - Launch Logbook
3 - Go to Tools > Configure > Callsign Lookup... Enable tab
4 - Add only HamCall.net
resulting order is UCSDB (Public), UCSDB (Private), HamCall.net, Country List
5 - Press "Apply"
6 - Click the "Test" tab
7 - Enter "WA9PIE" (without quotes) and click "Lookup"
8 - Observe the results where the address field does not populate Country at the bottom of the address field.

See attached image.
Additional Information: I don't consider this a show-stopper for the 6.7 release. If it gets done... great. Otherwise, we can do this in an upcoming maintenance release.
Attached Files: Hamcall address field.png (88,000 bytes) 2019-11-06 16:25
https://development.hamradiodeluxe.com/file_download.php?file_id=819&type=bug
CallsignLookupMapping4x.xlsx (25,936 bytes) 2019-11-06 22:22
https://development.hamradiodeluxe.com/file_download.php?file_id=820&type=bug
Notes
(0009185)
K7ZCZ   
2019-11-06 21:55   
The code is behaving per the specification right now. The specification says that the country line (the last line) of the address comes from field #209, which the API documentation describes as "mailing country". The lookup from WA9PIE yields no value for 209, so nothing is aded to the field.

The DXCC country field (the undocumented #225 field) is also blank, so there's no way to compute a DXCC country.

I don't see a way to do what you're asking. That must mean that you've actually intended to ask for something else. What is it? For example, the WA9PIE lookup returns "USA" for field #189, which the API describes as "Prefix Country". Should that value be used instead of the mailing country?

(0009186)
WA9PIE   
2019-11-06 22:22   
I had it wrong in the version of the field mapping spec you're looking at.

It later occurred to me that - if we're obtaining the country from the Country List... then it's a matter of putting the country name from the Country List as the last line in the address field.

Sorry about that. I'm attaching an in-progress version of that field mapping spec that I'm using to keep track of the "as-built" mapping. You'll see this in the yellow high-lighted HamCall.net column.
(0009193)
K7ZCZ   
2019-11-07 08:27   


I don't think releasing a product with a specification that' described as "in-progress" is good process.

If the code is changed to match what you're asking for here, the repro case provided still won't show a country name in the address because the call sign given doesn't offer a DXCC number at this data source. Is that what's desired?

(0009195)
WA9PIE   
2019-11-07 08:30   
Put the country from the distilled results on the last row of the address field.
(0009197)
K7ZCZ   
2019-11-07 10:09   
Right now, code for each lookup source produces a set of name-value pairs. In this case, the HamCall lookup produces an "Address" name with the a value that has an address that doesn't include a country name. The country name isn't included because this source doesn't provide one. This arrangement matches the specification, where each column in the spreadsheet shows a set of mappings from source fields to logbook column fields.

Since the HamCall lookup source (like all other lookup sources) atomically produces each named value it contributes to the results, we can't readily take one named value from the distilled results and use that value to edit the existing results from another value, from another source.

The lookup code works this way so that each source standardizes its representation of the results in a way that can be readily combined, displayed to the user, and placed in a logbook database record. For that standardization, "ADDRESS" is the name of one of the values. While other values exist which might be part of the address, the "ADDRESS" value is computed by each lookup source for itself, using its locally-known fields and rules.

Changing that would require removing the "ADDRESS" field and breaking it into component parts, standardized across each component, so that something added to the distillation step could consider different values from different sources when displaying the final "ADDRESS" value to users, or preparing COL_ADDRESS for the database.

Until today, this approach was compatible with the specification. The approach is modular, isolated, readily exensible, easy to understand, and pretty flexible.

Now that it's not, we're forced to consider alternatives -- and to do so just before a shipping deadline.

My first suggestion for an alternative would be to consider different sources for the country name. First, use field #209 ("Mailing address country"), if it's available. If not, use field #189 ("Prefix Call") from this source, if it is avaialble. If not, use the DXCC country name based on looking up the DXCC entity number in field #225.

Or, maybe there should be a different order.

As this repro case shows, there are records from this data source which have neitehr #209 nor #225 populated. Since the specification says to ignore #189, the source ends up producing no country name in the address (or in the COL_COUNTRY field, or any of the related fields).

If you'd like, we could have this component side-step the Coutry List component and have the country list produce a country name based on the prefix matching logic it has. If we take this approach, should it be done unconditionally without considering any other fields? Or should it be done only if certain fields are blank? In which order?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3556 [3 - Current Dev List] Bug minor always 2019-11-06 16:23 2019-11-06 22:24
Reporter: WA9PIE Platform:  
Assigned To: K7ZCZ OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Call lookup
Testing: Not Started
Summary: Add DXCC Country as the last row in the address field for callook.info
Description: Because the address field is used for the mailing label, and because our customers are International, we should add the DXCC country as the last row in the address field.

(The address field is correctly being placed here for all other lookup methods except Hamcall; separate Mantis issue for it.)
Tags:
Steps To Reproduce: 1 - Launch Rig Control
2 - Launch Logbook
3 - Go to Tools > Configure > Callsign Lookup... Enable tab
4 - Add only Callook.info
resulting order is UCSDB (Public), UCSDB (Private), Callook.info, Country List
5 - Press "Apply"
6 - Click the "Test" tab
7 - Enter "WA9PIE" (without quotes) and click "Lookup"
8 - Observe the results where the address field does not populate Country at the bottom of the address field.

See attached image.
Additional Information: I don't consider this a show-stopper for the 6.7 release. If it gets done... great. Otherwise, we can do this in an upcoming maintenance release.
Attached Files: Callook info address field.png (63,997 bytes) 2019-11-06 16:23
https://development.hamradiodeluxe.com/file_download.php?file_id=818&type=bug
Notes
(0009187)
K7ZCZ   
2019-11-06 22:22   
I think it's too late to do this work for the imminent release as it would be too destabilizing. If you're insistent on getting it done, then you should have one of the other developers look into it. You probably should do that anyhow, so they can start getting up to speed and are able to make progress in my absence.

(0009188)
WA9PIE   
2019-11-06 22:24   
I could do that. But for this change, I suspect it would take far longer to get someone up-to-speed vs. the amount of time it would take to make this change. Dunno.

But, the point regarding this change being made so close to the release is a concern that I share.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3541 [3 - Current Dev List] Enhancement minor have not tried 2019-11-02 23:13 2019-11-06 08:02
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.7.0.240  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Call lookup
Testing: Not Started
Summary: Call sign lookup test results could use report control
Description: The CodeJock report control allows for varying row heights, and would allow the lookup test results to show the address on multiple lines. The stock list control in Windows, which we're using now, doesn't support variable row heights.

The control would also allow embolding the selected data in the result group, which would give a visual cue to how the results are computed.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0009174)
k8jhd   
2019-11-06 08:02   
unable to test on win 10 laptop-K8JHD


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3555 [2 - Next Dev List (Holding Area)] Enhancement minor always 2019-11-06 06:04 2019-11-06 07:50
Reporter: g3ucq Platform:  
Assigned To: g3ucq OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Panadapter
Testing: Not Started
Summary: Frequency display in the Panadapter
Description: The frequencies displayed in the panadapter are to 3 decimal places.
Is that necessary?
Tags:
Steps To Reproduce: Open the panadapter (connected to a Icom IC-7610 in my case)
Note that the frequencies are displayed to 3 decimal places.
Too long IMO.
Additional Information:
Attached Files: panadapter.JPG (11,414 bytes) 2019-11-06 07:50
https://development.hamradiodeluxe.com/file_download.php?file_id=817&type=bug
Notes
(0009169)
K7ZCZ   
2019-11-06 06:09   
For me, only integers are displayed with nothing to the right of the decimal point. Please provide a screenshot.
(0009172)
g3ucq   
2019-11-06 07:50   
Are the last 3 numbers necessary?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3550 [3 - Current Dev List] Maintenance minor always 2019-11-04 08:44 2019-11-06 07:48
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: All
Sub-Module: Functional
Testing: Not Started
Summary: Awkard background thread architecture has dangerous deficiencies
Description: Rig Control, DM780, and Logbook all use an awkard BackgroundProcessingThread class to manage extra threads to handle actions outside of the UI-owning main thread. The class has an interface that is prone to creating buggy code that's hard to maintain and diagnose, is quite inefficient, and should be re-written.

The notable problems are here:


  • A single REQUEST_SIGNAL_DATA structure is used for all requests. The name of this structure is unrelated to the type of request, which makes the code hard to read or understand.

  • The thread implements several types of requests, but they're all initiated with an instance of that same RSD structure. A more sensible design gives each request its own structure type so that parameters can have descriptive names and accurate types -- no casting back and forth would be necessary.

  • The RSD structure is exposed to outside callers and shouldn't be. Instead, type-safe accessors functions should be used, or even buildable C++ objects so that parameter types and options can be clearly represented.

  • Many instances of the thread class exist, which naturally supports multiple threads and scaling. Each thread instance ends up only handling certain types of requests despite carrying local buffers used for the full set of requests types -- which not all threads will end up servicing. The result is a significant amount of wasted memory.

  • Code switches actions on an enum, then calls member functions of the thread class. A more OO design would hold a queue of polymorphic types (for type safety of the request data), then allow the request type to implement its own servicing function so that requests and their representative data were encapsulated together.



This large item might be attacked at once, but probably can be split into multiple issues for tracking ... at least for each affected application, if not for each work item. The result of fixing this issue will be safer application code, greater code reuse (allowing bug fixes in a single spot rather than hunt-and-repeat), and lower resource usage.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0009171)
k8jhd   
2019-11-06 07:48   
unable to test on my win 10 laptop-k8jhd


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3551 [1 - Backlog] Bug major always 2019-11-04 14:09 2019-11-06 05:27
Reporter: g3ucq Platform: PC  
Assigned To: g3ucq OS: Windows  
Priority: normal OS Version: 10 64 bit Home  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Panadapter
Testing: Not Started
Summary: Panadapter options reversed.
Description: The options for Mode/Centered and Fixed are reversed
Tags:
Steps To Reproduce: Use a rig that can use the Panadapter.
Open Rig Control/Tools/Panadapter (Main)
Select Mode/Fixed and the Span drop down menu becomes available.
The rig mode is changed to Fixed if not already.
The options from the Span drop down menu are not required in Fixed Mode.,
Change to Mode/Centered and the Span drop down menu becomes unavailable when it is needed.
Additional Information: The same role reversal issue applies to the Edges drop down menu.
It is greyed out when Mode/Fixed is selected and available with Mode/Centered is selected.
System Description
Attached Files:
Notes
(0009158)
K7ZCZ   
2019-11-06 04:36   
These settings are radio-specific, so it's necessary to know which radio model you've connected to when reproducing the issue.
(0009165)
g3ucq   
2019-11-06 05:27   
Sorry. Icom IC-7610


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3475 [3 - Current Dev List] Maintenance minor have not tried 2019-09-28 21:26 2019-11-02 23:13
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.7.0.226  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: All
Sub-Module: General
Testing: Not Started
Summary: upgrade to CodeJock 19.0 libraries
Description: CodeJock has released version 19.0 of their libraries; the change list is here: https://codejock.com/products/releasenotes/release_notes.asp

This version fixes the high-DPI problems we had with column widths (Mantis 3144), plus a localized resource conflict issue we also had to manually work around.

I think we should upgrade to this new version so we can remove the workarounds I had to make in the product to fix these issues for our own customers.
Tags:
Steps To Reproduce:
Additional Information: My CodeJock account doesn't show a valid license anymore. I don't if our support has expired or not. Seems a bit annoying that CodeJock took more than a year to fix these two issues -- tons of other fixes in this release, but these issues were quite substantial and not at all easy to work around.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3535 [3 - Current Dev List] Bug minor always 2019-11-01 10:25 2019-11-01 10:29
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.6.0.237  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: Rig Control polls radio continuously
Description: Rig Control polls radio continuously

When connected to a radio, the Rig Control application polls all of the radio's settings for without any delay or throttling. This results in a high rate of communication with the radio, which in turn causes noticable lag in UI response from the application.

Modern radios offer dozens -- sometimes hundreds -- of settings. When the Rig Control application refreshes, it requests values for every available slider and button, even if those controls aren't configured to be shown to the user. The Rig Control application must also serve other applications in the suite which connect to it over a listening network port. The network clients (which are probably local instances of other applications in the suite) might request any paramter of the radio.

When a user interacts with the UI, the commands they initiate are likely behind other requests the application is making for itself, causing lag in the response.

Rig Control should be modified so that that it requests the minimum number of radio paraemters to service the configured UI, plus any client applications. It should throttle the requests it makes so that it's not constantly polling the radio. When fixed, the application can guarantee a response time for user input and still serve the

On Icom radios, this fix would also make more bandwidth available for the panadapter feature which struggles to get its large amount of data through the hundreds of requests issued to support the numerous buttons, sliders, and modes on the IC-7610 and IC-9700.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2197 [1 - Backlog] Bug minor always 2017-08-11 17:24 2019-11-01 10:29
Reporter: K7ZCZ Platform:  
Assigned To: K7ZCZ OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: General
Testing: Not Started
Summary: Logbook open and close performance is slow
Description: The loogbook application stores records in memory, after reading them from the database. It does so with an egregiously bad data structure. If we imagine each record as a set of values for each column, we can think of each of those values as a “cell”. The value of the “call sign” cell in record #6 might be “K7ZCZ”, while the value of “Frequency” in record 102 might be “14.313.000”.

The logbook has about 120 columns that are visible to users; it maintains about 225 columns internally. Thus, each row has 225 cells. If you’ve got a logbook with 60,000 QSOs in it, the logbook is managing values for 225 * 60,000 == 13,500,000 cells.

The problem is that these cells are each managed as individually allocated or freed bits of memory. Some work was done to eliminate null, empty, or zero values; but in my testing, a 60,000-row logbook still allocates more than 4 million individual blocks of memory.
Tags:
Steps To Reproduce:
1) We have a 60,000-entry logbook for testing. Import it.
2) Close it. Takes about 50 seconds
3) Open it. Takes about 35 seconds.

Additional Information:
Attached Files:
Notes
(0004134)
K7ZCZ   
2017-09-07 22:31   
I've got a prototype fix for this. It needs to be integrated to the mainline, and tested further (particularly with Awards and Filter)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3537 [3 - Current Dev List] Maintenance minor always 2019-11-01 10:27 2019-11-01 10:27
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.6.0.237  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Data
Testing: Not Started
Summary: Logbook data is poorly structured
Description: Aside from the related issue, the Logbook struggles with the clear management of data in several formats. It's obliged to take data from several sources -- ADIF, Cabrillo, XML, and so on -- and store them in its own native format.

This challenge is poorly solved. In particular, the Logbook largely uses pairs of synchronized name/value arrays to represent records. These arrays are simply lists of strings, correlated so that the index of a field name in one array matches the index of a field name in another. To find a value, the name array must be searched until the field name is found, then the corresponding index referenced in the value array. Operations that involve lots of rows end up sharply O(n^2) for time complexity because of the inner loops over each field multiplying their effect on the large number of rows.

A map would be a far more appropriate data structure for this application, as linear searhces wouldn't be necessary. Further, instead of using strings as keys, integers could be used instead; this would be faster and require less memory. And individual structures (and sets of integer identifiers) could be adopted for each different data format. One structure represents ADIF records, one Cabrillo, one for native Logbook data, and so on ... making different C++ types for different representational types would make the code clearer and more efficient. A helper object (or individual memober functions) would be provided to implement translations, centralizing the code and avoiding the copy-and-paste clutter that permiates the code today.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3536 [3 - Current Dev List] Maintenance minor always 2019-11-01 10:27 2019-11-01 10:27
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.6.0.237  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: Rig Control radio definition structures lead to cumbersome program structure
Description:
The Rig Control application is largely driven by huge (!) structures in the RadioOptions.cpp these statically-initialized tables of data are keyed by radio and radio model, and offer command strings and some parameters for each command a radio might implement. The product supports more than 130 radios, and even simple radios have 20 to 30 commands. More interesting radios have more than 100 commands; there are many different tables grouped functionally, so the file is huge and cumbersome. The RadioOptions file is more than 23000 lines in length which, by any standard, is unacceptably long. The file size even causes tools to break; diffs in the Azure DevOps UI are impossible since the file is so long.

The tables are heterogeneous. Different radios live side-by-side, and not all commands or vendors implement things the same way. One command in a given table might need a two-digit hexadecimal number, while the very next command in the same table might use a four-digit decimal number as a parameter. Instead of putting the code and data in the same structure, functions in the CRadioOptions class attempt to handle each exception case, often varying common behaviour based on radio manufacturer and model.

The data is un-ordered. To find a command for a certain radio, the whole table is searched linearly. Hundreds of linear searches happen each second over these tables, since the Rig Control application pounds the radio interface without throttling (See Mantis 3535). As a result, CPU usage is very high and performance of the Rig Control application is affected. Large if/else trees and switch statements try to do the right thing, but the data and code are so far apart that any changes are cumbersome, and adding conditional code to fix one parameter for one radio ends up making the quagmire even thicker.

The structures use strings to identify radio manufacturers and models. The strings are redundantly stored with each command (rather than grouping commands of a single radio model into a structure), so memory usage is quite inefficient. Given the linear searches described above, Rig Control is performing hundreds of thousands -- probably millions -- of string comparison operations each second it's connected to a radio.

I've had some success splitting tables off into organized maps. (see RadioOptionsSliders.cpp, RadioOptionsToolTips.cpp, and so on ...) This effort should be refined and continued. A good way to start would be to identify candidates for refactoring and open tracking issues in Mantis for them. Once all the refactoring of the data tables is done, code can be refactored so that each entry in the table represents an functional object that actually implements the command, rather than passive data that supports some other code which implements the command.

This ends up being an incremental rewrite of the Rig Control engine, but I think it's importance can't be denied. The code right now is barely maintainable design mistakes are showing through to the product's implementation an usability.

In order to approach the completion of the rewrite, the team will have to be willing to accept that the fix might make things worse before they get better. Since the company owns very few radios to sue for testing, and promises to support such a wide variety of radios, it might be that a rewrite is unrealistic. This mostly leaves us stuck with the poor decisions, though some incremental progress might still be possible.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3516 [1 - Backlog] Enhancement minor always 2019-10-23 05:49 2019-10-30 21:30
Reporter: g3ucq Platform: PC  
Assigned To: OS: Windows  
Priority: normal OS Version: 10 64 bit Home  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Panadapter
Testing: Not Started
Summary: Minimise/Maximise option on the Panadapter window
Description: There is no Minimise/Maximise option on the Panadapter window
Tags:
Steps To Reproduce: Open Rig Control with a radio that can use the Panadapter.
Rig Control/Tools/ Panadapter (Main)
Notice there is no option to minimise or maximise the Panadapter window.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3428 [3 - Current Dev List] Enhancement minor have not tried 2019-08-11 14:55 2019-10-30 21:30
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.7.0.215  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: (select)
Testing: Not Started
Summary: Add code to horizontally scale Panadapter
Description:
The panadapter can't be resized horizontally. It's a bunch of math to do this, and we need to be sure we can do that math rapidly enough to keep up with re-drawing the display. But it would certainly be nice to stretch the graph horizontally.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3457 [3 - Current Dev List] Bug minor have not tried 2019-09-25 10:05 2019-10-30 21:29
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.7.0.227  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: SW License Mgmt
Sub-Module: SW License Client
Testing: Not Started
Summary: HRD drops a file in the root of the user's Documents directory
Description:
The licensing manager client drops an XML file in the users Documents directory (at %USERPROFILE%\documents). Application-specific files should be in an application-specific folder, not at the root of the Documents directory. I'm not sure hwat this file is specifically for, but it for sure belongs someplace else.
Tags:
Steps To Reproduce:
1) Start with a clean machine
2) Install HRD
3) Check the %USERPROFILE%\documents directory for a file named "HRD Software 7.0.lw.xml". It's not there.
4) Run Rig Control
5) The software presents the licence key dialog. Enter a valid license and activate it.
6) Check the %USERPROFILE%\documents folder.

BUG#1) A file named "HRD Software 7.0.lw.xml" has appeared.


7) Shut down Rig Control
8) Uninstall HRD with the control panel
9) Return to the %USERPROFILE%\documents directory

BUG#2) The "HRD Software 7.0.lw.xml" file is still there. Maybe it's meant to survive an uninstall, dunno what it's for. But it shouldn't be in this directory.
Additional Information:
Attached Files:
Notes
(0009108)
K7ZCZ   
2019-10-30 21:29   
A file with the same name is also placed in the "C:\Program Files (x86)\HRD Software LLC\Ham Radio Deluxe" directory after setup runs. Why are two copies of the same file needed? Are they both actually used?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3532 [3 - Current Dev List] Bug minor sometimes 2019-10-30 18:36 2019-10-30 19:29
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.6.0.237  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: (select)
Testing: Not Started
Summary: Lookup pane in Logbook suffers from race condition
Description:
The code that implements the Lookup pane in the Logbook performs two operations. It does a call sign lookup operation, then also does a WSI lookup. The code is written in a way that assumes the call sign lookup operation finishes first, then the WSI lookup completes. If the work doesn't complete in this order, the Lookup pane won't display valid results, and might display no results at all.

Tags:
Steps To Reproduce:
There's not really a solid repro for this, which is the nature of a race problem. The problem is more likely to show itself when more look up data sources are enabled than fewer; and is more likely to be apparent when there are fewer (just one) WSI-configured data sources than more.

The 6.6 and 6.7 releases have the same problem.
Additional Information:
Attached Files:
Notes
(0009107)
WA9PIE   
2019-10-30 19:29   
Good catch. This is exactly the kind of things I hope we find and fix.

That said, we should take this on post 6.7.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3531 [3 - Current Dev List] Bug minor have not tried 2019-10-30 18:35 2019-10-30 19:28
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.6.0.237  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: (select)
Testing: Not Started
Summary: Logbook Lookup Pane ignores or doesn't handle database errors
Description:
The Lookup pane in the logbook performs lookups to resolve WSI data against various databases. It ignores errors from those databases and doesn't notify the user that the results they're getting might be incorrect. If the user expects correct worked status information, then the Logbook's failure to connect to a database configured to be used for WSI information should be brought to the user's attention so they know the information they see isn't correct, and they can take corrective action.
Tags:
Steps To Reproduce: 1) Start up the Logbook. Note that this issue documents a problem with the 6.6 version of the product.
2) Use the "Manager" button on the main toolbar to open the "Logbook Databases" window
3) In this window, configure a new database that's hosted in a MySQL database
4) Make the new database configured for WSI lookups. Right-click on the database's row in the list to change it.
5) Once configured, close the "Logbook databases" window.
6) Import some records to the MySQL database from whatever source you'd like. Or, create a few new, identifiable records manually.
7) Close the Logbook
8) Shutdown the MySQL database server.
9) Start up the logbook again. At this point, you might have another database opened, or not -- doesn't matter much. But the Logbook is still configured to do WSI lookups from the MySQL database configured in Step #3. This database is no longer reachable because of Step #8.

10) use the "Lookup" command in the "View" menu to open the "Lookup" pane
11) Enter a call sign

BUG#1) The Lookup pane takes quite a while to run, but produces results. No errors are displayed to the user.
Additional Information:
Attached Files:
Notes
(0009106)
WA9PIE   
2019-10-30 19:28   
Good catch. I completely agree that we should fix this.

That said... we'll take this up post 6.7. (If we get it back to the way it was in 6.6.0.237, it won't be any worse than it was then.)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3530 [3 - Current Dev List] Bug minor always 2019-10-30 18:34 2019-10-30 19:27
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.6.0.237  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: (select)
Testing: Not Started
Summary: Lookup Pane uses WSI-configured databases for lookups
Description:
Per the attached annotated picture, the lookup pane in the Logbook should use only the open Logbook to resolve the entered callsign. Instead, it's using each of the databases configured for WSI lookup in the Database Manager.
Tags:
Steps To Reproduce:
1) Start up the Logbook. Note that this issue documents a problem with the 6.6 version of the product.
2) Close whatever database you've got open. This might leave a blank central pane, but you might have the Radio Screen or Logfile tabs.
3) Use the "Manager" button on the main toolbar to open the "Logbook Databases" window
4) In the window, find a database that isn't configured for WSI lookups. it'll have a blank "WSI" column. You can right-click on an existing database to change it. Or, you might need to create a new database if you don't have one. This test requires a database that isn't empty.
5) In this same window, find a database that is configured for WSI lookup. Any database that has "Yes" in the "WSI" column will do. You can right-click on an existing database to configure it. Or, you might need to create a new database. You'll want a non-empty database for this test, though.
6) Close the "Logbook Databases" window.
7) Open the WSI-enabled database from Step #5
8) Open the WSI-disabled database from Step #4.
10) Make sure the WSI-disabled database is the active tab in the Logbook's main window
10) use the "Lookup" command in the "View" menu to open the "Lookup" pane
11) Enter a callsign

BUG#1) It looks up against the WSI database, not the in-focus database.


Additional Information:
Attached Files: Lookup.jpg (312,561 bytes) 2019-10-30 18:44
https://development.hamradiodeluxe.com/file_download.php?file_id=802&type=bug
Notes
(0009100)
K7ZCZ   
2019-10-30 18:44   
attached image
(0009105)
WA9PIE   
2019-10-30 19:27   
I was likely incorrect when I referred to the "in focus database."

I'm not sure what we do want in this case... other than - for now, we should put it back the way it was.

We can take this up post 6.7.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3529 [3 - Current Dev List] Bug minor always 2019-10-30 18:34 2019-10-30 19:25
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.6.0.237  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: (select)
Testing: Not Started
Summary: Lookup Pane works even when no Logbook database has focus
Description:
The attached picture says that the lookup pane in the Logbook should work against the one open logbook that is in-focus. However, it actually works when no logbook databases are open at all.

Tags:
Steps To Reproduce:

1) Start up the Logbook. Note that this issue describes a problem with the 6.6 version of the product.
2) Close whatever database you've got open. This might leave a blank central pane, but you might have the Radio Screen or Logfile tabs. No database tabs, though
3) use the "Lookup" command in the "View" menu to open the "Lookup" pane

BUG#1) The pane is enabled and allows input. Since it't can't possibly work (with no Logbook database open) it should be completely disabled.

4) Enter a call sign.

BUG#2) The lookup operation will run and the pane will at least partially populate (for a valid cal lsign).


Additional Information:
Attached Files: Lookup.jpg (312,561 bytes) 2019-10-30 18:44
https://development.hamradiodeluxe.com/file_download.php?file_id=803&type=bug
Notes
(0009101)
K7ZCZ   
2019-10-30 18:44   
attaching image
(0009104)
WA9PIE   
2019-10-30 19:25   
This is a valid point, as it applies to all the WSI values in the Callsign and Country sections. It's reasonable to have it enabled for the purpose of displaying data in the Licensee section... or show information in the upper section of the Country section that are unrelated to WSI and come from the lookup source.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3534 [3 - Current Dev List] Bug minor always 2019-10-30 19:02 2019-10-30 19:23
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.6.0.237  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: (select)
Testing: Not Started
Summary: Lookup pane spuriously looks up call signs only partially entered
Description:
The call sign lookup pain works on a timer of about half a second and will try to perform a look up operation while the user is still typing. This is a poor user experince as the result is startling and unexpected. The pane populates with incorrect information. As a lookup operation also several seconds to complete, and doesn't show progress, it's not readily corrected.

Generally, a timeout shouldn't be a duration less than the duration of the operation itself.

Tags:
Steps To Reproduce:
1) Start up the Logbook. This issue reproduces with either 6.6 or 6.7 builds. Might reproduce with earlier builds, too.
2) Use the "Lookup" command in the "View" menu of the Logbook to show the Lookup pane
3) Enter "N9V". Pause here. Maybe you're trying to remember the call sign of that operator -- was it "N9VG" or "N9VJ"?

BUG#1) Doesn't matter what you wanted; the logbook has already looked up the wrong call sign at N9V.

4) Type "G".

BUG#2) Wait. The first operation isn't complete yet. It will finish after a few seconds, then the "N9VG" operation will start.
Additional Information:
Attached Files:
Notes
(0009103)
WA9PIE   
2019-10-30 19:23   
Good point. This is similar to the topic related to partial calls that was changed a couple years ago. It's reasonable to expect the user to hit "Enter" or something in order to let the function know that it was meant to search.

Keep in mind... clicking on a spot from the DX cluster is meant to put the spotted call into the Lookup Pane and do the lookup. We wouldn't want the user to also have to go over there and take additional actions to cause the lookup in the pane (clicking in the field and hitting Enter, for example).

We can do this work post 6.7.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3533 [3 - Current Dev List] Enhancement minor always 2019-10-30 19:02 2019-10-30 19:19
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: (select)
Testing: Not Started
Summary: Lookup pane in Logbook doesn't update highlight of current radio band or mode
Description: The attached annotated screenshot says that band and mode information returned for matches to the current callsign should be in brackets. If the list contains "20m, 30m, 40m", for example, and the radio is tuned to "40m", the 40m entry should be in square brackets as "20m, 30m, [40m]".

The brackets do appear if the band or mode is selected in the radio at the time the lookup operation runs. But the markers are not updated when the radio changes bands or modes.
Tags:
Steps To Reproduce: 1) Start up the Logbook. This issue reproduces with either 6.6 or 6.7 builds. Might reproduce with earlier builds, too.
2) Start up Rig Control and connect to your radio.
3) Tune the radio anywhere in the 40m band
4) In the Logbook, open a non-empty database.
5) Use the "Lookup" command in the "View" menu of the Logbook to show the Lookup pane
6) Enter a callsign and wait for the lookup to populate
7) Note that the "Bands" displayed for the lookup will include "[40m]".
8) Tune the radio to 20m

BUG#1) The brackets remain around [40m].
Additional Information:
Attached Files: Lookup.jpg (312,561 bytes) 2019-10-30 19:02
https://development.hamradiodeluxe.com/file_download.php?file_id=804&type=bug
Notes
(0009102)
WA9PIE   
2019-10-30 19:19   
This is an interesting idea. I consider it an enhancement. Actually, quite a good idea.

I think Erik added the brackets a long time ago as a test mechanism. I don't think it was ever intended to change.

So we'll hold this for future improvement. I'm going to change the Category from Bug to Enhancement.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3458 [3 - Current Dev List] Enhancement feature have not tried 2019-09-25 10:28 2019-10-29 08:29
Reporter: g3ucq Platform: PC  
Assigned To: g3ucq OS: Windows  
Priority: high OS Version: 10 64 bit Home  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Panadapter
Testing: Not Started
Summary: add ability to resize the panadapter window
Description: Ability to resize the panadapter window
Tags:
Steps To Reproduce: Open Rig Control/Tools/Panadapter(Main)
It is not possible to resize the window.
It should be possible to resize the window at least horizontally.
Additional Information: The Panadapter needs to be added to the Module (Rig Control/Panadapter)
System Description
Attached Files:
Notes
(0008675)
K7ZCZ   
2019-09-25 17:21   
It is already possible to resize the panadapter window vertically. We'll eventually add the scaling necessary to resize the window horizontally.
(0008690)
g3ucq   
2019-09-26 08:35   
The window can be resized from the top up but not from the bottom down.
(0008696)
K7ZCZ   
2019-09-26 09:12   
Vertical resizing works both from the top edge or the bottom edge for me, no problem.
(0009077)
WA9PIE   
2019-10-29 06:55   
John,

Can you restest this, based on MikeB's comments?
(0009078)
g3ucq   
2019-10-29 08:29   
Yes, the window can be resized from top and bottom but not horizontally even though the resize arrows show.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3313 [3 - Current Dev List] Bug minor always 2019-05-12 21:25 2019-10-29 05:46
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.208  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Reports
Testing: Not Started
Summary: In Logbook "Print" dialog, font, "Range" and "Print On" combos should be drop-downs
Description:
The Logbook's "Print" dialog has a couple of combo boxes that offer only two coices. Because these controls are combo boxes, they have an edit control where the user can type in anything they'd like -- even if it's not a valid choice.

Same for the un-labelled control which enumerates fonts. We have a fixed list of fonts, so users should not be able to type in an arbitrary name.

These shoudn't be combo boxes; they should be drop-down lists, which wouldn't allow the user to type arbitrary text.

The Range box has only two choices; the "Print On" list has only three choices. Seems like these should be a collection of radio buttons instead.
Tags:
Steps To Reproduce:
1) Start up the logbook
2) Use the "Print Labels" command in the "File" menu
3) Click on the "Range" control
4) Type "XYZZY".

BUG#1) You can type that, even though the only valid choices for this box are "Selected" and "All".
Additional Information:
Attached Files:
Notes
(0009074)
WA9PIE   
2019-10-29 05:46   
I tested this in the 6.7.0.239 build. It is not fixed.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2682 [1 - Backlog] Enhancement minor have not tried 2018-04-17 13:29 2019-10-29 05:37
Reporter: KB3NPH Platform:  
Assigned To: KB3NPH OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: DM780
Sub-Module: ALE Window
Testing: Not Started
Summary: DM-780 ALE not resolving Country in same manner as Logbook ALE
Description: Mike posted 04/17/2018 11:43 AM
In the ALE pane of DM-780, if you enter Z66D as the callsign, the ALE pane resolves the country as the Czech Republic.

If you enter Z66D as the callsign in the add ALE of Logbook, the ALE pane requests that the user choose the correct country, either the Republic of Kosovo or the Czech Republic.

QSOs logged using the DM-780 DX country resolution process may be logged with the incorrect DX country.
Tags:
Steps To Reproduce:
Additional Information: Ticket #604809
Attached Files:
Notes
(0008003)
K7ZCZ   
2019-06-06 13:27   
(Last edited: 2019-06-06 13:28)
It's not perfectly clear how countries are "resolved" in the Logbook; maybe this is related to the work being done in Mantis 3001 to revamp the callsign lookup code.

How does this issue related to 3001? Is a specification available that describes how the country of a callsign should be resolved? We can't just say that "it should be the same as the Logbook" because the way the Logbook does it is also broken -- or, at least, being changed -- so I think it's important to be very precise and deliberate in describing the desired behaviour.

(0008145)
WA9PIE   
2019-06-20 14:38   
Updated to change from bug to enhancement.
(0008314)
KB3NPH   
2019-08-01 09:59   
I would say it is related to 3001. If there have been specifications set for the lookup in Logbook, those same specs should be followed in all areas where the Lookup data is displayed which seems to me that would include the ALE in DM-780.
(0009067)
WA9PIE   
2019-10-29 05:37   
While the 0003001 work resolved most of the callsign lookup problems with DM-780, a few remain. They're minor. We'll take them up after the 6.7 release.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2883 [1 - Backlog] Bug tweak always 2018-09-07 11:28 2019-10-29 05:34
Reporter: k2ie Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Call lookup
Testing: Not Started
Summary: Calbook (qrz.com) should not override UDP API supplied value for grid
Description: QSOs entered via the UDP QSO Forwarding API go through a callbook lookup when the Lookup Missing Fields on Receive box is checked. However, the grid locator supplied by that lookup may not be the same one supplied by the logged station during the QSO. Where a non empty grid locator is supplied by the API, the callbook lookup should never override this value.
Tags:
Steps To Reproduce: Log a QSO via the API where the grid square reported by the DX station is different from the one recorded in the callbook (ie qrz.com).
Additional Information:
Attached Files:
Notes
(0006133)
vk2byi   
2018-09-08 00:54   
Dan makes a good point regarding the grid locator. A non-empty locator value being forwarded by WSJT-X should always be logged as the actual location for the contact - not the location of record for their home station.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1554 [1 - Backlog] Enhancement feature N/A 2014-01-27 11:13 2019-10-29 05:33
Reporter: WA9PIE Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Call lookup
Testing: Not Started
Summary: Add function to use Callsign lookup on log import or initiate full log update
Description: DXLabs has the ability to initiate XML lookups for QRZ subscribers for log imports. This is a big gap for us.

What we need is the ability to allow the user to use the Callsign Lookup selections (QRZ, Logbook, Callook.info, Country file... as selected) to fill-in missing fields. This is the same thing we do for ALE... but we would just be doing this on import.

We also need the ability to initiate a full lookup for existing logs. (when we do, it's probably best to start with the newest QSO records first. But we should discuss.)
Tags: ParityGap
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0005263)
WA9PIE   
2018-06-13 21:47   
This is related to 2262... only this describes a process that would happen on import. Competing software can do this.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2006 [1 - Backlog] Enhancement feature have not tried 2017-03-23 11:28 2019-10-29 05:33
Reporter: w6hdg Platform:  
Assigned To: WA9PIE OS:  
Priority: low OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: DM780
Sub-Module: ALE Window
Testing:
Summary: Unify ALE into a single window for Logbook and DM780. Add a pictorial compact QRZ page within the larger unified ALE window
Description: I realize this is pie in the sky. But it would be so terrific to not have to transfer callsigns from the Logbook ALE to the DM780 ALE. You would have the advantages of all the terrific info in the Logbook ALE when making Digital/CW contacts (things like heading, LoTW status, prior details of all contacts, etc). An integral small QRZ box similar to MacLogger and "Cluster at a Glance" graphic would be so useful too. see http://www.w6hdg.com/MacLogger.jpg
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0008272)
WA9PIE   
2019-07-25 15:29   
Before we take action on this, I'd like to extend the conversation about it before we do work on this.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
472 [1 - Backlog] Enhancement feature N/A 2013-12-21 18:56 2019-10-29 05:33
Reporter: WA9PIE Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: (select)
Testing:
Summary: Add QRZ.com photo download into contact & option to show on ALE
Description: Users have indicated that "other logging programs download the picture from QRZ". So this is a user request.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: QRZ picture.jpg (165,577 bytes) 2014-02-26 11:53
https://development.hamradiodeluxe.com/file_download.php?file_id=11&type=bug
Logbook-Images.PNG (507,971 bytes) 2019-03-10 20:19
https://development.hamradiodeluxe.com/file_download.php?file_id=699&type=bug
Notes
(0000360)
WA9PIE   
2014-02-26 11:54   
From: GM0PHW@hamcall.co.uk [mailto:GM0PHW@hamcall.co.uk]
Sent: Tuesday, February 25, 2014 2:40 PM
To: mike@wa9pie.net
Subject: Product Enhancement...

Sir,

I have sent a few emails regarding HRD and wondered if HRD will be making a product enhancement that I asked about, i.e. as well as displaying information on the amateur you are in QSO with HRD display's their picture that is on QRZ.com (if one is available) I have taken the liberty and done a mock up of what it may look like using your call sign, I hope you don't mind, I hope you agree it looks great and helps fill some dead space, I am sure it will create more sales, I for one would purchase as would quite a number of other amateurs that I have spoken to.
 
Thanks for listening.
 
Mike
(0005237)
WA9PIE   
2018-06-11 23:33   
The user who made this request has left the beta team (a 4Z call).
(0006827)
WA9PIE   
2018-12-30 00:37   
In the QRZ XML data, the path for this picture is found in the "image" tag. For example, for callsign NB6GC:

<image>
https://s3.amazonaws.com/files.qrz.com/c/nb6gc/nb6gc.jpg
</image>
(0007572)
K7ZCZ   
2019-03-04 13:02   
Is the intent that the URL in the image tag is stored, then the image retrieved for display when the user visits the record?

Or is the intent that the image is downloaded from the URL when the record is retrieved, and the image itself stored in the database?
(0007663)
WA9PIE   
2019-03-10 20:19   
Here's another mock-up for the photo (image).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1395 [1 - Backlog] Enhancement feature always 2013-12-23 21:44 2019-10-29 05:29
Reporter: Support Platform: None  
Assigned To: OS: Windows  
Priority: low OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: (select)
Testing:
Summary: Automatically calculate location
Description: HRD Logbook asks for latitude & longitude, so why not use that info to
automatically calculate gridsquare, CQ and ITU zones as well? Maybe also IOTA.
Tags:
Steps To Reproduce: In Logbook, go to Tools/Configure/My Station
Additional Information: Reported by bigdog
Attached Files:
Notes
(0000310)
WA9PIE   
2014-02-02 10:30   
Not ready to "Assign" these yet. Changing status.
(0009064)
WA9PIE   
2019-10-29 05:29   
I'm removing the association to 0003001. I believe this is resolved. It cannot be reproduced.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2262 [1 - Backlog] Enhancement feature N/A 2017-09-22 23:19 2019-10-29 05:26
Reporter: WA9PIE Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.4.0.787  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Call lookup
Testing: Not Started
Summary: Add bulk callsign lookup in Logbook
Description: Context:

Users who import their logs from programs like N1MM complain that they have to open each individual QSO record and click the "callsign lookup button" in order to populate fields from the callsign lookup sources. They don't want to do this one-at-a-time.

The request is to enable bulk callsign lookup on selected records.

(This could actually apply to records imported from any third-party logging program. We hear it a lot from contesters who have used N1MM, N3FJP, Write Log... and so on. Point is to give folks a bulk callsign lookup option so they don't have to go one-by-one through several hundred QSOs to do lookups.)

The theory is that there is a "callsign lookup function". It should be the same function that is called when a callsign is looked up in the ALE. This is the same lookup function that should be used for this enhancement.
Tags:
Steps To Reproduce: Here's a use-case scenario:

User has some number of QSOs in the log where the worked station's fields have not been populated from the callsign lookup sources.
- User selects some number of QSOs in the log
- Right-click menu shows "Callsign Lookup" (see attached image below)
- Logbook sends each QSO out to the callsign lookup selections (same logic currently used when a single QSO is logged) and brings back data for that call... fills the fields as it would if it were a new QSO... then moves to the next selected QSO... repeats until all selected QSOs have completed.

This should probably run as a background process (in other words... not tie-up Logbook while this is happening).
Additional Information: We 'could' take the opportunity to clean up the session problems with QRZ at this time. This is where the each lookup creates a new session key instead of maintaining it. Dunno.

We presently don't have any error messages that are presented when the callsign lookup fails - due to network issues, authentication... etc. We could add something like that... but I'm not requesting it at this time.
Attached Files: batch-lookup.PNG (67,100 bytes) 2018-03-11 22:31
https://development.hamradiodeluxe.com/file_download.php?file_id=289&type=bug
BulkCallsignLookup.png (85,796 bytes) 2018-04-25 21:49
https://development.hamradiodeluxe.com/file_download.php?file_id=377&type=bug
CallsignLookupFunctionFlow.pdf (387,621 bytes) 2018-05-10 15:45
https://development.hamradiodeluxe.com/file_download.php?file_id=391&type=bug
Notes
(0004445)
WA9PIE   
2018-03-05 23:55   
If we do this, we should probably fix the login session key thing that Fred Lloyd at QRZ had raised recently.
(0004477)
WA9PIE   
2018-03-11 22:31   
Here's another request for the same thing.
(0004888)
WA9PIE   
2018-04-25 21:49   
Here is a mock-up picture of what this would look like after the user selects QSOs in the log and pulls up the right-click menu:
(0004902)
K7ZCZ   
2018-04-26 14:18   
If we'd like to implement this feature, I think we should do some work to define how it behaves.

So far, we have a screenshot that is intended to show that we should be able to highlight multiple entries in a logbook view. (The program can already do that.)

The screenshot also shows that there's a new command in the "Lookup" tear-off menu from the context menu in the logbook listing view; that new command is named "Callsign Lookup".

That's probably not a great name, since there's already a "Callsign Lookup" command in the application (in the "Configure" tool bar button; and in the "More" tool bar button; and in the "Confure" tear-off of the "Tools" menu). The existing "Callsign Command" configures callsign lookup work.

It seems like "callsign lookup button" mentioned in the issue is the "Lookup" button on the main dialog inside the ALE, which uses the accounts and settings configured by the "Callsign Lookup" command to find details of a contact by their callsign.

We could proceed by looping over the selected items and looking them up; retrieving data from the callsign lookup sources, modifying each record with the returned data, and then writing the modified record back to the database.

Seems simple enough, but I have a few questions about the details:


  • How is progress represented to the user? A large number of look up operations can take a while, so we have to show the user progress somehow.

  • Is there a way for code to know if a record was previously looked up? If so, should this feature skip records that were previously retreived? Or does it just do the lookup operation again, overwriting was was there?

  • Is there a way for a user to know if a record was previously looked up? If I have 100 records in my logbook, do I always select them all and bulk lookup? Or do I know to select a few -- which ones?

  • That is, is there opportunity for a feature that looks up all records that haven't been looked up before? The user wouldn't even have to select them in the first place.

  • Can the user cancel? If so, how do we show them which work was completed and which wasn't?

  • How are errors handled? Do we stop at the first error? Are errors just ignored? Maybe a list is shown of the failing records; or they're left selected.

  • What can a user do about errors, anyway? Do they need to mark the record to not try again? Can't be printed or something? Say I run the bulk QRZ feature on 100 records. 98 work, 2 fail. What do I do next?



Writing a loop that performs the lookups isn't going to be too hard. Showing the results with the user and finding a good way for users to interact with the feature requires some thought and planning.
(0004903)
K7ZCZ   
2018-04-26 14:22   
assigning for feedback about design
(0004904)
WA9PIE   
2018-04-26 18:41   
(Last edited: 2018-05-06 15:44)
Answers to the questions (de WA9PIE):

So far, we have a screenshot that is intended to show that we should be able to highlight multiple entries in a logbook view. (The program can already do that.)
>>The steps were updated with a bit more detail.

The screenshot also shows that there's a new command in the "Lookup" tear-off menu from the context menu in the logbook listing view; that new command is named "Callsign Lookup".
>>That's correct.

That's probably not a great name, since there's already a "Callsign Lookup" command in the application (in the "Configure" tool bar button; and in the "More" tool bar button; and in the "Confure" tear-off of the "Tools" menu). The existing "Callsign Command" configures callsign lookup work.
>>Customers refer to this as "Callsign Lookup." I'm open to other ideas. But we'd have to change this across all of Logbook and then convince folks to learn a new way to refer to it. (For example, it's under the Tools, Configure menu. But we could call it "Lookup.")

It seems like "callsign lookup button" mentioned in the issue is the "Lookup" button on the main dialog inside the ALE, which uses the accounts and settings configured by the "Callsign Lookup" command to find details of a contact by their callsign.
>>That's correct.

We could proceed by looping over the selected items and looking them up; retrieving data from the callsign lookup sources, modifying each record with the returned data, and then writing the modified record back to the database.
>>Right. But there's a method to the way the existing "function" is supposed to work... where it fills vacant fields in a particular order. This request assumes we'll use whatever function, routine, or code that is.

Seems simple enough, but I have a few questions about the details:

How is progress represented to the user? A large number of look up operations can take a while, so we have to show the user progress somehow.
>>I'm open to suggestions here. If a user does several hundred, they may not want a status bar sitting in their way of using the software. But maybe there's some way to provide status in an existing spot on Logbook in such a way that it all happens in the background. I'm open to suggestions here.

Is there a way for code to know if a record was previously looked up? If so, should this feature skip records that were previously retrieved? Or does it just do the lookup operation again, overwriting was was there?
>>The existing logic "doesn't care" whether or not the record has been looked up before. Maybe pop up a message that says, "Lookup will replace existing location information for these QSOs" might be good enough.

Is there a way for a user to know if a record was previously looked up? If I have 100 records in my logbook, do I always select them all and bulk lookup? Or do I know to select a few -- which ones?
>>There's no way to know if a record was previously looked up (same answer as to the previous question). This function (feature) will only lookup the records that were selected by the user.

That is, is there opportunity for a feature that looks up all records that haven't been looked up before? The user wouldn't even have to select them in the first place.

Can the user cancel? If so, how do we show them which work was completed and which wasn't?
>>Sure. If there's a way to do that. That would be great.

How are errors handled? Do we stop at the first error? Are errors just ignored? Maybe a list is shown of the failing records; or they're left selected.
>>I don't think there's any error handling in this now. We could certainly give them a list of the ones that errored out because there was no lookup info for them. (Probably bad calls anyway.)

What can a user do about errors, anyway? Do they need to mark the record to not try again? Can't be printed or something? Say I run the bulk QRZ feature on 100 records. 98 work, 2 fail. What do I do next?
>>The errors would basically be "call not found" or something. It's most likely because they entered the call wrong. So giving them a list of calls that failed would give them a list to go research.

(0004906)
K7ZCZ   
2018-04-26 21:04   
Thanks for the answers. I think we need to be very crisp about how things will work before taking action; otherwise, nobody agrees that it does what was meant becuase what was meant wasn't very clear.

Making this process work in the background isn't too difficult, but the database code in the Logbook already suffers from severe concurrency issues. These issues are at the root of the DX Cluster crashing, for example. Progress visualization is straightforward; I think that a modeless dialog with a list that shows a callsign, a status, and a message should be adequate. These are sortable, and maybe there's a way to copy the list around.

I think it's important to understand if a previous lookup has been performed for two reasons. One is that it saves the user time by preventing work that's already been done from happening again. It might take two or three seconds to perform each lookup; that adds up quickly. The other concern is that information may be overwritten and changed; when a user doesn't expect that, it's a negative experience even if they had requested the update.

If we have no way to detect that a previous request has been succesful, then we can't avoid these scenarios and that doesn't seem like a very solid feature.

I don't know of code that tries to find or set fields in a particular order; I don't see mention of this in the product documentation, either. Is a description of this mechanism available? Otherwise, I'll have to take apart code and try to find it.

I'm sorry, but I don't understand the "same as previous" answer. The previous answer given was that the logic doesn't care, but logic never actually cares. I'm asking about the user, not the code, and I feel certain the user cares. If they didn't care, we wouldn't need to peform the lookups in the first place. Users don't want to spend time looking up the same information over and over again. They probably have the expectation that the software knows what has been done before; and if it doesn't, we should add that feature to support this one.

Finally, I want to know if this is the right feature. The product already has settings that work in the background to report QSOs to tracking websites. Would a feature that looks up newly added or imported QSOs be a better solution for whatever it is that customers are trying to solve?

If the problem the user is trying to solve is to fill missing information into the logbook, it seems natural that there should be a way to note which records haven't had a retreival attempt and service those without the user needing to manually find and select them.
(0004990)
WA9PIE   
2018-05-10 15:45   
While my flow-charting skills may not be sufficient, I've created a flow-chart for how I believe the existing callsign lookup function is supposed to work as-is. The purpose of this enhancement request is to enable this function to repeat itself for selected QSO records.

Good idea about using this at the time of import. That's certainly a great use-case.

But it's also needed for the folks who have existing records that are missing data... or where they failed to use the lookup at the time of import.

The feature of enabling newly added/imported records to be looked up in the background is a fine idea. However, the feedback I get from users is that they want to select a group of QSO records to invoke the lookup function for and have the fields filled.

Perhaps there should be an option to "Fill All" or "Fill Empty." Worth the conversation.
(0006582)
K7ZCZ   
2018-12-12 04:16   
At the highest level (that is, ignoring any details at all) the flowchart does show the current state of affairs in the call sign lookup feature of the ALE.

The implementation of the feature is tightly-coupled to the ALE. Making the same code work against the record currently visible in the ALE and against an arbitrary record in the logbook is doable, but is involved.
(0007209)
K7ZCZ   
2019-02-01 18:27   
Mantis 3001 seems to be tracking the work to specify how callsign lookup should work in general. Once that's avaialble, we'd need some incremental work for a batch mode version to complete this work.

The first comment in this issue cryptically mentions a "login session key thing" issue. I don't see any details about it. A separate Mantis issue should be opened to describe that issue in detail and track progress against testing and fixing it.
(0008106)
WA9PIE   
2019-06-16 17:20   
Agree. We should hold this until after Mantis 0003001.

I don't intend to release this as a minor enhancement. This should be enabled by QLM.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3525 [1 - Backlog] Bug major always 2019-10-29 05:16 2019-10-29 05:16
Reporter: g3ucq Platform: PC  
Assigned To: OS: Windows  
Priority: normal OS Version: 10 64 bit Home  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Panadapter
Testing: Not Started
Summary: Panadapter RBW issue
Description: The RBW menu in the Panadapter changes from Nar or Mid to Wide with no intervention by the operator
Tags:
Steps To Reproduce: Use a radio that can use the Panadapter.
Open Rig Control and the Panadapter from the RC Tools menu.
Set the rig's RBW setting to Nar and note that the RBW on the Panadapter will show Wide after a few seconds.
The signals above the waterfall are not affected.
The RBW setting on the Pandapter may also switch intermittently between Nar and Wide.
Set the rig's RBW setting to Mid and note the RBE on the Pandapter will show Wide after a few seconds
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2915 [1 - Backlog] Maintenance minor always 2018-10-11 14:19 2019-10-28 14:01
Reporter: KB3NPH Platform:  
Assigned To: PD9FER OS:  
Priority: high OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: ALE Window
Testing: Not Started
Summary: Partial and Exact buttons on ALE no longer working
Description: Ticket #454426 In the past couple releases we have had customers complaining that the "Partial" and the "Exact" buttons on the ALE are no longer providing the logbook lookups as they did in past releases.
Tags:
Steps To Reproduce: Steps to replicate.
1. Open ALE
2. Make sure you are on the "Logbook" tab above the toolbar on the lower half of the ALE screen.
3. Depress the "Exact" button on the toolbar
4. Type a callsign in the "CALL" field of the ALE.

In previous versions, when the "Exact' button was depressed prior to entering the callsign in the "call" field, after the call was fully entered HRD would automatically do the lookup in the logbook and display all the logbook QSOs with the call entered. The way it is now, in order to display all QSOs with the call entered in the Call field, you have to enter the full call then you have to hit the "FIND" button located to the right of the "Call" field in order for the QSOs with the call entered to be displayed in the lower window of the ALE.

In previous versions, if you depressed the "Partial" button as you entered each character in the "Call" field of the ALE, all QSOs beginning with the characters added to the Call field would be displayed in the lower part of the ALE. Example, if the first character entered in the Call field was a "K", all QSOs with callsigns beginning with "K" would be displayed, if you added a "2" to the Call field, all contacts with "K2" would be displayed and so on until the full callsign was entered and only the contacts with that full callsign would be displayed.

I certainly hope this procedure to replicate the problem isn't to complex to understand. It's really quite simple to reproduce just by following the above instructions.


It's the same way if you depress the "Partial" button. If you
Additional Information:
Attached Files: A.jpg (41,670 bytes) 2018-10-29 07:00
https://development.hamradiodeluxe.com/file_download.php?file_id=576&type=bug
B.jpg (150,526 bytes) 2018-10-29 07:00
https://development.hamradiodeluxe.com/file_download.php?file_id=577&type=bug
Notes
(0006348)
KB3NPH   
2018-10-26 09:15   
This has also been reported in Mantis ID 0002924. This issue also appears to be related to an issue reported in OSTicket #901202 and is affecting the Lookup Pane in Logbook in HRD version 6.4.0.893. There is too much detail and too many screenshots in the OSTicket to post into this Mantis report, but if the developer who is handling this issue will check in OSTicket #901202 the steps to replicate along with other information will be obvious that the Partial and Exact buttons in the ALE should NOT affect the lookups done from the Lookup Pane in the logbook. This issue is causing a lot of confusion and complaints from clients.
(0006353)
PD9FER   
2018-10-29 07:00   
Ticket #901392
Also strange behavior in the Lookup pane
For example I took GS3PYE/P which is a confirmed QSO (LoTW) see A.jpg
Now entering the call in the Lookup pane, no data is shown... See B.jpg
(0006770)
g3ucq   
2018-12-21 05:59   
Having to press the Lookup button in the ALE is not mentioned above.
With Lookup pressed and highlighted the Option is working for me.
(0008231)
PD9FER   
2019-07-14 09:56   
It has to do with the /P
QRZ will redirect to the normal call, and ignoring it as worked.
(0008232)
K7ZCZ   
2019-07-14 11:41   
Ferry, please open a separate Mantis issue for your concerns about the lookup pane. The Lookup pane is not at all related to this issue, and it will be easier to document and track the issues separately in Mantis.
(0008311)
PD9FER   
2019-08-01 04:15   
I Won't / can't create new Mantis issues as Long the Attachments feature is broken in Mantis.
(0009038)
k2ie   
2019-10-28 14:01   
This is still an issue an build 235. See https://forums.hamradiodeluxe.com/node/51138 for further discussion.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2983 [3 - Current Dev List] Maintenance minor always 2018-12-12 12:09 2019-10-27 21:31
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: All
Sub-Module: Various
Testing: Not Started
Summary: Maintenance: some modules suppress dangerous warnings
Description:
The HRDStation, HRDManagerService, and Setup2 solutions have, in total, more than 100 invocations of the "#pramga warning(suppress" directive to turn off warnings.

Blindly turning off warnings without using them to improve the codebase actually does more damage because these directives hide potentially dangerous code from being tagged by the compiler in each build, or in speical static-analysis builds. The directives should probably be summarily removed, and we should start over with properly addresing Code Analyzer builds. Or, they should be visited and examined to determin their viability.
Tags:
Steps To Reproduce:

1) Load the HRD Solution
2) Search the entire solution for "#pragma warning(suppres"

BUG#1) About 105 total hits, none with comments indicating a solid reason for suppressing the error.


Additional Information:
Attached Files:
Notes
(0008882)
K7ZCZ   
2019-10-20 15:30   
(Last edited: 2019-10-20 15:30)
HRDManager and HRDManagerServce have been removed from the project, which helps -- but HRDStation and Setup2 remain. They still needs to be cleaned-up



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3522 [1 - Backlog] Bug major always 2019-10-27 11:47 2019-10-27 17:11
Reporter: g3ucq Platform: PC  
Assigned To: g3ucq OS: Windows  
Priority: normal OS Version: 10 64 bit Home  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: DM780
Sub-Module: Data
Testing: Not Started
Summary: Data Controller cause DM780 to close
Description: Clicking on the Data Controller in DM780 creates a minidump file and close DM780
Tags:
Steps To Reproduce: Run DM780. It can be run in DemoMatic mode.
Click on the Data Controller tab as show in the image.
A mini dump will be created and DM780 closes.
Additional Information: This issue happens whether a radio is connected or not.
I was unable to find how the Data Controller tab is set to be viewed.
The minidump file is 91MB too large to up load.
System Description
Attached Files: DM780.JPG (36,209 bytes) 2019-10-27 11:47
https://development.hamradiodeluxe.com/file_download.php?file_id=798&type=bug
Notes
(0009030)
K7ZCZ   
2019-10-27 12:40   
Please provide the minidump file.
(0009031)
g3ucq   
2019-10-27 12:49   
The file is 91Mb, too large for Mantis. Can I send it to you some other way?
(0009033)
K7ZCZ   
2019-10-27 13:51   
You should contact WA9PIE and work out how to upload the file to Mantis. Sounds like the file limit was reduced for some reason. Also, consider compressing the file using a smaller minidump size setting.
(0009034)
g3ucq   
2019-10-27 17:11   
Not long ago it was possible to upload large files.
Why is that still not possible.?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3518 [Issues Needing Retest] Enhancement major always 2019-10-26 09:50 2019-10-26 09:50
Reporter: n4fn Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Label
Testing: Beta Failed
Summary: Label issue
Description: The font size is fixed and very small when printed.
Several releases before allowed the font and size to be adjusted so as to fill a label on the Dymo Label writer 450 and I suspect also the Brother??
I have the Dymo. It was removed for what ever reason and needs to be installed back.
I hear from users in the Atlanta area that had used the Dymo before and are not happy.
Neil N4FN
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3431 [3 - Current Dev List] Bug minor have not tried 2019-08-13 10:24 2019-10-25 12:21
Reporter: KB3NPH Platform:  
Assigned To: JOSE OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 6.6.0.237  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version: 6.7.0.226  
    Target Version:  
Module: Rotator
Sub-Module: Rotators
Testing: Not Started
Summary: Fox Delta Rotator Controller Support
Description: Customer in Ticket #168924 has a Yaesu G-5500 rotor and a Fox Delta controller which emulates the Yaesu GS-232B controller. The Yaesu products support 450 degree rotation meaning when using OEM Yaesu rotor and controller, the rotor is capable of rotating past the normal 360 degree limits.

According to the Fox Delta manual, the controller is supposed to allow the 450 degree rotation when using the GS-232B emulation. Unfortunately the customer can only get 360 degree rotation and can not get the additional 90 degree over run.

Do we have a bug in our GS-232B code or is this a limitation with the emulated GS-232B firmware in the Fox Delta controller?

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0008403)
JOSE   
2019-08-14 00:19   
Change range from 0-360 to 0-450 in the code. It will need to be tested for correct behavior
(0008471)
KB3NPH   
2019-08-30 09:56   
The fix for this issue did NOT work. Sent the beta release to the customer for testing and he reported the rotor still will only travel 360 degrees. It will Not move to the 450 degree position.
(0008472)
JOSE   
2019-08-30 10:23   
Can you find out how the customer is trying to move to 450. From the Rotor gauge only 0 to 360 is allowed.
(0008505)
KB3NPH   
2019-09-03 11:31   
Jose, are you talking the gauge on the rotator GUI will only go from 0 to 360 and will not indicate any over-run? The customer is using this for satellite tracking. There are times, for example, when the satellite is passing, west to east and is low on the northern horizon. The 450 degree over run, allows you to pick up the satellite, say at 270 degrees. The satellite is tracking west to east, but low on the northern horizon. Normally if the rotator is set with a north stop, the satellite would be tracked from 280 to 359 degrees, then to continue tracking the beam would have to swing back the other way to the 001 degree to pick up the satellite past north (360 degree) and on to it's LOS at say 090 degrees. Being able to have continuous tracking from 270 to 360, then over run the stop so it can track to the 450 degrees. I hope you understand what I am trying to explain.
(0008506)
JOSE   
2019-09-03 11:41   
Yes as far as I know the gauge on the rotator only shows 0 to 360 and doesn't indicate any over-run. But the limits have been extended so the rotator code would accept upto 450 degrees. Depending on the rotator I see different limits. But I don't know how the satellite tracking handles it. In the LogFile you should be able to see what is the actual location of the rotator.
(0009018)
KB3NPH   
2019-10-25 12:09   
Jose, I can understand the gauge only indicating 0 to 360 and that it will not indicate the over-run, but do you have any possible idea why his "Fox Delta" controller that emulates the GS-232B az/el rotor controller will not allow the overrun to 450 degrees when the PST ROTATOR software works perfectly with his Fox Delta emulating the GS-232B as/el controller. I really need to be able to give Randy an answer about this.
(0009019)
JOSE   
2019-10-25 12:21   
I don’t understand what you expect to see. Like I said the controller has now 0-450 limits so any limitations don’t come from from the rotator software so I am at a loss as to what you are looking for.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3142 [4 - Business Priorities] Enhancement minor have not tried 2019-01-31 00:15 2019-10-25 03:33
Reporter: WA9PIE Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Data
Testing: Not Started
Summary: Logbook does not offer a list of satellites; this causes problems with LOTW upload (and probably awards)
Description: A satellite operator informed me that they use another logging program because HRD Logbook does not use the supported lists of satellites that makes it compatible with LOTW. I'm gathering information and sources about this.

But it seems to me that the "Ant/Sat" tab in the ALE needs to have a pre-built standard list of satellites that the operator can choose from... or we populate it from whatever information we get from HRD Satellite Tracking.

Some resources:

https://www.amsat.org/logging-satellite-qsos-with-logbook-of-the-world/
https://lotw.arrl.org/lotw-help/frequently-asked-questions/#sats

https://lotw.arrl.org/lotw-help/submitting-qsos/
"If the QSO was made via a satellite, its propagation mode must be set to SAT, and it must specify the name of the satellite used."
https://lotw.arrl.org/lotw-help/satellite-qsos/
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Satellite tab.png (53,458 bytes) 2019-01-31 23:58
https://development.hamradiodeluxe.com/file_download.php?file_id=674&type=bug
Satellite tab (2).png (81,269 bytes) 2019-02-08 11:44
https://development.hamradiodeluxe.com/file_download.php?file_id=684&type=bug
SatelliteMode.xlsx (10,464 bytes) 2019-02-13 00:40
https://development.hamradiodeluxe.com/file_download.php?file_id=687&type=bug
Notes
(0007189)
WA9PIE   
2019-01-31 23:58   
(Last edited: 2019-02-01 00:04)
Based on the data found on the ARRL's website that describes the requirements for satellite QSOs uploaded into LOTW, the following two fields are required in the ADIF export (example, based on included mock-up image):

Satellite Name: <SAT_NAME:4>AO-10
Propagation Mode: <PROP_MODE:3>SAT

The reasons for pointing this out is are as follows:

The SAT_NAME must match the list enumerated at https://lotw.arrl.org/lotw-help/frequently-asked-questions/#sats
Any time the SAT_NAME is filled with one of these enumerated values, the PROP_MODE must automatically be changed to "SAT".

I have tested the ADIF export and - with valid data properly entered into these two fields, the ADIF file is correct. No need to do work on it.

The purpose of this is to provide the correct list of enumerated satellites in a dropdown list for ease of use and LOTW compatibility.

(0007295)
K7ZCZ   
2019-02-06 14:44   
Looks like this will need at least a little design work. Here are my questions so far:


  • The product currently has "mode" field here; there are instructions to remove it. What becomes of the data that customers have stored in this field? It never sees the light of day again?


  • The screen shot is annotated with text thats says "whenever Satellite ID is filled with one of these values, Propagation Mode MUST be "Satellite"". What does this specifically mean for the UI? Maybe the Prop mode drop-down is set to "Satellite" and disabled when a satellite is chosen; and when "Satellite" is chosen as a prop mode, the form won't save if a specific Satellite name isn't chosen. Or, maybe some other design is desired.


  • The ADIF specification doesn't seem to say that SAT_MODE is an enumeration; it's just a string. What is meant to be stored there? The existing propagation field in the product is wired to the ADIF "PROP_MODE" field, which is an enumeration.


  • The current product shows an editable Name field, and I expect customers already have data in this field. In the screen shot, the "name" text appears to be static and not editable. Is that the intended design? That would mean customers can't ever edit the names they've previous input.


  • What becomes of existing customer data in the name field, then? Is it matched to an ADIF satellite name? If a match is found, is ID populated automatically? What if the name is not a match?


  • The nomenclature seems like it might be off. ADIF specifies a SAT_NAME field. The advice in this issue is that the satellite ID is exported in the SAT_NAME field, not the satellite name. Is that intentional?


(0007302)
WA9PIE   
2019-02-07 03:19   
I sometimes jump from problem straight to solution without the explanation.

A user wrote me to indicate the following:

"It’s been a long long time since I last tried to use HRD for satellite operation and logging. It sounds like others are steering you in the right direction. Of course Doppler tuning management is essential as is accurate rotor control. I seem to recall both has been problematic but I also remember another objection was about logging. Some of us changed to using Log4OM as it accurately logs satellite QSOs with the proper information. Maybe you can take a look at that and get some ideas, maybe that shortcoming has been solved. I hope you get there as I’ve gone back recent,y to using HRD and really like it. Id like nothing better than to do all my logging including satellite QSOs and everything else using HRD."

Furthering the dialog with him to find out, "Why doesn't HRD accurately log satellite QSOs?" I started digging into this.

It turns out, there are several problems. But for this item, I'll stick to the point.

First thing I had to conclude is that there's very little value in assuming that the way HRD does something is the correct way to do it. So what is that "mode" field in the Satellite tab? Well, SAT_MODE is listed in the ADIF spec. But there's no useful information about it at all. Further - if you look at what LOTW is expecting, there's no mention of SAT_MODE. So I conclude that it is of no use whatsoever.

Per https://lotw.arrl.org/lotw-help/satellite-qsos/ we can see that PROP_MODE is what's required (along with SAT_NAME). PROP_MODE is listed under the Propagation tab... and when a SAT_NAME is listed, then the PROP_MODE 'MUST' be "SAT" every single time. Otherwise, LOTW won't accept the QSO.

Further, allowing users to type a satellite ID into to a text box is not working. As mentioned in the ARRL documentation, the ID must be exact. So it would be AO-7... and not AO7 or AO-07 or anything else. It must be AO-7.

The fact that we've allowed people to type text into this box... and we don't populate PROP_MODE automatically when a satellite is selected in the Satellite tab is the basis for many errors. It's something we need to fix.

Given that the SAT_MODE field isn't used for anything, I doubt that anyone will miss it. Leaving it seems confusing... given that the ARRL doesn't use it.

So... it seems like a failed attempt to satisfy the LOTW requirements for PROP_MODE, but it put SAT_MODE there instead.

If we leave SAT_MODE there, it's confusing and useless. I'm advocating we hide it. But I could be talked out of it. It just leads the user to a confusing end. I suppose we could duplicate the PROP_MODE here (as we do with Locator in other situations). I'd just hide the field and leave the data. It's meaningless.

If a satellite is selected from the list (which is not enumerated by the ADIF standards... but it is enumerated by the ARRL in the provided links), then the PROP_MODE must equal SAT. The PROP_MODE is blank, by default and should remain that way. The data in the satellite ID field (and the corresponding sat name) can still be a string field. We just need to give them a pre-populated list that match what LOTW is looking for. Conceptually, this is no different from IOTA (which is also not enumerated in the ADIF standard... enumerated elsewhere... and we use that source of truth for the list of IOTAs).

If customers already have data in these fields, leave the data. If they want to update the records, they can come back and edit the records later from the enumerated list we provide.

If the user selects a satellite ID, we should populate the name.

But there are no cases where I can see us going back into someone's log and attempting to correct the mess created by the incorrect initial implementation of this. I'll leave it to the release notes and/or newsletter to explain that.

Finally, as you point out... the ADIF standards don't match what the ARRL references are. I'm not going to spend a lot of time being shocked by this. But the ARRL specifies a list of IDs... and Names. The ID exports as SAT_NAME... while the name field is not used by LOTW. Because the ADIF standard doesn't match the LOTW's enumeration, my recommended approach solves this problem. The satellite is correctly referred to by it's "ID". We correctly export that to SAT_NAME. No changes are needed with regards to exporting data. It's already fine. I verified that earlier. Yes, it was intentional... and necessary in order to address the inconsistency between the ADIF standard and the ARRL's enumeration.
(0007306)
K7ZCZ   
2019-02-07 11:07   
Here's what I've got so far:


  • We need to remove the existing "Sat Mode" and "Sat Name" fields from the UI.

  • To protect customer data, the COL_SAT_MODE and COL_SAT_NAME fields stay in the database. But customers lose the ability to edit or view these fields with any part of the application. The fields are removed from the product: the logbook database view doesn't show them anymore, not visible in filters, and so on.

  • If the Satellite ID field is set on the Ant/Sat tab, the Propagation mode field on the Propagation tab is set to "Satellite".

  • If the Propagation mode field on the Propagation tab is set to anything but "Satellite", the Satellite ID field on the Satellite tab is cleared.

  • The "name" field in the new Satellite group-box in the Ant/Sat tab is not editable.

  • The database gets a new field called COL_SAT_ID. The only valid values are from the ID column of the ARRL list of satellites.

  • At ADIF import, <SAT_NAME> is set to COL_SAT_ID.

  • At ADIF export, COL_SAT_ID populates <SAT_NAME>. COL_SAT_MODE and COL_SAT_NAME are ignored.



Does that look right? Anything missing?
(0007307)
WA9PIE   
2019-02-07 14:30   
We need to remove the existing "Sat Mode" and "Sat Name" fields from the UI.

[No. We need to keep them both. (I'm reversing my position on the "Mode" thing. I'll get to that in a moment.) We're changing the Sat Name field from a free-form text field to a dropdown list of satellite IDs from the ARRL's list. We'll relabel the "Mode" field to "Sat Mode" and leave it. It's going to cause confusion without a change that I'll answer further down.]

To protect customer data, the COL_SAT_MODE and COL_SAT_NAME fields stay in the database. But customers lose the ability to edit or view these fields with any part of the application. The fields are removed from the product: the logbook database view doesn't show them anymore, not visible in filters, and so on.

[No. We're not removing any fields from the product. We're changing how they get filled... and we're adding one field that doesn't have a corresponding ADIF tag. Let me try this:

Satellite Name field (COL_SAT_NAME) in the UI gets a label change to "ID". Henceforth, it will be populated from a dropdown list provided by the ARRL under "ID". For ADIF import/export, this is <SAT_NAME>. (Unfortunately, it's not the name, it's the ID. So we'll need to create a column for the satellite name as shown under "Name" in the ARRL's list.) Whatever data customers already have there should remain in-tact and displayed if they go back to reveiw the record. But it's no longer a free-form text field. They have to select one from the dropdown list. (This is actually the current behavior for Country when the user doesn't allow HRD to update the Country name on import. That is - it retains its old value until someone updates it.

Mode field in the "Ant/Sat" tab remains, but with a label change. Let's call it "SAT Mode" in the UI. No changes needed for ADIF import/export. It's a completely useless field and it's going to confuse people, unless we go after this next item.]

If the Satellite ID field is set on the Ant/Sat tab, the Propagation mode field on the Propagation tab is set to "Satellite".

[Correct. Otherwise, folks are going to think that the SAT_MODE field is where PROP_MODE is set and they won't get it set. Then their LOTW uploads won't properly get registered as satellite QSOs.]

If the Propagation mode field on the Propagation tab is set to anything but "Satellite", the Satellite ID field on the Satellite tab is cleared.

[I don't think we're changing anything about the initial population of the PROP_MODE. I would state it this way - the ID dropdown being populated is what changes the PROP_MODE field from empty to Satellite. If someone changes it from empty to Satellite without having a satellite selected in the Ant/Sat ID field, that's fine. But there aren't any changes we need to make about this. But no, I don't want to clear the items in the Satellite ID field if someone changes data in the PROP_MODE field from Satellite to something else. They'll just figure out that they need to change it to Satellite if they want it to be recognized in LOTW and other systems.]

The "name" field in the new Satellite group-box in the Ant/Sat tab is not editable.

[Correct. There's no need for users to edit this because it's already defined by the ARRL and every satellite "ID" has a name. Allowing users to edit that makes no sense.]

The database gets a new field called COL_SAT_ID. The only valid values are from the ID column of the ARRL list of satellites.

[I wouldn't do it that way. It seems like too much trouble and it screws with people who have already put data there. I mentioned some of this above, but what I would recommend is this:

ID in the UI = COL_SAT_NAME = <SAT_NAME> for ADIF import/export
Name in the UI = new column in the database; maybe COL_SAT_FULLNAME = <app_hamradiodeluxe_sat_fullname>
COL_SAT_MODE = Sat Mode in the UI = <SAT_MODE> for ADIF import/export

At ADIF import, <SAT_NAME> is set to COL_SAT_ID.

[See above]

At ADIF export, COL_SAT_ID populates <SAT_NAME>. COL_SAT_MODE and COL_SAT_NAME are ignored.
[No. See above.]
(0007312)
K7ZCZ   
2019-02-07 19:51   
If we're keeping both the "Sat Mode" and "Sat Name" fields, then we should provide an accurate mock-up to reduce confusion and facilitate a common view of the intended design. The image above has removed both of the fields.

If we keep the existing COL_SAT_MODE and COL_SAT_NAME fields, but change how they get filled from a free-entry edit field to a drop-down list, then we're obliged to find a way to handle data that exists in the database for those fields, but doesn't exist in the list of valid choices in the drop-down. Otherwise, the existing data can't be shown to the user.

To be precise, it's not possible to implement this as described:

 > Whatever data customers already have there should remain in-tact and displayed if they go back to reveiw the record. But it's no longer a free-form text field. They have to select one from the dropdown list.
 
Or, at least, not possible to implement it as I understand it.

At this time, the COL_SAT_NAME field has an unconstrained domain: anything (including nothing) could be entered in that field. Using a drop-down list enforces a domain. Maybe nothing is in the field, and that's fine. But if something is in the field, it must be a value that's from the pre-populatd drop-down list.

Anything the user might have in the field in a pre-existing record which isn't in the set of values in the drop-down can't be displayed to the uesr.

How do we best handle existing data?

 > They'll just figure out that they need to change it to Satellite if they want it to be recognized in LOTW and other systems.
 
I want to understand how they'll "figure it out". If I understand the process by which users learn that, and why it's prefereable to actively enforcing the edit rules in the product, I might be able to better understand the intended design.
(0007325)
WA9PIE   
2019-02-08 11:44   
I've updated the mockup. I'm not suggesting we remove any fields. Hopefully the new mockup makes it clear.

As for this...
"If we keep the existing COL_SAT_MODE and COL_SAT_NAME fields, but change how they get filled from a free-entry edit field to a drop-down list, then we're obliged to find a way to handle data that exists in the database for those fields, but doesn't exist in the list of valid choices in the drop-down. Otherwise, the existing data can't be shown to the user."
[I have found in the past with changes like this that the user will still see the data that was previously put there. They can change it to one of the values from the dropdown list. I'd suggest that we build it and see if this is true (and I believe that it is). There are other examples of this. If you import an ADIF where the Country name is "Nowhere"... then the import process will absolutely import "Nowhere" and place it into the Country field. The user can see it in that record. They can change it to any value in the dropdown. We see this a lot when folks are importing from other programs that do not follow the naming standard for Countries, IOTAs... etc. Let's try it and find out.

As for this...
 > They'll just figure out that they need to change it to Satellite if they want it to be recognized in LOTW and other systems.
 
"I want to understand how they'll "figure it out". If I understand the process by which users learn that, and why it's preferable to actively enforcing the edit rules in the product, I might be able to better understand the intended design."

[So. We agree that when the user changes the value in the ID field (which is really COL_SAT_NAME = <SAT_NAME> with a new label), then we can automatically set PROP_MODE to Satellite (SAT). That's good.

The default value for COL_PROP_MODE is empty.

So help me understand how this would work...

If they populate a Satellite name in the ID field in the UI... this sets the PROP_MODE to Satellite (SAT). But if they go back to the Propagation tab and change PROP_MODE to something that makes no sense for a satellite QSO (like Tropospheric Ducting)... then we're going to do what?

Are we going to popup something that says, "You've got a satellite entered in the ID field in the Ant/Sat tab. This requires PROP_MODE = Satellite (SAT)" and prevent them from changing it?

Are we going to allow them to change it, but then go and clear the contents of ID (and thus, name) on the Ant/Sat... because something other than PROP_MODE = SAT is an invalid combination?
(0007327)
K7ZCZ   
2019-02-08 12:58   
> There are other examples of this. If you import an ADIF where the Country name is "Nowhere"... then the import process will absolutely import "Nowhere" and place it into the Country field. The user can see it in that record. They can change it to any value in the dropdown.

This approach seems to be at conflict with the previously asserted goal of "The SAT_NAME must match the list enumerated at arrl.org".

If, instead, we want to implement a control that encourages (but doesn't enforce) the user to use one of those pre-defined values, lets them keep existing arbitrary values (not in the enumeration), and no longer allows free-form editing, we can do that. But we should re-state that goal so that it's consistent with the approach we're actually taking.

The resulting control isn't quite the simple drop-down list that was previously discussed. It's an awkward use of the control, and a bit more cumbersome to implement when compared to a generic drop-down list. But it can be done.

I think a fundamental goal of a database application is to help the user enter correct data. That goal includes rejecting bad data as well as helping the user find and repair bad data.

While the suggested approach would have new data entered come from the limited list, it doesn't help with finding or repairing existing data in this column that no longer fits the newly defined domain for the column.

What are the longer-term results of such a decision? Seems like we'll never be able to reliably use this data in any consistent way because the data itself is inconsistent.

Is that limitation adequate for our needs? Are there other resulting limitations which we should evaluate?
(0007332)
WA9PIE   
2019-02-08 17:59   
"This approach seems to be at conflict with the previously asserted goal of "The SAT_NAME must match the list enumerated at arrl.org"."

I don't think that's the case. I've been consistent here.

1) In the first row, we need to relabel the field from "Name" to ID. It needs a dropdown to limit the choices to the list of satellite "IDs" provided by the ARRL. Users would only have no option to put a satellite in there that is not accepted by LOTW (which prevents people from putting data in their log that doesn't match the accepted values). The field name remains COL_SAT_NAME. The ADIF import/export is <sat_name>. (Yeah, it's a bummer that - way back when this useless feature was added, that someone referred to the ID as Name. But we're not removing any fields. We're changing labels in the UI.)

2) In the second row, we need to display the corresponding satellite "name" from the ARRL list for the user selected "ID". For example, when ID=AO-10, then the "Name" displayed is "AMSAT-OSCAR 10". This can't be changed independent of the ID... because there is no other name for AO-10 than "AMSAT-OSCAR 10". Create a new field to save this in. There is no equivalent ADIF value for this.

3) In the third row, we're leaving the existing "Mode" field and relabeling it to "Sat Mode". This is COL_SAT_MODE. ADIF import/export is <sat_mode>.

4) Whenever someone populates the ID field with a satellite from the list, the PROP MODE should change to "Satellite". ADIF import/export is <prop_mode>.

5) I don't see any point in trying to parse the existing data in COL_SAT_NAME to figure out whether or not "AO10" or "AMSAT-OSCAR 10" should be changed to "AO-10".

6) I don't know of any other limitations to this approach. The existing approach is completely useless (this coming from folks other than me). I'm not too worried about the ramifications of taking something doesn't work and changing it to something that does work. AMSAT users gave me examples of two other logging programs that do exactly the same thing. It seems that sat operators expect this.
(0007335)
K7ZCZ   
2019-02-08 19:29   
Let's say a customer has an existing database with some QSOs. Any version of the product previous to this change allows any input (at all) into the COL_SAT_NAME database field. Perhaps a user has these rows, with the corrsponding COL_SAT_NAME values:

Row 1:  "AO-92"						// happy case, it matches a known satellite
Row 2:  "AO92"						// doesn't match. Close, but not exact.
Row 3:  "Fooey"						// not even close
Row 4:  ""							// empty, no entry
Row 5:  "AMSAT-OSCAR 92 (Fox-1D)"	// the name (that's what we asked for!) not the ID


Only one of these (Row #1) matches the ARRL list. I guess Row #4 is okay, too, since not claiming a satellite contact is fine, so an empty field is allowed.

The rest of the rows don't contain a value that matches the ARRL ID list.

Your #5 says we don't see any point in trying to match values.

Since we're using a drop-down list to display these values, we must populate the list part of the drop-down with the ARRL list, then load the record from the database. If the COL_SAT_NAME field has a mathch, we're fine. If it's not a match, it must be added to the drop-down list and only then can it be selected and displayed. This is pretty cumbersome, and not what users really expect of such a control.

We can't treat all of the COL_SAT_NAME values in this database valid ARRL satellite IDs; they're not. If we try to send these to LOTW, we can't guarantee that we're sticking to the LOTW requirements because we've allowed data incompatible with the ARRL requirements to remain in the field. The domain of the COL_SAT_NAME is all strings, not all strings that match the ARRL ID list.

How can we reconcile the presence of rows 2, 3, and 5 with the rule that values in COL_SAT_NAME must be a member of the ARRL ID list?
(0007336)
K7ZCZ   
2019-02-08 20:10   
I recommend a more prudent approach. Using a new column enables the establishment of a tight constraint and ensures all values in the field are valid. It partitions old rows (before this change) away from new rows (entered after this change). Additionally, the columns get meaningful names -- we're not making excuses and instead fixing the problem actively. And instead of creating technical debit with fudged names and overloaded values.

Data integrity is a key tenent of good database application design. It's difficult for me to abide a design which actively avoids the opportunity to make improve data integrity. Indeed, other parts of this product do that. But I think those are defecits, not features which should be emulated or patterns to be replicated.
(0007337)
WA9PIE   
2019-02-08 21:01   
Using a new column basically loses the user's ability to see the data they entered previously... and it seems virtually impossible to parse and correct data that's already there.

What will happen after these new columns are parsed? Do users have access to them in the UI?

I don't see how we can come to the conclusion that the fact that users have entered useless data in their database... already uploaded it to LOTW... wrong data... is of any vale at this point. This doesn't change the fact that the user would have to find old QSO records... correct them... and upload them to LOTW again.

I'm opposed to adding items to the dropdown list that are not valid for LOTW credit.

What do we do now?
(0007338)
K7ZCZ   
2019-02-09 09:32   
> loses the user's ability to see the data they entered previously

We can still display it, read-only. Maybe let it be copied if it's valid, maybe make a "guess" button. We can investigate solutions and figure out what we want.

 > What do we do now?

Right now, there's no validation at all. (Really, that's true for many of the fields -- there are few field validations, and almost no cross-field validations.) COL_SAT_MODE and COL_SAT_NAME are both 32 characters, and that's that: no checking against any reference lists, no looking for valid or invalid characters or formats or patterns, nothing. So the domain of each column is any string.

 > This doesn't change the fact that the user would have to find old QSO records... correct them... and upload them to LOTW again.

I don't know how this fact was established. Maybe you're thinking of a use case with which I'm not familiar?

 > I don't see how we can come to the conclusion that the fact that users have entered useless data in their database

I don't think we have the conclusion that the data in the COL_SAT_NAME column is useless. We don't know that it is useful, though. We don't know if it's useful or not because the data is not validated by the application when it is added to the database. Anything can show up in there.

The shortcoming of the Logbook which I presume this Mantis issue is meant to address is that the Logbook isn't helping. If it validated entered data to be correct, it would add some value to the process.

Seems like there's a pattern in which the COL_SAT_NAME data gets validated by users indirectly, though. They enter or load some data into this field, then try to upload to their favorite logging site -- LOTW, maybe. Records with bad data are rejected, so they adjust them. Through trial-and-error, they discover that COL_SAT_NAME needs to be an ARRL-specified ID, and they fix up their data to match. Once they learn that lesson, going forward they always remember to use the ARRL-specified ID.

If this supposition is true, then I think we can build a new column populated from the old one. Let's try this proposal as straw man:


  • We add COL_SAT_ARRL_ID to the database.

  • New databases are created with COL_SAT_ARRL_ID.

  • Existing databases are migrated by adding the COL_SAT_ARRL_ID column. COL_SAT_ARRL_ID is initially populated by examining each row's COL_SAT_NAME field. If the COL_SAT_NAME field is a valid ID from the ARRL list, its value is moved to COL_SAT_ARRL_ID and COL_SAT_NAME is cleared. Otherwise, no change is made to the record.

  • In the application, COL_SAT_ARRL_ID is populated from a drop-down, strictly. No extra entries, no fudging the list to include extra maybe-valid values. COL_SAT_NAME remains and is editable.

  • COL_SAT_NAME is editable as a text field, no constraints. Maybe we add a button that looks up the name from the matching ARRL ID. But since this field isn't used for reporting to LOTW, that's fine.

  • At ADIF export: COL_SAT_NAME is ignored. COL_SAT_ARRL_ID is set to <SAT_NAME>. COL_SAT_MODE is set to <SAT_MODE>.

  • At ADIF import: <SAT_MODE> populates COL_SAT_MODE. <SAT_NAME> populates COL_SAT_ARRL_ID or COL_SAT_NAME using the same rule as the migration does.



Maybe we pick different names, whatever sounds good.

For ADIF import and export, maybe we need to consider using app-specific fields. We'd have to reason that through. If people use ADIF as a way to backup their HRD database (not XML?) them it's a strong reason to do so with full fidelity over round-trips.

If our belief that COL_SAT_NAME usually is a correct ARRL satellite ID, then this works out very well. Correct data is move to a column where we know all rows, all the time, have a correct Sattelite ID. And the user keeps (and can see, and can edit) the invalid data they might have lying about in the existing COL_SAT_NAME field.

We end up with almost the same UI as the "satellite tab (2)" picture. ID is strictly a drop-down, no funny business. Name is editable (not editable in the picture), and Sat Mode is remains.

I prefer this because it advances the product forward. We add a pick list for satellite names. But we also help improve data quality because we build a column that we know always contains valid satellite IDs for each row.
(0007356)
WA9PIE   
2019-02-11 21:29   
Good conversation. We came to agreement. Reassigning back.
(0007360)
K7ZCZ   
2019-02-12 20:05   
We did make progress, but there werew a couple of items unresolved:

1) Do we show the old COL_SAT_NAMe column? Where, and how do we name it? There was a concern with it being "confusing", but no specific example of how we might remedy the anticipated problem.

2) How is the new colum named? I proposed COL_ARRL_SAT_ID.

3) There was discussion about moving fields, so it's not clear if we're keeping COL_SAT_MODE or moving it, or what we do with the existing data in that field.
(0007367)
WA9PIE   
2019-02-13 00:40   
1) I suggest we put something that looks like a hyperlink at the bottom of the Satellite tab that says, "Access to Legacy Satellite Fields" and then bring up a dialog box to enable folks to see these old fields. (I'll probably do a YouTube video for this because the whole thing - as a topic - is pretty expansive in concept.

2) Agreed (thought we did agree to this one).

3) We're keeping COL_SAT_MODE. But I will want to restrict it also. I've got a spreadsheet with guidance about this (attached).

So...

In the new UI... we've got:
- the new COL_ARRL_SAT_ID... which is simply labeled "ID" in the tab/dialog box... adif import/export as <sat_name>. The contents of the field limited to the enumerated ARRL list
- we're displaying the corresponding ARRL Sat "Name" for that ID
- the "Mode" field should probably be labeled "Sat Mode". I'd like to populate Sat Mode automatically, based on the new standards for this as attached.

...then we have this hyperlink looking thing at the bottom as mentioned above

Good?
(0007387)
K7ZCZ   
2019-02-13 21:09   
1) okay

2) I proposed the idea, but there was never explicit agreement.

3) Actually, there was talk of putting Propagation and Satellite ID on a new tab. What you had said was this:

Propagation and Satellite seem to have more in-common than Antenna and Satellite.  Maybe we should leave Antenna on it's own... and combine the Propagation and Satellite to a common tab so the use of PROP_MODE is clearer to the user?


and that's what I'm asking after. I don't see that issue answered in our chat, and it's not answered here, so I don't know what the desired design is. My understanding is that you were considering moving the Satellite fields to the "Propagation" tab.

The spreadsheet and "restriction" of COL_SAT_MODE is something completely new in the conversation and we should talk it over to resolution. It seems like we're really in the same boat as COL_SAT_NAME here because COL_SAT_MODE is a free-from string. There's no validation, existing data can be anything at all.

The spreadsheet seems to be saying that COL_SAT_MODE should be computed based on the uplink and downlink bands. Totally possible, but what do we do with previously stored values in COL_SAT_MODE?

And where do we find the bands? I don't think we store TX and RX frequencies separately in the logbook. There is provision to do so, but we don't actually show the edit control in the ALE. Since we don't have the separate frequencies, how are the necessary bands derived?
(0007524)
WA9PIE   
2019-02-27 11:17   
After reading further dialog on the AMSAT email reflector this came up:

https://lotw.arrl.org/lotw-help/configxml/?lang=en

They say that the list of satellites on the ARRL's web page is not always current. But they say that this file that TQSL pulls down is constantly updated for the list of satellites.

Question - should we be using this same file, obtained from its source, to build the list referenced in this change?
(0007891)
WA9PIE   
2019-04-25 19:31   
I finally got around to uploading my satellite QSOs to LOTW. Even after all my research into this, I still managed to manually enter my required information into our fields incorrectly. This confirms that this problem is real. A drop-down list is needed.

I found that the TQSL program has an updated list of satellites we could use. It's contained within: C:\Program Files (x86)\TrustedQSL\config.xml


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3515 [1 - Backlog] Bug major always 2019-10-23 05:41 2019-10-23 05:41
Reporter: g3ucq Platform: PC  
Assigned To: OS: Windows  
Priority: high OS Version: 10 64 bit Home  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Panadapter
Testing: Not Started
Summary: The Panadapter display and operation is erratic
Description: The Panadapter display and operation is erratic
Tags:
Steps To Reproduce: Open Rig Control with a radio connected that can use the Panadapter.
I use the ICOM 7610.
Open the Panadapter (Main) from Rig Control/Tools.
Notice that the behavior of the waterfall and operation of the menus is erratic.
Additional Information: I made a screen capture video but it is too large to upload here.
System Description
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3511 [3 - Current Dev List] General major always 2019-10-22 20:05 2019-10-23 04:01
Reporter: WA9PIE Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Call lookup
Testing: Not Started
Summary: Callsign Lookup dialog box has confusing UI
Description: In the 6.7.0.235 beta build, the Callsign Lookup dialog box contains a list of things that are meant to be re-ordered with things that are not meant to be re-ordered (meanwhile, I was able to move things that were not meant to be moved). I think this will confuse customers.

The purpose of this change request is to suggest a change in the UI that is intended to provide better clarity for the users about how the dialog box and feature works.

We also need to add Up/Down buttons to the right of the "Enabled Methods" so that the user will know that they can re-order them.
Tags:
Steps To Reproduce: - Launch Logbook
- Go to Tools, Configure, Callsign Lookup... Enable tab
- Observe how this could be confusing
Additional Information:
Attached Files: CallsignLookupEnabledMethods.png (51,012 bytes) 2019-10-22 20:05
https://development.hamradiodeluxe.com/file_download.php?file_id=792&type=bug
Notes
(0008906)
K7ZCZ   
2019-10-22 23:59   
There are really three issues here: The missing up-down buttons, the ability to move items that shouldn't be moved, and the design of the UI itself.

Please open separate issues for each. Granular Mantis issues are easier to track, facilitate clear communication, testing, and documentation.
(0008907)
WA9PIE   
2019-10-23 00:47   
I have created three Mantis issues to separate out this work. I've placed them as child issues to this one.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3509 [3 - Current Dev List] Maintenance minor always 2019-10-22 09:14 2019-10-22 09:14
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Setup
Sub-Module: Install
Testing: Not Started
Summary: Should update Visual Studio redistributable package
Description: Looks like the current version of the VC Redistributable is 14.23.27820, but the 6.7 builds contain 14.15.26706, which is more than 6 months old.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3329 [3 - Current Dev List] Bug minor have not tried 2019-06-05 19:24 2019-10-21 16:31
Reporter: K7ZCZ Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Website
Sub-Module: Appearance/UI
Testing: Not Started
Summary: Download link in trial email has confusing behaviour
Description: The email sent to customers when requesting a trial key has a link to download the software. That link ends up opening the trial request form again, which is quite confusing. I expect many users won't notice that it's also downloading the software from that link.
Tags:
Steps To Reproduce: 1) Visit trial.hamradiodeluxe.com
2) Enter the data required to get an email with a trial license
3) Get back to your email application and open that email
4) click on the "click here" link to download the product
5) I end up at the form from Step #1 again
BUG#1) But also, the application surprisingly starts downloading. I think it would be better to give a clear and positive indication to the user that they're downloading the package.
Additional Information:
Attached Files:
Notes
(0008402)
WA9PIE   
2019-08-13 22:58   
(Last edited: 2019-08-13 22:59)
The link in the email is a direct link to setup.exe (https://downloads.hamradiodeluxe.com/setup.exe). I think that's the right approach for helping them download the file as it avoids sending them to a download page where they may not be clear on which file to download (though there's only one application on that page to download, some folks aren't certain whether it's for the trial or for the full version; of course there's no difference, but folks get confused about this). So suggesting we leave this as-is.

As a result, when the customer clicks on this download link, it goes back to the browser (for whatever page it was on previously) and begins the download. If the last tab open in the browser is https://trial.hamradiodeluxe.com, then yes, the behavior you've described is what will happen. But it's not because we're sending them back to the trial page. If the user had closed that tab, went to any other website in that tab, or closed the browser all-together, then it would have either gone back to the last tab viewed or opened a browser to do the download.

I tested this from Gmail opened in a browser. When I clicked on the link, it simply downloaded the file in the same tab where I was viewing Gmail. You may be using an email client (Outlook or whatever).

I do have some choices here (image attached) for the "Target frame" associated with that hyperlink. They are:
- New window
- Parent frame
- Same frame
- Whole page

I tried all these (again, reading my email from Chrome). I got the same result in all cases. That is - if a browser is open, it creates a new tab for the download, closes it, and then goes back to the previous page; current behavior. I'm not sure I can change this.

I've left it set to "New window". If this isn't sufficient, then this issue could end up in the "not fixable" category.

I'm having the system send the trial key email to K7ZCZ for evaluation.

I don't think there's any way to force the trial key page to close after making the trial key request.

(0008557)
K7ZCZ   
2019-09-16 19:43   
I don't have a copy of the email. Can it be sent again? Please let me know which address it is being sent to, so I know where to look.
(0008644)
K7ZCZ   
2019-09-24 20:37   
Dunno when or if it was sent, but I still haven't received an email.
(0008799)
WA9PIE   
2019-10-13 09:22   
If you're trying to do a trial, the email address radio@blaszczak.com has a permanent key.

We could start the whole sequence from scratch if you'd like to begin with only a trial key. I'd need to delete your permanent key associated with radio@blaszczak.com.

Let me know.
(0008802)
K7ZCZ   
2019-10-13 10:31   
Whatever works.
(0008803)
WA9PIE   
2019-10-13 10:39   
Ok. Just to start from the beginning, I deleted your permanent key.

You can go ahead and try the trial link and see what the email looks like at this point - https://trial.hamradiodeluxe.com
(0008809)
K7ZCZ   
2019-10-13 13:16   
I don't see a change in behaviour. What is expected to be different?

Here's what happens:

1) I received an email from "sales@hrdsoftwarellc.com".
2) It had a link that says ">>click here<<"
3) So, I clicked it. My browser opened to my default home page, and the file started downloading.

The experience seems a bit odd because I don't first see a page with any information about what I'm downloading; I never see an HRD-related URL in my browser. The download UI in my browser starts working, but it's kind of subtle and it's pretty easy to assume that the link just went to whatever my homepage is. Since my home page isn't related to HRD, why would I expect it to start downloading anything?

Most software I download in response to an email doesn't work this way. Instead, the email link goes to a download page at the web site of the vendor. The page explains what I'm about to download, maybe gives more information, like an hash so I can verify my download is legit and uncorrupted. Most importantly, the explicit step of downloading from the browser helps the user know that the download is starting.
(0008812)
K7ZCZ   
2019-10-13 14:34   
(Last edited: 2019-10-13 14:35)
This morning, I had to re-enter licensing information for my dev machines, including my VMs. Was it because my permanent key was deleted for this issue? Seems like we should find a mechanism for testing that's less invasive to the rest of my work.

Actually -- it's worse than that. I'm now able to run the product on one machine and none of my VMs. This leaves me completely stuck.

(0008815)
WA9PIE   
2019-10-13 16:33   
The email address you provided me was radio@blaszczak.com. That's the only one I removed so you could start the trail process from scratch.

There's absolutely nothing I can do to change the email. This ultimately ends up in the "can't fix" category. I've tried all (four) of the options and none of them result in what you're looking for.
(0008821)
K7ZCZ   
2019-10-15 09:08   
Is the URL of the link in the email not under our control?
(0008824)
WA9PIE   
2019-10-15 16:20   
I do have some choices here (image attached) for the "Target frame" associated with that hyperlink. They are:
- New window
- Parent frame
- Same frame
- Whole page

I tried all these (again, reading my email from Chrome). I got the same result in all cases. That is - if a browser is open, it creates a new tab for the download, closes it, and then goes back to the previous page; current behavior. I'm not sure I can change this.

I've left it set to "New window". If this isn't sufficient, then this issue could end up in the "not fixable" category.
(0008826)
K7ZCZ   
2019-10-15 21:07   
I'm asking about the actual URL, not the target. And the issue isn't for users reading from a browser; it's for users reading from a mail client. I'm suggesting that the URL be changed to link to a download page instead of linking to the file directly because the UX is pretty crummy in the current state. Changing the target doesn't help the experience because there's no existing browser window open; the browser might not even be running.

But if you don't want to fix it, that's fine.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3508 [1 - Backlog] Enhancement minor have not tried 2019-10-21 13:46 2019-10-21 13:46
Reporter: KB3NPH Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: DM780
Sub-Module: Functional
Testing: Not Started
Summary: Add Winlink VARA to supported modes
Description: Ticket #405587 A customer has asked that we consider support for Winlink and the VARA mode which is a new digital mode using some military specs.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3507 [3 - Current Dev List] Enhancement minor always 2019-10-21 09:01 2019-10-21 09:01
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: All
Sub-Module: General
Testing: Not Started
Summary: product should warn users about Windows 7 end of support
Description: Windows 7 support ends on January 14, 2020. The product should warn users with a popup, as we did for previous Windows EOL events.

https://support.microsoft.com/en-us/help/4057281/windows-7-support-will-end-on-january-14-2020


Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3029 [3 - Current Dev List] Bug minor have not tried 2019-01-03 14:22 2019-10-20 17:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Setup
Sub-Module: (select)
Testing: Not Started
Summary: HRDSync.rtf documentation mentions HB9DRV, is outdated
Description: The product installs to the "C:\Program Files (x86)\HRD Software LLC\Ham Radio Deluxe" directory a file named "HRDSync.rtf"

This file contains mentions of HB9DRV and his website, and has outdated content. It's not clear that the "sync" feature remains viable; perhaps it should be removed from the product, along with the documentation. If the feature remains, it should be cleaned up -- including updating this file for content and correctness.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006876)
KB3NPH   
2019-01-03 23:18   
The Synchronizer is a viable utility in HRD. It allows users who have transceivers which have very good transmit qualities but questionable receive quality and has CAT control capabilities to synchronize the TX frequency of their transceiver with a communications receiver, which also is capable of CAT control and has much better receiving quality.

Many hams have used the Synchronizer in some very ingenious ways to synchronize two different radios together, so, I would definitely say this is a viable utility. The current issue is that it worked in V5.x, but somewhere along the line the code got changed or corrupted in some way so it doesn't function as it was originally designed.
(0008096)
K7ZCZ   
2019-06-16 11:15   
This issue isn't about rebuilding the Synchronizer feature; it's about the content of this file, specifically.

It's easy to place new content into the file, but I'm not the person who should be writing or editing that content because I'm completely unfamiliar with the feature.

It's possible that, if the feature changes or is removed, this file should be removed. Looks like Mantis 520 is being used to track the issues with the utility itself.
(0008884)
K7ZCZ   
2019-10-20 16:16   
this was status == assigned, but was assigned to nobody. I'm resetting the status to "new"


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
520 [1 - Backlog] Bug minor always 2013-12-21 18:56 2019-10-20 16:15
Reporter: W4PC Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: (select)
Testing:
Summary: HRD Synchronizer does not work
Description: Synchronizer will not scan to see if more than one instance of RC is running.
Tags:
Steps To Reproduce: Load two instances of RC with a different rig configured on each instance. Open Tools>Programs>Synchronizer dialog. Click on "SCAN" to detect more than one instance of RC running. Synchrnizer does nothing.
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2759 [3 - Current Dev List] Maintenance minor always 2018-06-03 19:24 2019-10-20 15:22
Reporter: K7ZCZ Platform:  
Assigned To: K7ZCZ OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 6.4.0.842  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: All
Sub-Module: General
Testing: Not Started
Summary: Cleanup: remove use of bogus xmalloc / xfree macros
Description:
Several applications declare and use macros for memory management, like this:

#define xmalloc(s) (LPBYTE)HeapAlloc(GetProcessHeap(),0,(s))
#define xfree(p)   HeapFree (GetProcessHeap(),0,(LPVOID)(p))


These macros are bad for all the reasons that macros are bad -- most notably, type safety here.

More importantly, these macros aren't necessary. It's better to use new/delete or malloc/free, as they provide advanatages in debugging and performance, and are closer to C++ consturcts for sensible object (rather than memory) usage.

There is some evidecne that these macros were hacked in to work around perceived problems in the heap implementation. In fact, the issues largely surround concurrency and correctless issues in our own code.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006203)
K7ZCZ   
2018-09-13 16:03   
This checkin is made to the MikeB2 branch.
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4348

Once this change is merged to the main branch, the fixes will be available to test.
(0006578)
K7ZCZ   
2018-12-11 18:22   
Some more progress here ...
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4541
(0006585)
K7ZCZ   
2018-12-12 09:14   
A bit more progress with this checkin
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4548
(0008879)
K7ZCZ   
2019-10-20 15:22   
Tiny progress here ...
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5224


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3506 [2 - Next Dev List (Holding Area)] Bug major always 2019-10-20 12:14 2019-10-20 12:14
Reporter: w2pj Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Rig Control
Testing: Not Started
Summary: ILGRadio database (New .txt structure is not read by properly by HRD)
Description: I download and installed the new ILGRadio SW Database. Apparently extended and new fields have been added to the .txt database content structure, and the presentation is messed up in the rig control SWDatabse window. I do not believe a user you can edit the way the file is read. Probably requires an HRD update?
Can this be added to the improvements list? See below:

New Structure can be found here: https://www.ilgradio.com/structure/ab-structure.html

Latest Edition with upload time of October 19th 1200 UTC
Full Version now with 72199 data sets (improved new structure)
Look for improved new Structure and here on the Download page

Database modification with extended structure and more content effective September 1st 2019

ILGRadio database available of October 19th with more details available
EXT FILE: ilgadata.txt (zipped into ilgatext.zip)
DOWNLOAD: click here to download with your password
This text file is pure text without space between data fields (columns) and you can import this standard text file in other software.

I have attached the most recent file (trunctged so that size is under 2MB) from ILGRadio for you to use in testing...

73
Pete - W2PJ
Tags:
Steps To Reproduce: Install the current ILGRadio .txt Databse a,d the fields are all jumbled up in the sort Wave Databse window in HRD Rig Control
Additional Information: If you could please fix in the next Beta update, as those with current subscriptions to updates to the ILG dta bse cannot make use of the most recent SWL updates... Thank you
Attached Files: ILGBDATA_X_10_2019_Truncated.TXT (1,721,427 bytes) 2019-10-20 12:14
https://development.hamradiodeluxe.com/file_download.php?file_id=788&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3482 [3 - Current Dev List] Bug minor sometimes 2019-10-07 18:24 2019-10-19 10:18
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Call lookup
Testing: Not Started
Summary: Improve timeout detection in call sign lookup operation completion
Description: The call sign lookup operation splits work between the main thread (for the Logbook, UCSDB, and country list operations) and a worker thread (for any other source).

It's conceivable that something goes wrong in the worker thread, and results are not mmade available when the main thread expects to present them. This has always been a problem in the call sign lookup code, and isn't new to the rewrite. Code exists to do various message pumps and sleeping, but the bottom line is that an individual call sign lookup operation who's source has timed out or failed to respond will end up causing problems for the application.

This code could be tightened-up to be more reliable, and also transparent to the user about its error disposition.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0008836)
K7ZCZ   
2019-10-16 16:09   
some work with this check in, for the related bug (which was actually about a deadlock)
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5214
(0008865)
K7ZCZ   
2019-10-19 10:18   
This checkin adds code to assure the completion callback on the lookup client is only called once.
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5218


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3410 [4 - Business Priorities] General feature N/A 2019-07-30 14:23 2019-10-17 16:44
Reporter: WA9PIE Platform:  
Assigned To: K7ZCZ OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Interfacing
Testing: Not Started
Summary: Add the SDRplay to our panadapter display
Description: Based on our specification for this feature, we have a desire to integrate our panadapter feature to the SDRplay.

Based on the information available regarding N1MM's approach, radios made by Yaesu and Elecraft do not have the type of internal capability that the ICOM IC-7300/7610/9700 or Kenwood TS-890 have. So our only remaining option is to take a similar path and build out support for the SDRplay to enable radios that are not otherwise internally capable to enjoy the panadapter functionality.

https://n1mmwp.hamdocs.com/spectrum-display-window/

It seems that N1MM accomplishes this by using the SDR Vendor Provided ExtIO*.dll. This is also referenced in our specification.

We can get a lot of "bang for the buck" with supporting the SDRplay as it would open up the feature to many many radios that otherwise have no path for the feature.
Tags: ParityGap
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0008304)
K7ZCZ   
2019-07-30 16:43   
"Integrate" doesn't make much sense here because the Icom and Kenwood panadapter support is tailored to the command and data interfaces prescribed by the radio. Integration wouldn't be the right path; instead, a new panadapter window should be implemented to display the data made available by the Smart SDR radios.

Adding a panadapter display to support the SDR Play radios can mean any of several things.

Maybe it means that we connect Rig Control to an SDR Play radio, and that's that. It's controlled as if it's its own radio. If the user asks to tune it or switch modes, it does so just like any other radio we might support.

Maybe it means that we connect to some other traditional radio, but offer a SDR Play connection side-by-side to provide panadapter display in concert with the traditional radio. This means that we must implement separate connection and configuration management for the panadapter connection to the SDR separately from the main radio. This setting must be managed, persisted, configured differently. We'll have to design how to control the SDR Play as a secondary radio while the first radio is the primary radio, controlled by Rig Control's main UI.

Or maybe it means something else.

I think this issue would benefit from a clearer problem statement and some conversation about approach and desired results before development work starts.
(0008308)
WA9PIE   
2019-07-31 01:27   
Make our panadapter feature work with the SDRplay in the same experience as what we’ve done for the Icom and Kenwood radios.
(0008309)
WA9PIE   
2019-07-31 02:35   
Adding some more context here...

What we want in-the-end is a way to display the SDRplay in our panadapter feature. However (using this use-case as an example), clicking on a "stream" (I can't find a better word for this) in the panadapter display generated by the SDRplay should retune the primary radio. Again, this is the solution for people who have radios that cannot internally support the panadapter display.

Let's use the ICOM IC-7600 as an example. It has no internal ability to support the panadapter display with commands. However...

The IC-7600 does have an "RX ANT OUT" connector. This can be connected to the input of the SDRplay to provide a RX antenna to the SDRplay. As the user interacts with the panadapter display that comes from the SDRplay, they may click on a frequency in the panadapter display. This action should change the frequency and mode of the IC-7600. (There are almost endless use cases here. The SDRplay doesn't need to be connected to the main rig at all. It can have it's own RX antenna. But in any case, clicking on a frequency in the panadapter display should change the frequency and mode of the primary radio (Yaesu, ICOM, Kenwood, Elecraft... etc).
(0008310)
K7ZCZ   
2019-07-31 13:42   
To me, your note 8308 means that we implement SDRPlay support in Rig Control, then add Padapter support to that, just as we have for the Kenwood and Icom radios.

Your next note (8309) seems to contradict that. It seems to asy that ,if Rig Control has a connection to an SDRPlay radio, clicking in the panadapter should tune the SDRPlay and another attached radio. I guess this must be selectable, since any number of radios might be attached in one Rig Control session. There's no notion of a "primary radio" in Rig Control, as far as I can tell. How is that established?

Perhaps you mean that both are true: that we add SDRPlay support to Rig Control, and optionally allow the SDRPlay panadapter window to control a second connected radio at the choice/option of the user.

In your example, it seems like it would be necessary for the IC-7600's tuning to change the SDRPlay tuning. If the SDRPlay is being used as a scope for the IC-7600, then tuning the IC-7600 either manually (on the radio's front panel) or with Rig Control should cause the SDRPlay to change its tuning. Is that always true? If the IC-7600 is in split mode, which side is followed? Is it possible to want to use an offset or a different band?

I haven't yet looked into the SDRPlay programming interfact, but I don't expect these things are too involved to implement. But I think it's necessary to clearly understand and agree upon what we want to implement before we start implementing it.
(0008316)
WA9PIE   
2019-08-01 11:47   
It's not likely that I can explain this thoroughly (which is why my comments may see contradictory). I can explain it conceptually.

This article gives us some insight to what hams want to do (in the context of using the SDRplay): https://n1mmwp.hamdocs.com/spectrum-display-window/

The SDRplay is not the transmitter (obviously, it doesn't have a transmitter). It doesn't seem that it's the receiver they're using either. (That is - no one seems to want to use the SDRplay as their receiver and use another radio as the transmitter. They really want to just pretend that the SDRplay is a "panadapter inside their radio." As such... when they change frequency and/or mode from within the panadapter display (by clicking the panadapter or whatever), they want their transceiver to change frequency and/or mode.

The link provided supports this conceptually. It talks about using the SDRplay as the panadapter hardware that their panadapter software is using to control other radios (Elecraft, Yaesu... IC-7600 in-particular).

So... it almost seems like it should be possible to have the Rig Control display using a given rig (eg. IC-7600) and the panadapter display using a different radio (SDRplay).

In the end, I don't care if we can control the SDRplay in the main (legacy) Rig Control screen. But that won't satisfy this need. So I wouldn't put a lot of priority on enabling the Rig Control screen to control the SDRplay (unless that's otherwise necessary).

The objective here is to use the SDRplay as the panadapter for radios that otherwise can't do it in code... such that they can control their transceiver by clicking on the panadapter display rendered from data from the SDRplay.
(0008330)
K7ZCZ   
2019-08-06 17:40   
Sounds like we could add a command to the "Tools" menu to connect to an SDRPlay and bring up a panadapter display based on the data sent from the SDRPlay. This could work independently of the radio view, though we can set it up so that they tune eachother.

Does that plan satisfy the request?
(0008332)
WA9PIE   
2019-08-07 02:37   
Absolutely!
(0008335)
K7ZCZ   
2019-08-07 12:33   
OK, I can work on that.

It will take quite some time, as the SDRPlay radio outputs raw I/Q data, which we must process in order to get a usable panadatper-style display. Some filtering, probably; FFT to get power data out of the band. Scaling, maybe more filtering.
(0008348)
K7ZCZ   
2019-08-09 13:35   
Tim, in the 2019-08-08 call, you raised concerns that this work wasn't the right direction for the product. CAn you please review the plan we have and raise your concerns here, so that MikeC can review and address them?
(0008361)
WA9PIE   
2019-08-10 20:08   
MB - with all due respect to Tim (and I'm happy to discuss it with him), please do not stop development on this item.

This is an extremely important addition to the software.
(0008362)
K7ZCZ   
2019-08-10 21:48   
This is assigned to Tim to collect his input, as he and Ferry vehemently objected to the plan.

I'll start on this implementation after 3001 is fixed; that issue has substantial effort behind it and needs to be completed and checked-in as there's a cost to switching contexts and leaving the code lying around, outside of the merge path from other versions. The work described here (in 3410) is substantal, and will take several weeks to research and implement.
(0008367)
WA9PIE   
2019-08-11 03:07   
Previously (prior to my comment), it was assigned to me.
(0008368)
KB3NPH   
2019-08-11 04:32   
(Last edited: 2019-08-11 04:45)
I spoke with Mike C about my thoughts on this project. Apparently I didn't fully understand the scope of this project and the reasoning for adding support for the SDRPlay.

(0008369)
WA9PIE   
2019-08-11 04:46   
For context... this change isn't being requested for the people who already use something like SmartSDR with their Flex. This change is being requested on-behalf-of those who have asked us for a panadapter display for radios like the FT-857D (which has none internally).

As described in the N1MM page "N1MM Logger Website | Spectrum Display Window", these users want more than what the SDRuno software can provide.

They want a panadapter display that has DX spots... and will change the frequency and mode of their FT-857D... as-if the panadapter was built into their radio. Essentially, as with the N1MM example, they will want to use the Ham Radio Deluxe panadapter feature because it offers more than what SDRuno is capable of.
(0008371)
K7ZCZ   
2019-08-11 11:56   
Something must be wrong with Mantis, then, Mike.

The history below says that, at 2019-08-09 11:35, I assigned it to Tim. Your comment was on 2019-08-10 18:08, about 36 hours after. The last time the issue was assigned to you was 2019-08-01 09:47. I'm not sure which time zone Mantis shows -- might be Pacific, might be UTC. But the issue hadn't been assigned to you for more than a week prior to your comment #8361.

How can we track down why issues aren't being assigned correctly?
(0008379)
WA9PIE   
2019-08-11 16:12   
Looking at the log, I'm clearly mistaken.
(0008380)
K7ZCZ   
2019-08-12 02:45   
Thank you for acknowledging your mistake, MikeC.

Ferry also had substantial reservations about this work, so I've assigned this issue to him to be sure that his input is heard.

Ferry, on the 2019-08-08 call, you strongly objected to this work. Can you please provide your input?
(0008381)
PD9FER   
2019-08-12 09:19   
Test...
(0008382)
PD9FER   
2019-08-12 09:21   
Ok I got an error posting before...

On this Mantis issue: I heard Mike-C and it is now clear what the intentions are.
I might was not 100% understanding what he wanted.

pse do continue development and feel free to ask any SDR related questions.
(0008390)
K7ZCZ   
2019-08-12 14:25   
Great, thanks.
(0008573)
WA9PIE   
2019-09-22 02:41   
Here's a few videos that describe the scenario, but think of it this way...

For radios that do not have an internal panadapter (that we can get to with code), they are "non-capable radios." So... the approach that's being used by N1MM and others is to add an SDRplay to the station to get the same effect of having it built into the radio. In this scenario, the SDRplay can connect to (a) the radio's IF output, (b) the radio's RX antenna out port, or (c) use an "SDR switch" like the MFJ-1708 SDR. But the goal here is to display the panadapter generated from the SDRplay and interact with it "as-if" if were inside the "non-capable radio." That is - if you click on the panadapter display generated by the SDRplay, it changes the frequency and mode of the "non-capable radio" (as well as changing the frequency on the SDRplay). Zooming in zooms in on the SDRplay's bandwidth, just as it did with the "capable radios."

This is critical in order for us to have a full-blown solution for folks who do not have capable radios.

Videos:
https://www.youtube.com/watch?v=0yqniB6plWA (short one where they're using an IC-7600; a "non-capable radio")
https://www.youtube.com/watch?v=eDK4mCTonp0 (club demo where they also talk about turning "rig sync" on/off)

But the idea here is that this should be the solution for customers who do not have capable radios.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3479 [Issues Needing Retest] Bug major always 2019-10-04 08:45 2019-10-17 16:39
Reporter: KB3NPH Platform:  
Assigned To: K7ZCZ OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Interfacing
Testing: Not Started
Summary: RC Issues with IC-7850 / IC-7851
Description: Ticket #583678 has reported issues with his IC-7850 while attempting to add buttons and sliders to the radio pane in the HRD Logbook V6.6.0.237. The problem is every time he attempts to configure one of the buttons in the Logbook Radio Pane his Logbook freezes and the only way to get out of it is by closing the logbook using Task Manager.

Both Ferry and I worked with this customer in remote and attempted every possible solution we knew to resolve this issue, however none were successful and we started digging deeper outside of the Logbook.

We discovered that his IC-7850 was connecting in Rig Control as an IC-7800 -V2. We know this because when connected to the radio the TAB on the Rig Control Screen shows "IC-7850 connected as (IC-7800 V2 commands"

While investigating this we found that in the IC-7850 manual it indicates that the CI-V address can be 02h~8Eh~DFh
The manual for the IC-7851 also shows CI-V addresses of 02h~8Eh~DFh. According to http://www.plicht.de/ekki/civ/civ-p31.html the CI-V address for the IC-7800 is 6Ah. The crazy thing is it appared that no matter what CI-V address that was entered for the IC-7850 it would connect as an IC-7800 in HRD Rig Control.

Unfortunately this is all the information we have at this time about this issue. Maybe development might have any other suggestions on how we can test this and help provide more detailed information. I'm sure the customer will be very happy to assist us in any way he can to get this issue resolved.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2658 [1 - Backlog] Bug minor always 2018-04-06 06:43 2019-10-16 03:16
Reporter: PD9FER Platform:  
Assigned To: K7ZCZ OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: DX Cluster
Testing: Not Started
Summary: DX Cluster E-mail alarm Error:Warning:ssl_verify ! self-signed or not signed by a trusted CA
Description: Open Options in DX Cluster and navigate to E-Mail Alarms
When using Gmail with port 587 and click Test, an error is generated.

=> EHLO smtp.gmail.com
 
  <= EHLO smtp.gmail.com
 
=> STARTTLS
 
  <= STARTTLS
 
Error:Warning:ssl_verify ! self-signed or not signed by a trusted CA
Tags:
Steps To Reproduce: Same as description
Additional Information: Ticket #321095

I replicated the problem
Attached Files: ssl_error.png (63,607 bytes) 2018-04-06 06:43
https://development.hamradiodeluxe.com/file_download.php?file_id=348&type=bug
gmail.PNG (38,208 bytes) 2018-06-27 06:17
https://development.hamradiodeluxe.com/file_download.php?file_id=451&type=bug
Notes
(0004710)
PD9FER   
2018-04-06 06:53   
Update:
Seems only the error appears when using the Test button.
E-mail is sent correctly.
(0005495)
PD9FER   
2018-06-27 06:12   
Other report in Ticket# 112542
(0005496)
PD9FER   
2018-06-27 06:17   
Added image
(0005499)
WA9PIE   
2018-06-27 09:56   
Ferry - I need you to document exact steps to replicate this and get them into Mantis please.
(0005501)
PD9FER   
2018-06-27 11:31   
Open Options in DX Cluster and navigate to E-Mail Alarms
Setup whatever e-mail account you want.

Click the TEST button, it will now Fail every time

Do note that when you entered the correct details the TEST will fail but the Alarms will send out the e-mail.
(0005511)
PD9FER   
2018-06-28 07:31   
Looks like the whole e-mailing system does not work at the customer.
Please review the whole e-mail engine.
(0007639)
PD9FER   
2019-03-07 16:04   
Going to retry
(0007710)
PD9FER   
2019-03-20 03:02   
Still having these issues.
Also a new ticket came in Ticket #481541
(0007713)
K7ZCZ   
2019-03-21 15:19   
In the triage call on 2019-03-21, we agreed that the advice to "please review the whole e-mail engine" isn't viable, and that we'd focus on the GMail testing here, only.
(0008827)
PD9FER   
2019-10-16 03:16   
Tested this again on V6.7.0.234

=> EHLO smtp.gmail.com
 
  <= EHLO smtp.gmail.com
 
=> STARTTLS
 
  <= STARTTLS
 
Error:Warning:ssl_verify ! self-signed or not signed by a trusted CA
=> AUTH LOGIN
  <= AUTH LOGIN
=> ZmVycnlAaHJkc29mdHdhcmVsbGMuY29t
  <= ZmVycnlAaHJkc29mdHdhcmVsbGMuY29t
=> c2F0ODI2MXNhdDgyNjE=
  <= c2F0ODI2MXNhdDgyNjE=
=> MAIL FROM: <intentionally blank>
  <= MAIL FROM: <intentionally blank>
=> RCPT TO: <intentionally blank>
  <= RCPT TO: <intentionally blank>
=> DATA
  <= DATA
=> Date: wo, 16 okt 2019 08:11:09 +0000
=> From: intentionally blank <intentionally blank>
=> To: <intentionally blank>
=> Cc:
=> Subject: A Test from HRD Logbook
=> X-Mailer: Sysgem AG - SMTP Mailer v1.0
=> MIME-Version: 1.0
=> Content-type: text/plain; charset=utf-8
=> Content-Transfer-Encoding: 8bit
=>
=> HB9DRV is on 20 meters
=> .
  <=
  <= .
  <= QUIT
 


The mail is send and received.
Only issue that I now see is: Error:Warning:ssl_verify ! self-signed or not signed by a trusted CA


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3501 [1 - Backlog] Enhancement minor have not tried 2019-10-14 07:01 2019-10-14 07:01
Reporter: KB3NPH Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: DM780
Sub-Module: Functional
Testing: Not Started
Summary: Add digital mode MFSK-128
Description: Ticket #637562 - It's been requested that digital mode MFSK-128 be added to DM-780 modes. It appears this mode is used by many organizations such as SATERN (Salvation Army Team Emergency Radio) International Digital Net along with many other EOCs, Races, MARS, etc. A lot of the organizations are currently using FLDigi and many of the members would rather use Ham Radio Deluxe.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2718 [1 - Backlog] Enhancement minor have not tried 2018-05-15 08:04 2019-10-13 12:54
Reporter: KB3NPH Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: All
Sub-Module: Appearance/UI
Testing: Not Started
Summary: Development of high-contrast screens
Description: We have a lot of visually impaired operators, including myself. How difficult, or could it even be done, to add a feature to HRD to allow for high-contrast screens in all of the modules, similar to that used on the Rig Control screen? Even just a white on black option on all the modules would be helpful. The ability to customize foreground and background colors would even be better.
 
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3500 [3 - Current Dev List] Bug minor always 2019-10-13 09:57 2019-10-13 10:55
Reporter: K7ZCZ Platform:  
Assigned To: K7ZCZ OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: All
Sub-Module: Functional
Testing: Not Started
Summary: MAPISend code is dangerous copy-pasta
Description: The CMAPISend class is copied and pasted to the rig control project, the Satellites project, and the DM780 project. It doesn't seem to be correct, and is a concern for security issues.

The redundant implementations should be removed, unused code should be deleted; and the whole class should be removed if possible.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0008805)
K7ZCZ   
2019-10-13 10:51   
(Last edited: 2019-10-13 10:55)
The Rig Control instance of this code was completely unused and is removed with this checkin:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5206

that leaves DM780 and Satellite Tracker

(0008807)
K7ZCZ   
2019-10-13 10:54   
oops, resolved the wrong issue


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3488 [3 - Current Dev List] Bug minor always 2019-10-12 16:21 2019-10-12 16:21
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: (select)
Testing: Not Started
Summary: weird action in Rig Control Connection dialog after pressing Enter
Description:
The Rig Control app will try to connect to a weird, non-existant radio if ENTER is pressed in the "Conntect" dialog. Pressing enter in a dialog box is meant to take the default action -- as if the default button (usually "OK") was pressed. If the connect dialog doesn't perform a predictable action, its usability is impaired.
Tags:
Steps To Reproduce: 1) Start up Rig Control
2) In the "Connect" dialog, press ENTER without adjusting any other controls
BUG#1) Rig Control opens with a radio view tab labeled "HamRad1". Might have a different number, but "HamRad" is always there. The radio view is mostly blank -- tuning bars appear, but no frequency is displayed and there are no sliders, buttons, or dropdowns.

It's also possible to repro this with Rig Control already opens

1) Start up Rig Control
2) Connect to your regular radio. DemoMatic is fine
3) Use the "Connect" command in the "File" men
4) When the resulting "Connect" dialog is displayed, just press enter
BUG#2) As BUG#1 above.
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3455 [3 - Current Dev List] Bug minor always 2019-09-24 17:28 2019-10-12 11:58
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.7.0.227  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: SW License Mgmt
Sub-Module: SW License Client
Testing: Not Started
Summary: Data Collection requirements message contains typo
Description: The "Data Collection Requirements" text shown to users in the license dialog contains a typo and should be fixed.
Tags:
Steps To Reproduce:
1) Start up any program in the suite. I used Rig Control.
2) Connect to DemoMatic.
3) Use hte "HRD License Manager" command in the "Tools" menu
BUG#1) The first line in the text in the box inside the resulting "License Key Manager" dialog says "Data Collection Requirments"

Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2679 [1 - Backlog] Bug crash always 2018-04-16 14:46 2019-10-09 10:30
Reporter: KB3NPH Platform:  
Assigned To: WA9PIE OS:  
Priority: low OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Functional
Testing: Not Started
Summary: Elecraft K3 Extended menu causes crash of RC. No dump created.
Description: In Rig Control for the K3, click on "Tools > Extended Menus >" and when it opens it attempts to load and gets about 1/2 way anc causes a crash. No dump is provided.

In V6.3.0.613 it functions perfectly.

For steps to reproduce see the two PSR Zip files in the Team Drives\HRD Software\Dumps\ file names are HRD V63_613.zip and HRD6.4_806.zip.

Hope these help you identify the issue so you can resolve it.
Tags: Elecraft, K3
Steps To Reproduce:
Additional Information: Ticket #627379
Attached Files:
Notes
(0007371)
K7ZCZ   
2019-02-13 08:40   
I don't have access to a K3. Until I do, the only chance of addressing this issue is by collecting a minidump.

If the app is crashing, it probably is creating a minidump. It's just that the dump isn't caught by our own handler and ends up being processed by Windows Error Reporting.

This can be confirmed by examining the Windows Event Log. There are some notes about how minidumps work in this forum post: https://forums.hamradiodeluxe.com/node/43376

and they include a link to these instructions: https://support.microsoft.com/en-us/help/931673/how-to-create-a-user-mode-process-dump-file-in-windows

which show how to have Windows Error Reporting keep the dump around even after it is processed.

If this issue is still reproducible in current builds, please collect a dump as it will provide our best chance of working out a fix.
(0007722)
K7ZCZ   
2019-03-21 21:50   
In the 2019-03-21 team call we weren't sure if this menu even existed.

Is this an issue we should pursue fixing, or has the issue become obsolete?
(0007723)
KB3NPH   
2019-03-23 01:25   
I have been in contact with the customer who reported this issue (Ticket #627379). Unfortunately he can't provide any further information. He can't tell me when this feature worked, only that it stopped working sometime between 2016 and 2017. He did, however, provide a video of the "crash". I created a folder (Mantis 2697) in the Dumps folder and placed the video in there for you to view. It appears to just shut down the Rig Control program without giving any kind of error. Hope this helps in some way.
(0007725)
K7ZCZ   
2019-03-23 09:39   
A copy of the dump file written for the crash would be most helpful. Since I don't have access to any Elecraft radios for testing, it's my only hope at making a fix.

Instructions for collecting minidumps are in this thread: https://forums.hamradiodeluxe.com/node/43376

And information about getting dumps that are recorded by Windows itself are in this KB article: https://support.microsoft.com/en-us/help/931673/how-to-create-a-user-mode-process-dump-file-in-windows
(0007783)
KC7FPF   
2019-03-28 15:17   
I will make a attempt to contact elecraft in regards totis issue.
(0007788)
K7ZCZ   
2019-03-28 17:01   
In the team call on 2019-03-28, we agreed that Tim would own following up with the reporting customer to use the suggested steps to secure a dump for the failed process from the OS.
(0007828)
KB3NPH   
2019-04-04 12:32   
Kevin contacted Doug from Elecraft Customer Support who said "Closest thing to an extended menu on a K3 is a K3S, the superseding model of radio." which indicates that there is no Extended Menus in the K3 and that the only actual extended menus are in the K3S and newer models.

I believe we can now close this with no action and I will notify the customer of this information.
(0007843)
KB3NPH   
2019-04-09 10:37   
(Last edited: 2019-04-11 14:15)
Today in Ticket #627379 send the following response:

Hi Tim,

This is version 6.0,0,132. I understand that this is a old copy of HRD.

I also tried version 6.2.72.294 they have posted but it has the crash problem.
Its unknown what version I was using years ago.

73
Alan

Included in his message was a video that demonstrated the K3 External Menus were working in this version. Can we go back to the source for 6.0.0.132 or to a version around this time and check the K3 code in the source and see how it compares to what we now have in the code to see if we can make this thing work as it is demonstrated in the V6.0.0.132 version in this guy's video?

https://support.hamradiodeluxe.com/file.php?key=-m8r7pjjjrdcr5dfxcinxjeitsq0frfe&expires=1555113600&signature=821673430b506c85a11d025358596bd36503bcc5

Above is a link to the video this customer left in his OSTicket

(0007844)
K7ZCZ   
2019-04-09 11:14   
Comparing source code across versions isn't a viable way to track down an issue like this.

During the team call, we agreed that we'd try to retrieve the minidump from the customer's machine. Minidumps make identifying these problems pretty easy, and let the dev team focus on the actual fix. Is progress being made on that plan?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3430 [3 - Current Dev List] Bug major always 2019-08-12 14:23 2019-10-06 18:37
Reporter: g3ucq Platform: PC  
Assigned To: OS: Windows  
Priority: high OS Version: 10 64 bit Home  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Import Export
Testing: Not Started
Summary: HRD ADIF Import no longer Importing any HRD User_Defined_Fields.
Description: As the title reported by G4NVB
Tags:
Steps To Reproduce: 1: Export a Logbook which contains information in any of the HRD User_Defined_Fields (ensuring ADIF + Ham Radio Deluxe Radio Button is selected).

2: Inspect the Exported ADIF File to confirm that the HRD User_Defined_Fields are populated.

3: Create an empty HRD LOgbook.

4: Import the saved ADIF File.

5: Observe that the HRD User_Defined_Fields are no longer populated.
Additional Information: I confirm G4NVB's findings.
System Description
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2236 [3 - Current Dev List] Bug minor always 2017-09-04 14:44 2019-10-06 18:31
Reporter: g3ucq Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Various
Testing:
Summary: Custom field reports a false positive
Description: Using the Custom 1 field I have created a field called Clublog Upload.
If I have uploaded a QSO to Clublog I add 'Yes' to the column (using bulk editor)
If I have worked a station before, and uploaded to Clublog so that Yes has been added, all subsequent QSOs with that station will show a 'Yes' for Clublog upload even though I have not yet done that.
Tags:
Steps To Reproduce: Using the Custom options create a custom field.
E.g Clublog.
For each QSO that is uploaded to Clublog add a 'YES' for the QSO.
Subsequent QSOs with the station, even on different bands/modes will show a YES against that QSO despite not having uploaded that QSO to Clublog.
Additional Information: Would it be possible to add a dedicated column for Clublog upload as for LOTW etc.?
Attached Files:
Notes
(0004494)
g3ucq   
2018-03-16 06:10   
No change.
(0007617)
g3ucq   
2019-03-07 04:37   
No change.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3254 [3 - Current Dev List] Bug minor have not tried 2019-03-19 08:37 2019-10-05 10:37
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: All
Sub-Module: Functional
Testing: Not Started
Summary: CXMLMgr (and CXMLMgrSDK) seem like they leak objects
Description:
CXMLMgr (and the redundant CXMLMgrSDK) seem like they leak memory. They play fast-and-loose with OLE object reference counts, with very unorthodox paradigms for managing the returned object life cycles.

Each call site (and there are many!) which use CXMLMgr should be examined to see if they're properly managing references. I fear that we're leaking XML DOM objects in several places in the code.

The class should be morphed into a more sensible, more useful wrapper for XML documents.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2982 [3 - Current Dev List] Maintenance minor have not tried 2018-12-11 12:21 2019-10-05 10:37
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: All
Sub-Module: (select)
Testing: Not Started
Summary: CXMLMgrSDK is almost-unused reimplementation of CXMLMgr
Description:
The applications share the CXMLMgr class to read and write XML-formatted data.

The CMigrateDlg in the Setup2.DLL library avoids the CXMLMgr class and uses, instead, a class named CXMLMgrSDK. This class is reimplemented from CXMLMgr, but avoids using MFC (CString, in particular) and any C-runtime library routines. It reimplements several CRTL routines, in fact.

Re-implementations of low-level functions, and of CXMLMgr itself, are unjustified and should be removed. We're better off with a single CXMLMgr implementation so we can fix bugs and add features in one single place.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006655)
K7ZCZ   
2018-12-15 10:17   
This checkin scopes a couple of global, static helper functions for XML/HTML formatting into the CXMLMgr class. Tight scoping is a tenet of good C++ programming:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4568

Scoping these functions immediately revealed that some code which shoudl be using CXMLMgr (from HRDCommon) was instead depending on both CXMLMgr and CXMLMgrSDK (from Setup2). That dependency is rectified in the same checkin. Remedying this dependency further isolates the CXMLMgrSDK code in preparation for removal.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3391 [3 - Current Dev List] Enhancement minor have not tried 2019-07-13 16:45 2019-10-05 10:34
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.6.0.236  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: SW License Mgmt
Sub-Module: SW License Client
Testing: Not Started
Summary: consider removing .Net setup from HRD product setup
Description: I believe that .Net is installed on all versions of Windows we support. If that's true, then we should remove the .Net setup components from our product setup image.

Maybe I'm wrong -- if we're still supporting back-level versions of Windows that don't include a version of .Net good enough for our dependency, then maybe we can at least remove .Net from the product setup image and provide a web-based installer.

The .Net setup contributes about 50 megabytes to the size of the downloaded setup image. The .Net setup is required only to support QLM. No other part of the product uses it.
Tags:
Steps To Reproduce:
Additional Information: This blog post has a table showing which versions of Windows include which versions of the .NET runtime by default.
https://blogs.msdn.microsoft.com/astebner/2007/03/14/mailbag-what-version-of-the-net-framework-is-included-in-what-version-of-the-os/

Attached Files:
Notes
(0008751)
K7ZCZ   
2019-10-05 10:34   
3437 (now related) has notes saying that we've encountered a system in the wild without .NET installed. If that diagnosis is accurate, then ti seems like we need to figure out why Setup isn't installing its .NET runtime playload when it's needed. Setup bug? Wrong version? Maybe that diagnosis means this issue is won't fix, and if so, it probably leads to other issues to fix the .NET install failure and to minimize the impact of the .NET runtime on the downloadable file size.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1409 [1 - Backlog] Bug minor always 2013-12-23 21:44 2019-10-04 11:16
Reporter: Support Platform: Inten Dual-Core  
Assigned To: KC7FPF OS: Windows 7 Home Premium  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: (select)
Testing: Not Started
Summary: Radio Misidentified As "TT-Jupiter"
Description: I'm running HRD 6.0.0.123 Preview/Beta 2.24 and an Omni VII with an RTS Systems
cable. Using the Radio, not the Remote Omni VII connect option.

The radio pane in the Logbook incorrectly identifies my radio as a "TT-Jupiter"
instead of an Omni VII. I am using the Omni VII drivers.

Unfortunately this gets passed upstream to HRD Logbook and then to the "world".
Tags:
Steps To Reproduce: In the main HRD screen, setup a connection to an Omni VII (Radio).

Start the logbook, then open the radio pane. It will say you're running an
"TT-Jupiter" instead of an Omni VII.
Additional Information: Reported by n1zhe
Attached Files:
Notes
(0008748)
KC7FPF   
2019-10-04 11:16   
At this time Ten Tec is only producing one new radio. this is a new radio for TenTec 588+ OMNI-VII+ Tx/Rx
It does appear that Ten will continue to do repair on older equipment. However unknown if any further support will be available for older equipment.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1566 [1 - Backlog] Bug minor always 2014-02-01 01:38 2019-10-04 11:15
Reporter: WA9PIE Platform:  
Assigned To: KB3NPH OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: DM780
Sub-Module: Macros
Testing: Not Started
Summary: Macro issues (parent)
Description: This record was created to track macro bugs.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0008737)
KB3NPH   
2019-10-03 14:21   
Mike B, could you please take a look at the open related issues and see what can or can't be done with them.
(0008747)
K7ZCZ   
2019-10-04 11:15   
Right now, 573, 534, 1385 and 1438 are the active issues related to this one. I don't think I can do anything for them in their present state. I've made notes in each of the individual issues.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
534 [1 - Backlog] Bug tweak always 2013-12-21 18:56 2019-10-04 11:14
Reporter: W4PC Platform: PC  
Assigned To: W4PC OS: Windows  
Priority: normal OS Version: 64-bit Pro  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: DM780
Sub-Module: Macros
Testing: Not Started
Summary: DM-780 - Annoying Placement of Radio Pane during Macro Edit
Description: If you do any amount of work editing DM-780 macros, this soon begins to get really annoying. Why is the macro edit Radio pane 'always on top' and why is it positioned over the macro editing pane?

Could we please get this annoyance fixed? Thanks.
Tags:
Steps To Reproduce: Right click on any macro in the macro list that has radio control commands.
If one does not exist, create one.
Notice the behavior of the radio control dialog.
Additional Information: If you move the main macro edit dialog left and the RC dialog to the right, and then close using the OK button, the screen position of the main macro edit dialog is remembered and pops up there on the next open. However the RC dialog consistently pops up center screen - i.e. the new position is not remembered.

Suggested:
- Remove the modal property of the RC dialog
- Make it's position relatively to the right of the macro edit dialog (if possible), or make it's new position (user moved) persistent from one open to the next.
Attached Files: 6.4.0.779_DM_RCMacroEdit.png (252,074 bytes) 2017-08-18 07:47
https://development.hamradiodeluxe.com/file_download.php?file_id=238&type=bug
Notes
(0004021)
n4kit   
2017-08-18 07:38   
When Editing a Radio Control Macro, the Radio Pane dialog does pop up right over top of the Macro edit dialog. The RC dialog can be dragged aside, but I can see where if you were doing alot of macro editing of RC macros, it could get to be an annoyance.

Also, the RC dialog is modal and remains on top even if the main DM window is minimized.

See screenshot.
(0004022)
n4kit   
2017-08-18 07:47   
Screenshot added
(0008746)
K7ZCZ   
2019-10-04 11:14   
I guess the problem here is that we want one window to appear in a different location, with different parenting. All this would need to be workable is some repro steps -- how to access the macro list and the window in question, in particular.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1438 [1 - Backlog] Bug minor always 2013-12-23 21:44 2019-10-04 11:13
Reporter: Support Platform: Windows  
Assigned To: Support OS: Windows 7 Pro  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: DM780
Sub-Module: (select)
Testing:
Summary: Tags in DM-780 are not kept when between shutting down and restarting the program
Description: Macro Tags in DM-780 are not kept when between shutting down and restarting the
program. This does not affect macros themselves, they are fine, just the tags
are missing on startup.
Tags:
Steps To Reproduce: - enter tags
- shut down
- restart program
Additional Information: Reported by WA3WZR

Probably the same issue, but tags also did not migrate over from the previous 6
beta version
Attached Files:
Notes
(0000319)
WA9PIE   
2014-02-02 15:01   
We're not assigning them until just before they go to the "List of 5".
(0004047)
n4kit   
2017-08-18 11:53   
Tags in DM780 need a hard look relative to Identities and My Station profiles. See also 0000509.
(0008745)
K7ZCZ   
2019-10-04 11:12   
To make progress, this issue needs some repro steps. in particular, "enter tags" doesn't give us much to work with.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
537 [1 - Backlog] Bug major always 2013-12-21 18:56 2019-10-04 11:11
Reporter: W4PC Platform: PC  
Assigned To: WA9PIE OS: Windows 7  
Priority: normal OS Version: 64-bit Pro  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: DM780
Sub-Module: Macros
Testing: Not Started
Summary: Macro set titles not updated from file load
Description: Macro set titles are available from files, but are not updated from a file load unless the 'Set Title' button is clicked.

Macro set titles should be loaded from the file, and the Macro Set title be made an editable field.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0004025)
n4kit   
2017-08-18 08:45   
(Last edited: 2017-08-18 08:51)
Holy hell, what a mess!
The more I noodle with the macros, the more confusing it gets.
It would now appear that, by default macro definitions are saved in several files:
DMMacroDefns.xml = Default set
DMMacroDefns_001.xml = Set 2
DMMacroDefns_002.xml = Set 3
DMMacroDefns_003.xml = Set 4
DMMacroDefns_004.xml = Set 5
DMMacroDefns_005.xml = Set 6
etc.

Moreover - the Load and SaveAs buttons on the toolbar appear to apply to the currently selected macro SET. This is probably good as one user could load another user's set of macros for e.g. a contest without overwriting all their other sets.

I think I understand the concept of having SaveAs - it allows a user to "export" a macro set to be sent to another user to "Load" - i.e. sharing.

If that is the case, then my comments RE Mantis 0000535 and 0000536 may be irrelevant and I would suggest the following adjustments:
1. Relabel the "SaveAs" button as "Export Set" with the same functionality.
2. Change the default directory for the "Export Set" save as dialog to the users My Documents directory
3. Relabel the "Load" button as "Import Set"
4. Change the default directory for the "Import Set" dialog to the users My Documents directory
5. Add a warning dialog to the "Import Set" button - "Warning - this will overwrite the macros in the current macro set, Do you wish to continue" Yes/No
6. Change the current "Import" button label to "Copy from Set"

With respect to this specific Mantis item, yes, the Set title when loading ("Importing") a macro defs from a file should replace the default "Set #" title. The user can then use the "Set Title" button to rename the set if desired.

(0004026)
n4kit   
2017-08-18 08:53   
Mike - need you to take a hard look at Mantis 0000535, 536, 537. Start at 537 and work your way backward. See if you agree with me, if so you can change statuses as you see fit.
(0005847)
WA9PIE   
2018-07-26 11:58   
Tim - can you take a look at this and see if you can replicate it?
(0006875)
KB3NPH   
2019-01-03 22:53   
On this report it's said that the name of the macro set that has been saved will not be added when the set is reloaded into DM-780. This is totally incorrect. Lets say for example you create a macro set that is used with a specific radio and assign it a set name of "FT-950 Macros". If you "save" this macro set in order to be able to load it into DM-780 at a later date, at first when you click the "SAVE" option in the Macro Manager to save this set, it will default to a filename of "DMMacroDefns.xml". Rather than continuing to save the file with the default name (DMMacroDefns.xml), you must change it to the set name that you have created. In other words you enter "FT-950 Macros" and it will then be saved to the file "FT-950 Macros.xml" in a location that you choose, like in your documents.

If it becomes necessary to reload this macro set back into DM-780, you would select an "empty set" (such as "set 3") in the Macro Manager, then click the "LOAD" option from the Macro Manager toolbar and navigate to where you saved the FT-950 Macros.xml file and select it. When it then loads into the empty set3 screen, the macros will be loaded, however the set name will still be "Set 3" and NOT the name of the file which it was saved as.

In order to restore the proper set name, all you have to do is click on the "SET TITLE" button located just to the right of the macro set name field and the loaded file name (FT-950 Macros) will be inserted where it currently indicates the original empty set name (Set 3).

This is really not a bug, but rather a poor design in the way the system saves and loads then reloads individually saved macro sets.

I hope this clarifies this and we can either close this with no action, and update our documentation to provide the proper way to save and load individual macro sets OR, change the design so that when a macro set is saved, the default filename IS the actual name of the macro set and NOT the default ""DMMacroDefns.xml" that has to be changed at the time of saving, then when reloaded instead of having to click the "Set Title" button to replace the name (set 3) in my example, replaces the "set 3" name with the actual filename.
(0008743)
K7ZCZ   
2019-10-04 11:11   
This issue contains no repro steps and not much of a description. Looks like there's a note that says the problem is with the UI design, but I don't see anything that specifically explains what the design should look like. We also have the decision of updating the documentation and fixing the application. If we have a good suggestion for fixing the application, then that probably should be preferred ...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1333 [1 - Backlog] Bug tweak always 2013-12-23 21:44 2019-10-03 15:01
Reporter: Support Platform: Windows  
Assigned To: WA9PIE OS: XP Pro SP3  
Priority: high OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: (select)
Testing: Not Started
Summary: Cabrillo fields missing in export HRD 5.x
Description: OK Jim, Did the contest, exported the cabrillo file and CAN'T email it in
because the exported cabrillo file does NOT show the RX/TX exchange numbers
.. did you miss the point here?

I dont give a fig if the exchange numbers appear in the logbook after the
fact, all i care about is that these fields "APPEAR IN THE EXPORTED CABRILLO
FILE"
Tags:
Steps To Reproduce: Every time export is done
Additional Information: Reported by M1BCM
Attached Files:
Notes
(0008738)
KB3NPH   
2019-10-03 14:58   
Mike, could you please take a look at this and see what YOU want to do with it? This export is normally used to create a Cabrillo file to send contest contact logs to the contest organizer. Since we are not contest logging software we can dump this for now, unless you want to keep it in the event we do decide to install a full blown contest module.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3477 [3 - Current Dev List] Bug minor always 2019-09-29 17:43 2019-09-29 17:43
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Documentation
Sub-Module: (select)
Testing: Not Started
Summary: Downloadable PDF documentation is incorrectly encoded
Description:
The downloadable PDF documentation file is incorrectly incoded, impacting the readability of the file. Curly quote marks and apostrophies were used in the original document, and do not render correctly.
Tags:
Steps To Reproduce: 1) go to https://www.hamradiodeluxe.com/downloads/
2) Use the "Downloads" button for the HRD user manual
3) Open the downloaded PDF file
4) Search for "?" in the PDF

BUG#1) first hit is "users stood at 20,006 ? quite an achievement"; looks like an em-dash is replaced with a question marks
BUG#2) next hit is "listed rigs that ?really? work fully with the satellite module"; looks like quotes were rendered as question marks
BUG#3) next hit is "If you don?t have a serial port"; looks like an apostrophie is rendered as a question mark
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2738 [1 - Backlog] Bug major always 2018-05-24 13:15 2019-09-28 08:03
Reporter: KB3NPH Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: ALE Window
Testing: Not Started
Summary: Logbook ALE STX and SRX saved to wrong fields in the log
Description: The STX# (Serial TX #) and SRX# (Serial RX #) are being saved in the wrong fields in the Logbook DB. These fields should be configured as numeric only, however, the way they are now, any kind of data you enter in those fields in the ALE are saved to the Received Exchange and the Sent Exchange. The data in the Sent Exch and RCVD Exch is entirely something else and is defined by the contest organizers.

Please see the attached image of the logbook and please read
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: SRX STX Wrong fields.jpg (125,050 bytes) 2018-05-24 13:15
https://development.hamradiodeluxe.com/file_download.php?file_id=403&type=bug
Notes
(0005109)
KB3NPH   
2018-05-24 13:33   
A PDF file is in the support docs that explains how this SHOULD work and where the items are to be saved in the Logbook DB.
\Team Drives\HRD Software\HRD Support\HRD Logbook Guidance\LB - ALE Contest STX - SRX Numbers.pdf
(0005128)
K7ZCZ   
2018-05-28 16:48   
Linked to 2231, which changed how these fields are managed a few build ago. That issue describes ADIF exports, but it does indicate a format for these field and made no mention of numbers in square brackets as the "LB - ALE Contest STX - SRX Numbers" document does.

The only way to fix this would be with a complete and clear specification of the functionality.
(0008222)
KC7FPF   
2019-07-12 17:21   
As indicated by a recent customer with the same issue. Please refer to OS Ticket 202295
(0008448)
KC7FPF   
2019-08-26 14:59   
Customer was inquiring about the status of this issue Ref ticket 364439
(0008717)
PD9FER   
2019-09-28 08:03   
Ticket 199026 (Related?)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3454 [3 - Current Dev List] Bug minor always 2019-09-24 11:17 2019-09-27 09:08
Reporter: K7ZCZ Platform:  
Assigned To: DOUG OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 6.7.0.226  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: SW License Mgmt
Sub-Module: SW License Client
Testing: Not Started
Summary: unused controls in QLM License Dialog
Description:
The QLM License Dialog (IDD_DIALOG_LICENSE_UPGRADE_QLM) has a static control and an edit control that are marked visible = FALSE. No code exist to make the controls visible at runtime. Data is set to the controls, but never read. The controls appear to be redundant to the visible

The control IDS are IDC_STATIC (ugh!) and IDC_EDIT_CALLSIGN2.

If we can confirm the controls are truly unused, they should be removed completely. The related m_editNewCallsign2 member of CLicenseUpgrade should be removed, too.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0008687)
DOUG   
2019-09-26 00:07   
They are not in use. There was some old code built around them that ended not being needed.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3470 [3 - Current Dev List] Enhancement minor have not tried 2019-09-26 22:34 2019-09-26 22:34
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.7.0.227  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: (select)
Testing: Not Started
Summary: Panadapter could have a decay-hold line
Description:
The panadapter draws a graph of instantaneous signal strength. It could be enhanced to show peak-hold signal strength and let it decay after a certain period. Some users might not want this, so it should be configurable with an option. The decay time can vary from short (250 ms or so) to long (two or three seconds).

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3469 [3 - Current Dev List] Enhancement minor have not tried 2019-09-26 22:33 2019-09-26 22:33
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.7.0.227  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: (select)
Testing: Not Started
Summary: Add option to show grid lines in Panadapter
Description: The panadapter display doesn't presently show grid lines -- there's no Y scale, and no divisions on the horizontal frequency scale. The display might be a bit more readable if grid lines were displayed. Since some users might or might not want this, there should be an option to display the lies (or not).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3467 [3 - Current Dev List] Enhancement minor have not tried 2019-09-26 22:31 2019-09-26 22:31
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.7.0.227  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: (select)
Testing: Not Started
Summary: Add click-to-tune to the panadapter spots area
Description:
When the panadapter window draws spots from the DX cluster window, they're not clickable. The user can click approximately where the spot line is drawn and probably get good results, but it would be nice to precisely tune when the spot name is clicked.

Tags:
Steps To Reproduce:
1) Start Rig Control. Coonect to a panadapter-supported radio.
2) Open a panadapter Window
3) Start Logbook. Database doesn't matter
4) Open the DX Cluster pane and get it connected.
5) Wait a bit to get a few spots
6) Click on them to tune

BUG#1) Can't do so. It would be nice.
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3466 [3 - Current Dev List] Enhancement minor always 2019-09-26 22:29 2019-09-26 22:29
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.7.0.227  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: (select)
Testing: Not Started
Summary: Panadapter spots should age
Description:
The Panadapter plots spots recieved from the DX Cluster window, but doesn't clean them up. They'll just pile up and over-write eachother. The code should be made smarter to remove or add spots depending on their age.

Tags:
Steps To Reproduce:

1) Start Rig Control. Connect to a panadapter-supported radio.
2) Open a panadapter Window
3) Start Logbook. Database doesn't matter
4) Open the DX Cluster pane and get it connected.
5) Wait a while.

BUG#1) When the spots fill up the panadapter, they'll visibly overwrite each other.


Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3461 [1 - Backlog] Enhancement minor have not tried 2019-09-25 10:56 2019-09-26 08:38
Reporter: g3ucq Platform: PC  
Assigned To: OS: Windows  
Priority: normal OS Version: 10 64 bit Home  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: (select)
Testing: Not Started
Summary: add the ability to decode cw signals from the waterfall
Description: Have the ability to decode cw signals from the waterfall as does CWSkimmer.
Tags:
Steps To Reproduce: Now the Panadapter shows cluster spots on the signals.
If it is possible to decode signals on the waterfall can there be an option to turn on/off cluster spots or decodes?
Image showing CWSkimmer in action.
Additional Information:
System Description
Attached Files: cwskimmer.gif (182,026 bytes) 2019-09-25 10:56
https://development.hamradiodeluxe.com/file_download.php?file_id=757&type=bug
Notes
(0008676)
K7ZCZ   
2019-09-25 17:24   
This is a substantial amount of work -- three to six moths, probably. I don't think we have plans to address it at this time. For now, DM780 is the HRD solution signal decoding.
(0008691)
g3ucq   
2019-09-26 08:38   
Yes, Supersweeper can decode CW signals but only from the band width of the cw filter.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2720 [3 - Current Dev List] Bug crash always 2018-05-15 13:04 2019-09-25 18:19
Reporter: K7ZCZ Platform: Intel i7-5960X  
Assigned To: K7ZCZ OS: Windows 10 Professional x64  
Priority: normal OS Version: 16299  
Status: assigned Product Version: 6.4.0.840  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Data
Testing: Not Started
Summary: Logbook: Poor error handling when database opening fails
Description: If the Logbook tries to open a database and that database can't be opened, error handling is very poor. This should be cleaned up.
Tags:
Steps To Reproduce: 1) Setup a data source on a server in the Logbook; SQL Server, Oracle, MySQL, whatever you'd like.
2) Build a logbook database on it
3) Close the logbook
4) Stop the database server
5) Restart logbook
6) The Logbook, at restart, will try to open that database. It can't, since the server is stopped.

BUG#1) The timeout for opening the database is very long; it doesn't need to be. The user sits around and wonders what's happening.

7) An error appears that the database couldn't be opened.

BUG#2) It's pretty hard to understand and isn't completely accurate; "The data source 'MySQLTest1' does not exist. (#2 - Connect = DSN=MySQLTest1)". The data source actually does exist; it just couldn't be opened.

8) The logbook opens a view associated with that database. It's blank, since the connection failed, but the user doesn't know that. This state is pretty bad, since it implies that their data is gone; and allows them to try to do work against a database that isn't connected.

BUG#3) The view shouldn't be opened.


BUG#4) In this state, the logbook isn't at all stable. Eventually, a background task or user action will try to access the broken database connection and cause a crash.

Additional Information:
System Description
Attached Files: HRDLogbook_20180529_162054.mdmp (801,381 bytes) 2018-05-29 11:28
https://development.hamradiodeluxe.com/file_download.php?file_id=410&type=bug
Notes
(0005104)
K7ZCZ   
2018-05-24 13:07   
Addressed with this checkin;
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4132
(0005133)
g3ypp   
2018-05-29 11:28   
On trying to open a second (MySQL) database, logbook crashed and mini-dump produced.
(0005147)
K7ZCZ   
2018-05-29 20:57   
It doesn't look like the provided dump is related to this change. I've opened 2752 to track it.

I don't think that report should block shipping the beta.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1963 [3 - Current Dev List] Bug minor have not tried 2016-11-15 07:27 2019-09-25 15:06
Reporter: KB3NPH Platform:  
Assigned To: K7ZCZ OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Data
Testing: Not Started
Summary: Can't manually log frequencies above 2.3GHz
Description: Ticket #722646

In Logbook, if I hit (+) Add button to add a log entry manually, I am unable to enter a frequency in the upper microwave bands.
The data entry converts what I type in to a nonsense value.
Award tracking allows you to have entries for 6cm, 3cm, and smaller wavelengths to 1mm.
Yet you can't enter frequencies up there.
1300.000.000 is fine
2650.000.000 is fine
3500.000.000 gets mapped to 1630.032.704 which is total nonsense
5925.000.000 same nonsense
10368.100.000 gets converted to 1778.165.408 nonsense
24250.000.000 gets converted to 2775.163.520 nonsense
47000.000.000 becomes 4050.327.040 nonsense

You can also try 3.500.000.000 for example, and it converts to nonsense.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0003190)
K7ZCZ   
2017-06-03 21:31   
The limit is at 2147483648 Hz, which is 2**31 - 1, which is the limit of a signed 32-bit integer. I'll see if I can figure out where we're using this data type and see what we can do ...
(0003192)
K7ZCZ   
2017-06-04 11:32   
Bad news for this one: it turns out that the limitation is essentially system wide.

1) The database is created to store frequency in a NUMBER (limited to 2^31), and should use a LONG NUMBER (with a limit of 2^63).
2) The Frequency edit control is declared to produce and store a UINT (limited to 2^32) and should use a UINT64 (with a limit of 2^64).
3) Might be an issue in XML data exchange, too, but fixing #2 would fix most of the issue with that.

This is a pretty big change, since fixing it means changing the database schema. Certainly, the team has done this before -- what mechanism do we have for migrating database schema between versions of the product, so upgrading users have their database rebuilt with the correct schema?
(0004913)
K7ZCZ   
2018-04-30 23:51   
Partially fixed with this checkin; still a lot more work to do.
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4067
(0004992)
K7ZCZ   
2018-05-10 19:44   
Here's what I can think of:

1) Find all places where input is accepted from Frequency Edit control. Widen it to 64 bits.

2) Repair, rewrite, or wrap locations where 32-bit frequencies are passed with Windos messages. This will probably be the most difficult (error prone) area, since the late-bound nature of Windows messages makes it hard to get compiler verification of changes.

3) Widen communication between app components (most notably, XML files) to be sure that 64-bit values are transferred correctly.

4) Widen the Frequency and RxFrequency columns in the database. code that creates the QSO table uses FLOAT or INTEGER depending on the database vendor type (INTEGER for Access and MySQL, FLOAT for others). There is no existing schema migration code in the product applicable to this issue. We should have it for the general case.

5) Verify that comparisons and tests against frequences (bands, awards) are functioning

6) figure out how 64-bit frequencies are sent to radios; any SDRs support high frequenceis, for instances? Down converters?

Each is a couple days work, execpt for 4, which is a substantial project.
(0005170)
WA9PIE   
2018-06-01 13:20   
Verified by NT9E (one of the requesters).
(0005191)
WA9PIE   
2018-06-03 21:32   
After hearing from Mike (K7ZCZ), it seems that the Requester was incorrect when he validated this.

As a result, I'm reopening it and putting it back to Assigned status in the Current Dev project.
(0005211)
K7ZCZ   
2018-06-05 18:13   
I think that comment #4992 above enumerates most of the work that needs to be done to fully fix this issue.
(0007029)
K7ZCZ   
2019-01-19 10:27   
This checkin widens a couple of frequency formatting routines to accept 64-bit integers:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4739
(0007900)
KC7FPF   
2019-05-01 09:26   
I went through and setup and added a frequency range as suggested by Tim. Once this was accomplished. I got the same result as the customer.

Also reference ticket 685859
(0008409)
PD9FER   
2019-08-15 03:57   
Ticket #208701also marked for this Mantis issue
(0008657)
K7ZCZ   
2019-09-25 08:28   
In the team call on 2019-09-19, this issue was identified as not a priority. Note, though, that with the resolution 3181 and some of the previous check ins, this work is mostly complete.
(0008672)
KB3NPH   
2019-09-25 15:06   
If work towards a resolution has already been done, of course we don't want to discontinue working on this. Our discussion during the 2019-09-19 call again was for Mike B to set his own priority level on this. Since 3181 has been resolved and has brought us closer to a total resolution on this, it's ridiculous to halt all work on this, especially if it's noted that other issues can put us in a position to totally resolve this problem in the very near future. Our discussion on this also noted that the majority of the complaints about this issue came from European stations.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1828 [3 - Current Dev List] Enhancement feature N/A 2015-11-22 00:07 2019-09-25 08:36
Reporter: WA9PIE Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Awards
Testing: Not Started
Summary: Provide an option to use pre-defined list of US States or a user-entered list
Description: Because the US States pre-defined, we are prevented from using the same fields for creating other awards that refer to "secondary administrative areas" (in Canada, Provinces... in Russia, Oblasts... in Japan, Guns... and so on).
Tags: ParityGap
Steps To Reproduce:
Additional Information:
Attached Files: Pre-defined Lists.png (19,779 bytes) 2018-03-25 21:21
https://development.hamradiodeluxe.com/file_download.php?file_id=306&type=bug
WorkedAllCanada.xml (1,993 bytes) 2018-03-25 22:07
https://development.hamradiodeluxe.com/file_download.php?file_id=307&type=bug
FilterExample.PNG (41,451 bytes) 2018-03-25 22:23
https://development.hamradiodeluxe.com/file_download.php?file_id=308&type=bug
Primary Administrative Subdivisions.docx (62,892 bytes) 2019-02-17 11:03
https://development.hamradiodeluxe.com/file_download.php?file_id=691&type=bug
Primary Administrative Subdivisions v2.docx (64,311 bytes) 2019-02-19 20:33
https://development.hamradiodeluxe.com/file_download.php?file_id=692&type=bug
Notes
(0000674)
WA9PIE   
2015-11-22 00:11   
The awards def builder already has the ability for users (or me) to enter a list of "things". In this case, "things" would be a list of "States"... for the purpose of creating awards that use "secondary administrative areas" (in Canada, Provinces... in Russia, Oblasts... in Japan, Guns... and so on).
(0004575)
WA9PIE   
2018-03-25 21:21   
I'm adding an image that provides more information. The request was to offer an option to ignore the predefined lists. This button has no effect on the result.
(0004576)
WA9PIE   
2018-03-25 21:49   
By the way, I'd prefer that there are no pre-defined (hard-coded) lists. But no one else could figure out how to make DC part of MD for WAS. If there's a way to do that in the hand entered list of things in the awards def, I'd be happy to rewrite the few that use them.
(0004577)
WA9PIE   
2018-03-25 22:07   
(Last edited: 2018-03-25 22:11)
Here, I'm uploading an award definition file for Worked All Canada.

When this is used, it should be counting Canadian Territories by two-letter abbreviation... rather than using the US States list. It's almost like it's ignoring both frankly and not counting anything.

But you can import this one... and see that it doesn't work... as long as you have Canadian QSOs in your log where State is populated with AB
BC
MB
NB
NL
NS
NT
NU
ON
PE
QC
SK, or
YT

(0004578)
WA9PIE   
2018-03-25 22:23   
Take Ontario for example. The award def that I created shows zero (for all). But on 80m, based on this screenshot, I know I have five Canadian (DXCC=1) QSOs on 80m where COL_STATE=ON.
(0006780)
K7ZCZ   
2018-12-21 10:27   
Needs design work and clarification, so assigning this back to MikeC
(0007416)
WA9PIE   
2019-02-17 11:03   
I have added a more detailed description of the design requirements in the attached document.
(0007435)
K7ZCZ   
2019-02-19 20:33   
I've added some notes here.
(0008108)
WA9PIE   
2019-06-16 17:31   
Reading your notes, I'll put my responses here (due to the problem with attaching files right now):

It's not necessary for us to define Canadian Provinces, Guns, Oblasts... etc. We could... but that's a never-ending game. The requests will never end.

The intention of the changes we make here should enable the "Ignore Predefined Entries" box to work.

When it's unchecked, it works as designed.

When it's checked, it's not ignoring the predefined entries. As such, no one (me, other users, etc) are able to input/use their own list of "Primary Administrative Subdivisions." This can be validated with steps.

The list from 2018-03-25 22:07 can be used to test this when the box is unchecked using a log that has entries where "State" (aka. "Primary Administrative Subdivisions") are populated with Canadian provinces/territories.
(0008112)
K7ZCZ   
2019-06-16 23:20   
The repro steps are incomplete, as far as I can tell. It seems like they must provide a reference database that does (or doesn't) match the supplied province abbreviations. Is such a database available?
(0008120)
WA9PIE   
2019-06-17 14:23   
(Last edited: 2019-06-17 18:18)
Here are complete steps. I can also provide the exported awards definition:

Let's attempt to create a simple Canada awards report. These are the steps that users will take in order to create a custom report using COL_STATE:
- Launch Logbook with a log that has Canadian QSOs in it (a WA9PIE log could be used)
- Click the "Awards Tracking" tab
- Click "Definitions"
- Click "Add"
Unless specified in these steps, all other options remain at default values:
- Give it a name in the Title field: "Canada Award"
- Change "Main Field to display" to: "COL_STATE"
- In the text box below that labled "All fields:", paste the following list of the 13 Canadian Provinces and Territories:

ON
QC
NS
NB
MB
BC
PE
SK
AB
NL
NT
YT
NU

The user, or whoever is managing the award, will provide a list or a file with the valid values for COL_STATE here.

- Check the box that says, "Ignore Predefined Entries."
- Under "Definition", click the "DXCC Filter" and give it a value of 1 (for Canada)
- Up top, click "Add"
- Click the "Years" button and give it a starting date of 1/1/1945 at 12:01 AM (just to go way back)
- Where it says "Labels", type "Mixed"
- Click "Ok"
- Up top, click "Add" (again)
- Click the "Bands" button and select 160, 80, 40, 30, 20, 17, 15, 12, 10, 6"
- Click "Ok"
- Click "Ok" to close the award definition dialog box and save the award.

Then view the award.

If you get the same results I get, the award will be completely empty, but will show 13 entities needed.

What I can only assume is that the award is looking for DXCC=1 (Canada) and is looking for the predefined list of US States among the QSOs in Canada. (Obviously, I can't prove that. But I do have a log full of Canadian QSOs where the State field is filled with valid two-letter abbreviations for Canadian Provinces or Territories.

The option to "ignore predefined entries" isn't working.

(0008658)
K7ZCZ   
2019-09-25 08:36   
These steps seem dependent on some pre-existing database records being present (or not present?) It also includes vague instructions, like "if you get the same results I get" ... but doesn't clearly describe what those results are, or what they might mean.

If we want to move forward by writing code directly instead of writing a specification, I can try that -- but I do need the reference database and will probably have further questions. I might be able to take a cut at implementing the request, but I'm not perfectly comfortable doing so because I don't think we have a particularly crisp definition of what the feature is meant to do.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3453 [1 - Backlog] Bug minor always 2019-09-24 10:26 2019-09-24 10:26
Reporter: KB3NPH Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Functional
Testing: Not Started
Summary: Can't filter logbook according to "Time on / Time off" fields
Description: Ticket #977094 reports a bug that when attempting to use the filters in the HRD Logbook, when he selects the "Time on" filed, it provides a way to select a date from a calendar dropdown, but doesn't permit entering an actual time such as "10:30;10" as a filter value to search the log for.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: 2019-09-24_11-23-48.jpg (219,764 bytes) 2019-09-24 10:26
https://development.hamradiodeluxe.com/file_download.php?file_id=753&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3241 [1 - Backlog] Bug major always 2019-03-09 12:51 2019-09-22 02:58
Reporter: k2ie Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Awards
Testing:
Summary: WAS Award Granted by Band Not Reflected in Tally
Description: I recently obtained the ARRL 160 WAS Award and set about to update my QSOs to show that award credit was granted. After updating about 20 QSO, I went back to the Awards tally screen for WAS. The number of Granted for the 160 WAS award had not incremented despite the updates. I closed the Award tab and did a database refresh, then went to review the tally once more and it still had not changed.
Tags:
Steps To Reproduce: Update some number of QSOs that are for 160m contacts. Mode does not matter.
To update, do the following:

Select record to be updated
Select the Award tab while in Modify mode
Check off WAS Band on the Granted side of the screen
Select Update

Do this for some number of records and then

Open the Awards Tracking tab by selecting the button
Select the ARRL WAS (HRD) award
The records that you just updated ought to be included in the Granted column for 160m but are not

Additional Information:
Attached Files:
Notes
(0008575)
WA9PIE   
2019-09-22 02:58   
Right. The problem is that the code we've got only supports updating DXCC granted. We need to add the ability to do WAS granted on download as well. (Submitted also)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3357 [3 - Current Dev List] Enhancement minor N/A 2019-06-15 19:55 2019-09-22 01:23
Reporter: WA9PIE Platform:  
Assigned To: K7ZCZ OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Data
Testing: Not Started
Summary: Create a method to manage operator callsigns (remove "Operator" from the My Station dialog box)
Description: I don't have much on this right now. I do have an image that I'll post.

But I wanted to get this in to at least start thinking about it.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0008092)
K7ZCZ   
2019-06-16 11:04   
This needs a specification and design before it can proceed
(0008099)
WA9PIE   
2019-06-16 17:00   
(Last edited: 2019-06-16 17:01)
- Create a list of operators under - Tools, Configure, Operators.
- The list would be simple - Callsign, Name. Hand entered by anyone who manages the workstation.
- The list can be common to all callsigns in the My Station dialog and can be accessed regardless of which callsign or location is behind used.
- It would be great if the user could change them without digging into a menu to select one... and that the currently selected "Operator" would be shown in main Logbook UI.

I have created a mock-up of how that might look.

Google Drive\\Shared drives\HRD Software\Attachments\OperatorField.png

Thinking it through... we should leave the "Operator" field displayed in the "My Station" tab (per Mantis 0003362).

I don't know if this is a specification or not... but let me know if more information is required.

(0008131)
K7ZCZ   
2019-06-18 13:08   
I can't say that I fully understand the impetus of the change. I'd really prefer to start with "Why" so I can understand what problem it is I'm being asked to solve. If you'd rather, I can just do what you say iteratively. But I think that approach minimizes my ability to contribute.

Let me know how you'd like to proceed. Either way, it seems like this change deserves at least more care in its design.

For now, here are the questions I have:


  • For now, I guess that the selected operator is used whenever the operator field from the selected "My Station" location and call sign would've been sued. Is that correct?

  • In other UI (like the "My Station" tab of the ALE, or the "My Station" editing dialog), what is displayed? Is the "My Station" setting simply removed, or is it offered there -- how? Can it be changed?

  • Seems like a user might creating a QSO in the ALE, then wonder what "Operator" value was going to be used. They'd have to move the ALE, look back at the main window, and check the setting there. Why not display and allow the selection of the operator from the ALE window directly?

  • Since the instructions here say the operator is displayed in the logbook's main window, it must mean that the operator is somehow associated with the operations that can be done in the main window of the logbook. What operations are those, and how does the selected operator specifically affect them?

(0008132)
WA9PIE   
2019-06-18 19:26   
Let me try to expand on this...

Think of this as a hierarchy. That is...

Customers have callsigns,
Callsigns have locations,
Locations have Operators.

Each of these can have a 1:many relationship.

So we have a method of associating a customer to callsigns as tabs in My Station. That works.

Callsigns have locations in the My Station tab. That works. The location contains the details of a station. That works.

The problem is with the way that “Operators” are handled.

A Station could have many “Operators” and some clubs absolutely will.

In the past, that caused someone to create an additional “location” or to edit “Operator” in My Station each time a different Operator made QSOs from the Station.

It would be far more elegant to provide a way to manage a list of “Operators” and give the user an easy way to change the operator without constantly going back to the My Station dialog to do it or creating a redundant location for each operator.

All that’s really needed is a way to change which operator is associated with a given QSO.

Does that help?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3256 [3 - Current Dev List] Bug minor have not tried 2019-03-21 15:36 2019-09-20 23:30
Reporter: K7ZCZ Platform:  
Assigned To: K7ZCZ OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: All
Sub-Module: Appearance/UI
Testing: Not Started
Summary: What is the minimum screen size (in pixels) that HRD supports?
Description: Seems like some users expect to run HRD on very small monitors. However, we know that HRD doesn't scale well -- it doesn't include code to manage layout or content to smaller screen sizes.

We don't actively test or design with any specific display size in mind.

It would help to identify a minimum screen size (in pixels) which we support. By clearly communicating this to customers, we'll set their expectations; we'll also establish our own guideline for development and testing. Maybe we don't need to implement any scalying or layout code -- or maybe we do need to approach that issue.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0007716)
K7ZCZ   
2019-03-21 15:38   
In the triage call on 2019-03-21, we identified this issue and you agreed to evaluate the issue.
(0007717)
K7ZCZ   
2019-03-21 15:40   
The related issues show a couple of cases where the HRD UI becomes cumbersome on smaller screens.
(0008401)
WA9PIE   
2019-08-13 22:13   
I was testing our apps with a variety of pixel dimensions today. What I found is this...

The one thing I could find that I didn't like that was affected by the pixel dimensions was that when the width is less than about 1234 pixels, the "ribbon bar" above the logbook database view goes from one row to two rows (I have no other means to describe this, but it's the bar that has Add, Contest, Delete, View, Cut, Copy, Paste... LOTW Upload, LOTW Download). When this happens, then vertical screen real estate is consumed and (I think) it makes using the program a bit more awkward. (Too bad users can't add/remove buttons from that bar.)

Are we trying to define (a) minimum requirements or (b) a recommended minimum?

If (a), then we're saying that the software will be configured so that it will not run on machines with less than the "minimum requirements?"
If (b), then there's more flexibility if we're telling customers that this is what we "recommend."

That said... it appears to me that 1280x800 would be the appropriate screen size. I'm just not sure we need to force that and prevent the software from running if it doesn't meet that minimum.
(0008558)
K7ZCZ   
2019-09-16 19:50   
Right now, we have no design guidance for the product. If we wanted to invent new or change existing UI features, how tall or wide can that UI be? We don't know. I don't think (a) or (b) helps that issue.

Once we have a limit, we can enforce it however we see fit. Further, we should test to make sure we adhere to that limit -- that the product does correctly and adequately work on displays of that size (and larger).

Once we commit to that work, then we should probably implement a hard limit and not allow the applications to start when on a screen that doesn't meet the required colour depth and size.
(0008569)
WA9PIE   
2019-09-20 23:30   
My guidance is that the minimum screen size (in pixels) that HRD should support is 1280x800.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3450 [3 - Current Dev List] Maintenance minor have not tried 2019-09-16 09:07 2019-09-16 09:07
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.7.0.226  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: SW License Mgmt
Sub-Module: SW License Client
Testing: Not Started
Summary: Most license types are unused, could be removed and code simplified
Description:
The new license manager seems to only support two license types; HRDLIC_PERMANENT and HRDLIC_FREETRIAL. Maybe one or two more are needed, but the 15 different licesne types in the LIC_TYPE enumeration are mostly unused.

If they can be eliminated, then the implementation of several license manager functions can be simplified, maybe some can even be deleted.

I'm particularly worried about the HRDIsValidLicense() function, which does a ton of heinous date-based math. This code has no comments, no explamation of the business logic, no definitions for the dates it used. (What happened on 2013-02-08? What happened a month later?)

Also note that there are at least three bowls of copy-pasta which implement case statements that convert an HRDLIC_enum to a string. We should consolidate these to one function, whihc heopfully only supports a couple of enum values.
Tags:
Steps To Reproduce:
1) Search the code for "Free Trial" (including quotes) There are six hits.

2) Search the code for "HRDLIC_DEVELOPMENT". Only two hits, both redundant with other license type in a switch statement.


Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3448 [3 - Current Dev List] Maintenance minor have not tried 2019-09-16 09:05 2019-09-16 09:05
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.7.0.226  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: All
Sub-Module: (select)
Testing: Not Started
Summary: common locator (grid square) code doesn't reliably handle lower-case
Description:
CLocator::CheckValidValidator() doesn't accept locators that contain lowercase letters. "CN87VN" might be acceptable, but many people put the last alpha pair in lower-case as "CN87vn". Since other CLocator functions handle lower case, CheckValidValidator() should to.


Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3101 [3 - Current Dev List] Bug minor always 2019-01-26 06:49 2019-09-14 02:15
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.187  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Satellite Tracking
Sub-Module: (select)
Testing: Not Started
Summary: The Satellite Tracker app provides an incorrect links to information about IO-26
Description: Both links provided by the application are 404
Tags:
Steps To Reproduce:
1) Start up Satellite Tracker
2) In the "Satellite Definitions" tab, use the "Enable All" button to enable all satellites
3) In the main window's toolbar, use the drop-down arrow next to the "Help" button
4) The resulting menu has an "IO-26" tear-off. Click the "AMSAT-italy" command in that menu

BUG#1) I end up with a page that doesn't have much to do with satellites. Looks like ti's about search engine optimization. I don't think this is the right page. The URL I see is http://www.itamsat.org/

5) Use the "AMSAT" link in the same IO-26 tear-off menu

BUG#2) Goes to a 404 landing page at Amsat.org. This is the URL I see: https://www.amsat.org/amsat-new/satellites/satInfo.php?satID=50&retURL=/satellites/status.php

Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3111 [3 - Current Dev List] Bug minor always 2019-01-26 17:51 2019-09-13 08:06
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.184  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: FT-891 IF shift can't be turned on or off using Rig Control
Description:
Rig Control doesn't offer a button to toggle IF shift setting on or off. Such a setting would emulate the radio's "SFT" soft-button on the front panel.
Tags: FT-891, Yaesu
Steps To Reproduce: 1) Fire up Rig Control
2) Connect to the FT-891
3) Use the "View" menu to reach the "Customize" tear off, which has a "Customize layout" command
4) Select the "Layout" tab
5) CLick any button
6) In the customize dropdown, there's no choice that will turn the IF shift feature on or off.
Additional Information: Note that the documentation for the radio is incorrect. The IF shift feature is enabled or disabled with an extra, undocumented character in the "IS" command.

Set Command = "ISabcdddd"

where:
   a = 0, always
   b = 0 to turn IF shift off or 1 to turn IF shift off
   c = + or - sign. send + with 0000
   dddd = four-digit frequency offset "-1000" for -1000 hertz, "+0030" for +30 hertz
   
Get command = "IS0"

Get response = "ISabcdddd"

where:
   parameters are as above
Attached Files:
Notes
(0008542)
PD9FER   
2019-09-13 08:06   
Ticket #213820 related?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3447 [1 - Backlog] Enhancement feature have not tried 2019-09-12 10:11 2019-09-12 12:37
Reporter: KB3NPH Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Interfacing
Testing: Not Started
Summary: Support for MSHV Logging to HRD Logbook
Description: OSTicket #919687 - As reported on the various help and peer forums, there is a logging issue between MSHV (http://www.lz2hv.org/mshv). MSHV is a widely used data programme used for VHF and HF data modes. For VHF operators it has a distinct advantage over WSJT in that it runs FSK441 and MSK441 under the same umbrella (1 programme) wheras to run or switch between these in WSJT, you have to switch between WSJT-X and WSTJ. I also think that MSHV tends to decode weak signals better than WSJT, but this is just a personal thing? Anyhow, WSJT & WSJT-X logging to HRD works perfectly, but no such luck with MSHV. This appears to be down to a problem within HRD - I am not a computer geek, but something to do with not being able to alter the receive destination???? Is there any progress on fixing this issue? I would like to think I could use my HRD to accept log inputs from MSHV? Apparently, No problems with MSHV, and some of the rival programmes to HRD such as N1mm, and Logger32+. Best wishes Andy Adams
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3446 [1 - Backlog] Bug major always 2019-09-11 07:22 2019-09-11 07:25
Reporter: KB3NPH Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Satellite Tracking
Sub-Module: Functional
Testing: Not Started
Summary: While setting frequency for SSB/CW transponder satellites Doppler tracking will not continue
Description: OSTicket #979923 When attempting to select the frequency of a non-repeater satellite signal, when you manually tune in a signal using the tuner on the radio, once you set the frequency, within a second or two the doppler tracking reverts back to the frequency being tracked before you manually tune the radio.

Here are the instructions for how this feature is supposed to work. These documents are within the program itself, and can be found by Open HRD Satellite, Select OPTIONS, Select MANUAL TUNING. Once you have selected the new frequency on the radio's dial, the dropdown box on the Manual Tuning options allows you to return to doppler tracking x amount of seconds. The doppler tracking then resumes from the NEW frequency selected on the radio dial.

What is actually happening is instead of resuming doppler tracking from the NEW frequency selected on the radio's tuning dial, the software reverts to tracking from the frequency that was in the radio's display PRIOR to making the manual adjustment.

Tags:
Steps To Reproduce: Here are the instructions on how this option is supposed to work, which is included in the help on the options page in the software.

Manual Tuning Delay
When the Auto-detect option in the Tuning Dial is enabled the software automatically detects when you change the frequency on your radio.

When a change is detected Doppler updates are suspended for the interval selected below. When the interval expires the radio frequency is read into the software and Doppler updates resume.

While manual updates are in effect a progress bar is displayed, this 'counts down' the remaining interval before Doppler correction resumes.

Select the interval (in seconds) below. (in the program below this statement is a dropdown menu that allows you to select 1, 1.5, 2. 2.5 and 3 second delay at which point the program resumes doppler tracking from the point selected by the manual tuning of the radio.
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3445 [1 - Backlog] Bug minor always 2019-09-10 09:39 2019-09-10 09:39
Reporter: PD9FER Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Rig Control
Testing: Not Started
Summary: VFO and Sub abnomalities
Description: Customer has a Kenwood TS-2000
When selecting VFO A and SUB, there is no frequency control

When Selecting VFO B and SUB, the frequency can be changed but snaps back.
This is happening with the real radio as well as the Demomatic TS-2000
Tags: Kenwood, TS-2000
Steps To Reproduce: Start Rigcontroll
Select Demomatic and TS-2000
Select VFO A and Main
Tune with the mouse the frequency > OK
Select Sub
Tune Frequency again... > Faill

Select VFO B and Main
Tune with the mouse the frequency > OK
Select Sub
Tune Frequency again... > Frequency snaps back and alters every 3 seconds
Additional Information: Ticket 507399

A video is placed in the Mantis ID# folder in Dumps on Google Drive
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3390 [1 - Backlog] Maintenance minor always 2019-07-13 11:17 2019-08-29 15:56
Reporter: PD9FER Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: DM780
Sub-Module: Various
Testing: Not Started
Summary: MT-63 in Digital Master has a fixed 1000hz center frequency, Making it unusable for MARS opperations
Description: DM-780 has a fixed center freq at 1000hz
MARS uses MT-63 center freq 1500hz
This makes DM-780 unuseable for MARS
Tags:
Steps To Reproduce: In Digital Master Select a MT-63 mode.
Try to change the Center Freq
You will notice it stays at 1000hz
This while MARS uses a 1500hz center

Additional Information: Ticket #747337
Suggestion to add 1500hz as an center frequency option
Attached Files:
Notes
(0008468)
K7ZCZ   
2019-08-29 15:56   
In the 2019-08-29 call, we reviewed this issue and the related issue ... and it seems like these requests would be addresed by allowing teh center frequency to be freely set by the user rather than fixed at a particular frequency. In this way, any variety of MT-63 schemes can be supported.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2635 [1 - Backlog] Bug minor always 2018-03-29 06:45 2019-08-29 15:53
Reporter: PD9FER Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: DM780
Sub-Module: Functional
Testing:
Summary: Digital Master MT63 snaps to old possition
Description: When attempting to change the marker for the main frequency using MT-63, 1000, long from 1000 to 1500, upon releasing the mouse button it snaps back to 1000 hz. If I adjust the vfo up 500 hz it decodes the message fine
Tags:
Steps To Reproduce: Open Digital Master
Select MT63 mode (does not matter witch one)
Try changing the frequency by clicking in the waterfall
Notice it snaps back to it's original position.

Additional Information: Ticket #262558
PSR file attached
Attached Files: mt63.zip (1,770,419 bytes) 2018-03-29 06:45
https://development.hamradiodeluxe.com/file_download.php?file_id=312&type=bug
Notes
(0004601)
PD9FER   
2018-03-30 11:59   
Probably not a Bug,
pse confirm

(Comment from Tim: The Center Marker will never work for on DM center freq 1500 your M marker will not move over in MT63 mode. MT63 is a fixed bandwidth mode and only centers on I think it is 1500 or 2000 HZ due to it's bandwidth.)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1697 [1 - Backlog] Bug minor sometimes 2014-08-13 20:03 2019-08-29 15:53
Reporter: user36 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: DM780
Sub-Module: Various
Testing:
Summary: DM-780 - MT63 does not appear to decode properly
Description: Signal appears to lose sync, causing inability to decode.

I have been using the 6.1 version of DM780 with absolutely no problems with any mode or frequency.
I upgraded to the latest version and very happy except for DM780. 99% of my digital is on Army & Navy MARS frequencies,
& mostly MT-63 2k-long. I have made no changes other than updating my HRD to 6.2.
When receiving MT-63 I can hear a strong signal, it shows in the waterfall & the signal strength in the squelch window goes past half way,
AFC is on, I can hear no change in the signal, a few characters are printed but then the bar in the squelch window goes to all the way to the left ( to zero)
and never comes back. There is another MARS member that has the exact same problem.
Please help.
Thanks for your time,
Jack
ka4bix
Florida Navy Marine Corps MARS
nnn0iic
nnn0gal5
Tags:
Steps To Reproduce:
Additional Information: MT63 requires sync. Possibly need to ensure that sound card is calibrated similar to methods used for SSTV.
Attached Files:
Notes
(0005802)
WA9PIE   
2018-07-25 12:53   
Updating these to Feedback, as all have questions or need re-tested.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
493 [1 - Backlog] Bug minor always 2013-12-21 18:56 2019-08-27 11:39
Reporter: W4PC Platform:  
Assigned To: WA9PIE OS: Windows  
Priority: low OS Version: Win 7 64bit  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Appearance/UI
Testing: Not Started
Summary: Logbook Edit Selections show all Problem
Description: When using the edit selections dialog box the "Show All" selection does not work.
It always defaults back to the amount you have set in the "Maximum" setting.
Tags:
Steps To Reproduce: Just select "show all" and the same amount that's set in Maximum will still be displayed.
Additional Information: I am using Alpha Ver 6.1.0.146 but its not listed in the Mantis Release versions.
Attached Files:
Notes
(0000083)
WA9PIE   
2013-12-24 22:19   
Changing status to "New" until we confirm that this is a bug or a trouble ticket.
(0003050)
WA9PIE   
2016-12-03 17:26   
I have no idea what "Edit Selections" is supposed to do.
(0003116)
WA9PIE   
2017-03-05 22:09   
I looked for this in 633 and I can't even find it.
(0005243)
WA9PIE   
2018-06-11 23:46   
Wow... this took quite a long time to understand. Yeah, it's broken... but doesn't seem like a very useful feature either.
(0007707)
PD9FER   
2019-03-19 04:58   
Ticket #854108
Right clicking on any item on the list will open a 'Logbook Selections' window where it is possible to create new, or modify
old selections (or delete not needed ones).
The new "Selections" I create do not work and actually cannot be saved as specified.
(0008405)
PD9FER   
2019-08-14 08:51   
New ticket 629520
(0008408)
g3ucq   
2019-08-14 15:03   
Via G3UCQ.
"I noticed you updated Mantis 0000493 today. This issue is related to Mantis 0003191.
The Logbookquries.xml file gets corrupted if you attempt to edit / save it. It has been like this for a number of releases although it has worked previously.
Regards
David G4NVB "
(0008415)
g3ypp   
2019-08-17 10:58   
I've never used this function but just had a little play. I set up a filter to display only the logbook entries from a previous QTH with the QRA square IO92ua. This locator is set in the "My Station" parameter for those QSOs.

This new filter appears to save OK but does not work - it still displays all contacts in the logbook when run.
On inspection of the "LogbookQueries.XML" file which stores all of these filters I can see that my new filter has been saved in the file BUT the filter parameters in the relevant search line are blank

<Match Date2="0.00000000000000000000" Date1="0.00000000000000000000" DateMatchType="5" EnableDate="0" Logic="0" Type="0" Enable="0"Match="" Field=""/>

The rest of the file is not corrupted (an earlier comment mentioned a corruption) but the new filter is not saving all of the data.
(0008454)
KC7FPF   
2019-08-27 11:39   
Had a other inquiry about this issue. Noted from customer that if Selections are executing no problem. However it you modify one it does not work correctly. It reports the whole log.

Also If you create or (add) a new one in-op.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3440 [3 - Current Dev List] Enhancement minor always 2019-08-26 14:27 2019-08-26 14:27
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Call lookup
Testing: Not Started
Summary: Text View of Callsign Lookup test could have clearer representation
Description:
The text view of the call sign lookup results is kind of a dump of the list control. It would be a bit nicer to have a clearer representation of the results, including the ordering and the value decisions.
Tags:
Steps To Reproduce: 1) Start up the logbook; no particulary database needed
2) Use the "Callsign lookup" command in the "Config" tear-off in the "Tools" menu
3) Activate the "Test" tab in the resulting "Callsign Lookup" dialog
4) Enter a call sign, anything valid is fine
5) Press the "Lookup" button
6) Wait for the lookup to populate
7) Press the "Logfile" button

BUG#1) The text representation of the results isn't particularly clear

Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3438 [3 - Current Dev List] Bug minor always 2019-08-26 14:26 2019-08-26 14:26
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.208  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Appearance/UI
Testing: Not Started
Summary: Logfile view tab in Logbook is missing an icon
Description: We don't have artwork for the "Timing" button in the toolbar in the Logfile view tab.

Tags:
Steps To Reproduce:
1) Start up the Logbook. No particular database is needed
2) Use the "Logfile" command in the "View" menu
3) In the resulting "Logfile" tab, examine the toolbar

BUG#1) The "Timing" button has a text label only, no icon

Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3436 [1 - Backlog] Bug tweak always 2019-08-22 09:48 2019-08-24 13:17
Reporter: KC7FPF Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: ALE Window
Testing: N/A
Summary: Save VFO B (sub-Frequency) in the database)
Description: The "Save VFO B (sub-frequency) in the Database" is checked in the Options drop-down in the ALE window.
You create a new QSO and save it. The VFO B freq. is added to the database.
The "Save VFO B (sub-frequency) in the Database" is Un-checked in the Options drop-down in the ALE window.
The QSO record is opened and updated without making any changes. HRD deletes the VFO B freq.
IMHO a good program never deletes data unless it specifically directed to do so. My recommendation is:

Whenever the "Split" option is active in the radio, save the VFO B freq. to the database. If the split option is not selected, do not save the VFO B freq. And, add the VFO B freq. field to the ALE someplace so it can be edited by the user. As it is now, either the Logbook bulk editor or a third party dB program must be used to fix the Freq(Rx).
Why is this a big issue, you ask? LOTW has to match bands to confirm a QSO. If HRD uploads a VFO B freq that is a different band than the VFO A band, you can't get credit for the QSO. I just spent the better part of a day manually fixing my logbook and LOTW




Tags:
Steps To Reproduce: this is item has been in the HRD logbook as long as I can remember. You have to go into the ALE window/Options.
Once there you have to manually uncheck
"Save VFO B (sub-Frequency) in the database) If this is checked when you upload to LOTW it will come back with an error.
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2577 [1 - Backlog] Bug major always 2018-03-07 08:37 2019-08-24 13:17
Reporter: k2ie Platform:  
Assigned To: K7ZCZ OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: ALE Window
Testing: Not Started
Summary: Frequency RX is blanked from existing log entry when updating record
Description: There is a logbook field called Frequency RX that is optionally recording during a split frequency QSO as long as the ALE Save VFO B option is checked. Data is also recorded in this field if an API insert submits it. However, if the record is later updated for any reason (QSL info or qrz.com update are 2 possibilities), the Frequency RX data is wiped out UNLESS Save VFO B is checked.
Tags:
Steps To Reproduce: 1. Log a QSO with split RX/TX frequencies.
2. Verify using the log view that both RX and TX frequencies have been recorded. You'll have to add Frequency RX to the layout.
3. Update the QSO after making some trivial change.
4. Verify using the log view that the Frequency RX field for that record is now blank.
Additional Information: Discussed in Beta Forum thread: https://forums.hamradiodeluxe.com/node/45218
Attached Files:
Notes
(0004449)
g3ypp   
2018-03-07 09:48   
I can replicate the reported bug
BUT also noted that when operating simplex, the same frequency is recorded in both columns ie "Freq" and "Freq(Rx)" irrespective of the frequency or band set on the sub VFO, VFO B whatever you want to call it.
The 2 entries are only different when I operate in "Split".
But in Split mode the "Freq" column contains the Rx frequency, and the "Freq(Rx)" column contains the Tx frequency. This is about face as they say.
I have an IC07600 V2
(0005486)
k2ie   
2018-06-25 14:51   
See also 1608 and 580.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2932 [3 - Current Dev List] Bug minor always 2018-11-02 13:18 2019-08-20 12:39
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.899  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Appearance/UI
Testing: Not Started
Summary: Logbook: confusing design around "Selection" pane and "Query" settings
Description:

The Logbook's "Display" panel features a "Selection" group. This group incldues a list of queries; some pre-defined, some user-defined and editable.

Turns out the query can be modified by using the "Query" command in the "Logbook" menu. This isn't intuitive, since the name "Query" doesn't seem related to the name "Selection".

The queries can be edited by right-clicking in the "Selection" pane. Editing a specific query there shows the same UI as the "Query" menu choice. The dialog box, via either access path, is titled "Modify Selection".

The choice of "Selection" seems pretty dubious; "Query" is probably a better name. Regardless of what's chosen, the menu command should match the UI title so that there's a visual cue that the command is related to the visible feature.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3433 [3 - Current Dev List] Bug major always 2019-08-16 12:29 2019-08-16 12:29
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.6.0.239  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: