View Issue Details

IDProjectCategoryView StatusLast Update
0003598Ham Radio DeluxeBugpublic2020-02-04 23:38
ReporterWA9PIEAssigned ToDOUG 
Status closedResolutionfixed 
Product Version 
Target VersionFixed in Version6.7.0.262 
Summary0003598: Callsign lookup is not honoring callsign prefixes
DescriptionThis 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.
Steps To ReproduceA 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 InformationYeah, 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
Tags6.7 defects
Sub-ModuleCall lookup
Testing Beta Successful


related to 0003125 closedWA9PIE QSOs with stations that aren't in a valid DXCC country show up in the awards totals for a country and should not 
related to 0002306 closed /MM (Maritime Mobile) QSO added to DXCC Awards count 



2019-11-19 07:50

viewer   ~0009399

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.


2019-11-19 07:51

administrator   ~0009400

Yeah, I saw this "fraction of a second" thing also. It's clearly populating the Country section twice.


2019-11-19 19:36

viewer   ~0009404

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


2019-11-19 21:59

administrator   ~0009405

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 (, HamCall, QRZCQ,, 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.


2019-11-20 08:09

administrator   ~0009431


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.

Callsign Lookup Addition.docx (67,190 bytes)


2019-11-20 08:38

viewer   ~0009432

That seems to cover all options.


2019-11-20 08:39

administrator   ~0009433

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?


2019-11-20 08:44

viewer   ~0009434

As KB3NPH/1 is in the same Country as KB3NPH then I suppose the /1 can be ignored?


2019-11-20 21:15

viewer   ~0009435

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':


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.


2019-11-21 15:00

administrator   ~0009444

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.


2019-11-21 16:29

viewer   ~0009445

The /A suffix in the UK denotes the licensee is operating from an Alternative location, but in the same Country as normal.


2019-11-21 17:47

viewer   ~0009448

Thanks John, then Case 2 should remain as "MM" and "AA" only, and let /A be ignored then.
Thanks, I have learnt something new :)


2019-11-21 18:59

viewer   ~0009449

Corrections to both notes 9435 and 9448 above. I obviously meant "AM" for aeronautical mobile - not "AA".


2019-11-21 19:21

administrator   ~0009450

Thanks, Chris.

Is there a complete list of common suffixes? I figure we should try to include the ones we know of.


2019-11-21 19:38

viewer   ~0009452

I found this on Wikipedia (

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.


2019-11-21 19:52

administrator   ~0009453

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.


2019-11-27 01:03

developer   ~0009457

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)


2019-11-27 12:12



2019-11-27 12:12

administrator   ~0009458

Last edited: 2019-11-27 12:13

View 2 revisions

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


2019-11-27 15:22

viewer   ~0009459

VK4/WA9PIE gives Australia as the Country. Great work.


2019-11-27 15:26

viewer   ~0009460

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.


2019-11-27 16:27

developer   ~0009461

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?


2019-11-27 19:45

viewer   ~0009462

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.

Country Lookup Test Results.xlsx (13,926 bytes)


2019-11-27 19:55

administrator   ~0009463

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.


2019-11-27 21:15

administrator   ~0009464

After dong some testing - manually creating a Country called "None" with a DXCC value of 0...

The 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.)

Suffixes That Do Not Count for a DXCC Country.docx (75,919 bytes)


2019-11-27 21:33

administrator   ~0009465

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?

BearingDistance.PNG (23,952 bytes)
BearingDistance.PNG (23,952 bytes)


2019-11-27 23:18

viewer   ~0009466

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.


2019-11-27 23:22

administrator   ~0009467

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


2019-11-27 23:26

viewer   ~0009468

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.


2019-11-27 23:31

administrator   ~0009469

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.


2019-11-27 23:34

viewer   ~0009470

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


2019-11-28 00:01

administrator   ~0009471

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.



2019-11-28 03:18

viewer   ~0009472

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


2019-11-28 08:43

viewer   ~0009473

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.

HRD6_7_0_254_Prefix.JPG (129,054 bytes)
HRD6_7_0_254_Prefix.JPG (129,054 bytes)


2019-11-28 08:48

viewer   ~0009474

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.


2019-11-28 08:57

viewer   ~0009475

Ditto as per John in 9474. It works with a number in prefix.


2019-11-28 11:22

administrator   ~0009476

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


2019-11-28 12:12

administrator   ~0009477

Last edited: 2019-11-28 12:14

View 2 revisions

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


2019-11-28 19:09

viewer   ~0009478

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.


2019-11-30 21:35

developer   ~0009480

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.


2019-11-30 21:57

administrator   ~0009481


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.

Callsign Lookup Addition v2.docx (130,314 bytes)


2019-11-30 22:08

administrator   ~0009482


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.


2019-12-01 03:33

viewer   ~0009483

Not fixed for me in EA/G3UCQ shows England but EA1/G3UCQ shows Spain.


2019-12-02 10:13

viewer   ~0009486

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.


2019-12-08 14:53

developer   ~0009491

Just kicked off the build that will add a number to prefixes without one.


2019-12-08 15:20

administrator   ~0009492

I've posted the build up for us to test this issue with.


2019-12-08 19:55

viewer   ~0009493

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


2019-12-09 01:05

viewer   ~0009494

Observations on
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.
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.


2019-12-09 02:17

viewer   ~0009495

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

1-character prefix.jpg (79,288 bytes)
1-character prefix.jpg (79,288 bytes)
2-character prefix.jpg (81,530 bytes)
2-character prefix.jpg (81,530 bytes)


2019-12-09 03:24

viewer   ~0009496

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.


2019-12-09 03:29

viewer   ~0009497

In the Lookup Panel my test callsigns above show correctly but VK9/G3UCQ shows England. (I wish!)
VK/G3UCQ Australia and VK4/G3UCQ


2019-12-09 04:29

viewer   ~0009498

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.


2019-12-09 06:15

administrator   ~0009499

From what I can see, case 3 and 4 are good. Case 1 and 2 still to close.


2019-12-09 07:36

viewer   ~0009500

I am not sure that the rotator distance and bearing are giving correct results.
eg I entered K7BX/VP9. This correctly shows Bermuda with a sensible Lat/Long.
But the distance given is 4763 miles on a bearing of 305 degrees.
My short path distance to VP9 is 3487 miles on a bearing of 276 dgrees

Similarly, F/PB8DX shows France but gives a distance of 3231 miles on a bearing of 2 degrees

Something amiss here.


2019-12-09 09:46

viewer   ~0009501

I confirm G3YPP's observations.
In the ALE lookup K7BX/VP9 gives 271 deg and 3227 miles which is correct.
The Lookup Panel gives 305 degrees and 4763.3 miles.
As for G3YPP with F/PB8DX


2019-12-13 19:47

administrator   ~0009506

I confirmed the observations about the azimuth and distance. I feel like we should have a separate tracking record in Mantis for that.

I'm in the process of going back and reviewing the items left in this doc. Would like to finalize this release before Christmas.


2019-12-14 19:02

administrator   ~0009507

Cases 1 & 2 are still in-progress.

Cases 3 & 4 are complete.

With a new build, we need to verify (a) lat/long and (b) the ability to control the rotor.

Callsign Lookup Addition v3.docx (132,282 bytes)


2019-12-22 22:49

developer   ~0009510

So the distance calculation was due to the lookup panel using a different "MyStation" lat/log setting than the ALE screen, sometimes that other setting was set to 0.0, 0.0, I changed it do use the same as the ale screen. Building the beta now.


2019-12-22 22:57

developer   ~0009511

I also made a pretty big change to the country wildcard parser so that \MM and \AM callsigns would result in "None" country. I had to touch some code that is used all over the place, so we need some testing to make sure existing Country lookups are not adversely effected.


2019-12-25 20:19

administrator   ~0009513

I'm attaching an image here regarding "None".

We should list it in the Country field drop-down as "[None]". Users will need the ability to select it... and they'll need it in the "Bulk Editor" that uses this list of Countries.

It's good to show DXCC=0. The Continent is blank (that's fine). But we should remove Lat/Long when Country = None (DXCC=0).

None.png (110,722 bytes)
None.png (110,722 bytes)


2019-12-26 05:33

viewer   ~0009515

In the ALE, VK4/G3UCQ shows Australia with bearing and distance correctly. GOOD
In the ALE, VK4/G3UCQ/AM shows Country as [None] and no bearings or distance. GOOD
In the Lookup Panel, VK4/G3UCQ shows Australia with bearing and distance correctly. GOOD
In the Lookup Panel, VK/G3UCQ shows DXCC=0 and NO Lon/Lat GOOD
In the Lookup Panel, VK4/G3UCQ/AM shows DXCC=0 but the Lon/Lat is showing. NOT GOOD.
Prefixes without a number; e.g. F/G3UCQ show as France correctly.
Nearly there.
Could we have a list of all callsign combinations that we need to test please?


2019-12-26 08:23

viewer   ~0009516

Mistake above.
In the Lookup Panel, should be - VK/G3UCQ/AM shows DXCC=0 and NO Lon/Lat. GOOD
Add a number to the Prefix, i.e VK4, and the Lat/Lon is displayed.


2019-12-27 05:17

viewer   ~0009517

W4ElP noted in the forum:

Installed tonight and whenever I change bands, either by the radio or by Rig Control, a Digital Master message pops up "Encountered and improper argument". Acknowledge the message and DM appears to go along ok - no crash. But on next band change, same message.
Rebooted, reinstalled 257, same results.
Reinstalled and all is well - no message.

I can replicate this.


2019-12-27 05:23

viewer   ~0009518

Re my comments in #0009500, this is now corrected in .257


2019-12-27 06:51

viewer   ~0009519

works okay for me, no oddities when changing bands also.

Knipsel.JPG (80,192 bytes)
Knipsel.JPG (80,192 bytes)


2019-12-29 05:10

viewer   ~0009520

The Lat/Lon are now being displayed to 14 decimal places in the ALE and Lookup Panel.
2 decimal places should be enough.


2019-12-30 08:04

viewer   ~0009521

I have noticed again ow in versions 256 & 257, the Lookup Window does report previously worked call sign and country information, but after a while, it stops reporting those fields correctly and previously worked info is always "blank". If I shut down Logbook and re-start, the functionality is restored for a period of time and then after awhile, it again reports "blank" for previously worked calls and countries that absolutely were worked before. The Licensee info always appears to report correctly...
Pete - W2PJ


2019-12-30 08:05

viewer   ~0009522

As reported by G3ypp I get the same results...
"Installed tonight and whenever I change bands, either by the radio or by Rig Control, a Digital Master message pops up "Encountered and improper argument". Acknowledge the message and DM appears to go along ok - no crash. But on next band change, same message.
Rebooted, reinstalled 257, same results."


2019-12-30 21:23

developer   ~0009524

The was legacy code that purposely not overwriting the Country lat/long when DXCC was 0. I am removing that code. Let me know if anyone thinks there is a situation where we want to keep that.

This will affect the Logbook and DM lookup pane


2020-01-02 12:49

viewer   ~0009525

Loss of ALE access to previous worked band and mode information in the ALE window is an intermittent problem that develops over time (1-2 hrs) in the Logbook. When it occurs, if you re-start the Logbook, the ALE reports previous contacts for a while, and then stops. Again re-starting the logbook restores the correct function of identifying previously worked QSOs in the ALE window.
It is not clear what is being worked on other than the prefix,suffix look ups, which has slowly been making progress. Previous worked contact issues surfaced with these updates.
I for one would like to see Mantis
0003506: ILGRadio database (New .txt structure is not read by properly by HRD
worked on. I posted the issue back in October. I pay for the ILG Database updates but with the new structure HRD cannot read it properly.
As a Beta Tester with a payed up maintenance license, it would be nice to see some attentions to a basic function of reading the new SWR DB structure provided by ILGRadio. There are few programs that read them, I would not want to have to buy another program just to do that!.

Is there any listed prioritization of what issues and new functionality are anticipated for HRD in 2020?
R & Happy New Year to all!
Pete - W2PJ


2020-01-03 07:25

administrator   ~0009526

I feel like the topic is straying away from what the intended purpose of this thread is all about.

We need to get the callsign lookup function working as it's supposed to. (We can worry about how many decimal places... other matters in the ALE... ILGRadio... and so on when this piece works.) That's what the priority is right now.

For a developer to wade through unrelated comments to sort out what to do to finish this, it's probably difficult. So let's stick to the primary purpose of the topic here.

I'm happy to take up other points in the beta forums.

Mike, VK4/WA9PIE


2020-01-03 09:32

administrator   ~0009528

257 build

Ok... I've run through a battery of tests. To John's point, I created a list of calls to test.

My results are in the attached spreadsheet. You're all welcome to validate my findings.

DOUG - the items in red in this sheet are the spots to fix.

3598 Test Script.xlsx (12,640 bytes)


2020-01-03 15:21

viewer   ~0009529

My results added to the Excel sheet. Hope its OK.

g3ucq.xlsx (11,303 bytes)


2020-01-04 02:02

administrator   ~0009530

John... I'm trying to account for the differences in your results and mind.



2020-01-04 03:28

viewer   ~0009531

Mike. Where I have a red cell indicates that what I see is incorrect.
It might be that there is data where there should be none.
Or no data where there should be some.
If you want me to test differently I will.


2020-01-04 03:41

administrator   ~0009532

I'm just trying to figure out if our results really differ... or if it's an interpretation thing.


2020-01-12 17:41

developer   ~0009543

Part of the problem is that there is a second "country" search that was overwriting the callsign lookup results. I change this, so that shouldn't happen any more. The second country search will run in certain situations.

Just kicked off the build with these changes. I still have a couple things on the ALE screen to fix, and I have a question out to Mike C. for confirmation that we don't want to use country lat/long when we use a prefix, with no modifier (i.e. VK4/WA9PIE)


2020-01-13 08:02

viewer   ~0009546

Updated excel file. There still some anomalies.


2020-01-13 08:03


g3ucq-2.xlsx (11,304 bytes)


2020-01-14 06:13

administrator   ~0009548

I tried the 258 build and noticed no difference from the prior build with my own script.

I did review G3UCQ's results. Those aren't the results I'm getting with 258 build.


2020-01-14 16:14

viewer   ~0009550

VE3JDF/W4 shows as United States in the ALE, correct distance and lat/lon.
All correct in the Lookup panel as well.


2020-01-14 16:46

viewer   ~0009551

I have redone the lookup test. I find that in the ALE and Lookup panel the Lon/Lat for /AM and /MM is shown as an incorrect number when there perhaps should be blank. I also did not realise that it is necessary to press Reset before each new call entry which makes a difference to the result.
I was just over writing the previous call. It is also necessary to press the Log Coordinates button when I thought the data was populated automatically.
New test result attached so I hope it agrees with yours Mike C.

g3ucq-3.xlsx (11,308 bytes)


2020-01-15 03:41

viewer   ~0009552

Please people.
Do understand /AM and /MM Don't have fixed lat/longs, they should show up blank IMHO


2020-01-26 16:18

developer   ~0009555

Changed lookup up, so new build upcoming later today. The key difference based on what I read from this bug and other emails are the following 2 items.

1. MM/AM modifiers will always clear out country to NONE and have no lat/long/distance/etc on any part of pane, or any of the ALE screens
2. Country Prefixes will ONLY show lat/long of that country on the Country portion of the lookup pane. lat/long/distance/etc will not be populated anywhere on ALE screen. Country name/DXCC will be populated based on prefix.

Let me know if either of these two items are not correct.


2020-01-26 16:45

viewer   ~0009556

Doug. I would think that Country prefixes should show the lat/long/distance on the ALE screen as on the Lookup pane.
Perhaps not really relevant for large countries like the USA and Russia but OK for smaller countries and islands.
Correct for AM/MM.


2020-01-26 17:20

viewer   ~0009557

Doug: Just a reminder to make sure you are aware of another problem with the ALE that has not received much atttnetion from the Beta team, but I have been able to consistently reproduce... I re entered it the comments on version 258 in the Beta Forum...
Replicating below:
"Just a reminder the ALE window certainly no longer crashes on looks ups, and it is no longer slow (I did not have the "slow lookup problem, only the crash on look up problem :-( ). There has been an enormous amount of focus on getting the ALE correct for call sign look ups to get to version 258.
A recurrent problem that still exists in version 258 is that on start up, it appears to work perfectly. Enter a call sign previously worked and you get the proper call sign and country information. After an amount of time (1-3 hrs?) the look up function partially continues to work from the perspective that the "licensee" info come up, but data on the previously worked call and Country" in the ALE window is completely blank. It looks like the program looses connection to the logbook database?
This needs focus and work as well, and I have not seen any dialogue recently on this problem. Are other on the Beta Team able to reproduce this issue?


2020-01-26 19:08

developer   ~0009558

If I understand correctly, my last correspondence with Mike indicated that he rather those be blank than filled in with potentially inaccurate data.

I have occasionally noticed behavior similar to what you are describing. I will see if I can pin that one down.

New build is now finished with lookup pane, ALE, and DM look pane changes. Despite looking similar the DM Lookup Pane and the log book lookup pane are implemented differently. So keep a critical eye to their differences to make sure I didn't overlook something.


2020-01-26 19:47

administrator   ~0009559

Last edited: 2020-01-26 19:57

View 2 revisions

In the 259 build, all things seem resolved except one minor thing... which is probably a cosmetic data display issue.

What's left:
- Get DXCC number to display in the Country tab of the ALE when Country = [None] Whenever Country = [None], the DXCC numeric value for [None] should be displayed. It is 0 (zero). This is the only thing left in the test script that needed fixing.
- I'd prefer to see [None] at the top of the list of Countries, rather at the bottom of the list. It'll be easier for users to use.
- DXCC awards are incorrectly counting "[None]" as a valid Country. The [None] Country needs to behave as-if it is in the list of "Non-DXCC Countries"; otherwise, awards totals will be worse than before
- Exported QSOs where DXCC=0 get exported correctly
- Imported QSOs where DXCC=0 are importing incorrectly (using some analysis of the callsign prefix or something); might not be a show-stopper for the next release, but it needs fixed

But so far... pretty good progress Doug. Thanks!

3598 Test Script (259).xlsx (12,624 bytes)
NoneEquals0.png (32,024 bytes)
NoneEquals0.png (32,024 bytes)


2020-01-26 20:11

administrator   ~0009560

Doug - here's a document that I've created to provide guidance for getting '[None]" to not appear in the DXCC awards.

Let me know if you have any questions.

GettingNoneOutOfDXCC.docx (210,807 bytes)


2020-01-26 22:03

administrator   ~0009561

Reminder to myself... when we release this, I'll need to publish a new Country List and encourage folks to get on the new release so the Country data is correct.


2020-01-27 04:37

viewer   ~0009562

With .259 I am seeing a 30 second delay for the ALE lookup and Lookup pane to populate.
Reverted to .258 and the delays disappeared. Unable to test until this is fixed.


2020-01-27 06:13

viewer   ~0009563

Improper argument on DM780 is resolved.
ALE functions the same as in 258 in Logbook.
A recurrent problem that still exists in version 259 in the Log Book is that on start up, it appears to work perfectly. Enter a call sign previously worked and you get the proper call sign and country information. After an amount of time (1-3 hrs?) the look up function partially continues to work from the perspective that the "licensee" info come up, but data on the previously worked call and Country" in the ALE window is completely blank. It looks like the program loses connection to the logbook database to show previous data on callsign and Country worked information
Pete - W2PJ


2020-01-27 06:15

viewer   ~0009564 delay observable in ALE lookup window in either 258 or 259 in Logbook or DM780 ALE.
Pete - W2PJ


2020-01-27 06:23

viewer   ~0009565

I am not seeing any delay in lookup or Ale Lookup, but in ALE Lookup the WPX field is not being populated.
Also, Improper Argument in DM780 is resolved.
Also seeing the "WSI and past QSOs lookup fail" after 3 hours or so as reported by W2PJ.


2020-01-27 06:56

viewer   ~0009566

Having reinstalled .259 lookups are now very fast. Go figure.
My lookups match what is seen in "3598 Test Script (259).xlsx"
The DM780 "Improper argument" error has been resolved.


2020-01-27 10:32

viewer   ~0009567

Well, after sitting doing nothing for an hour, Logbook crashed and produced a minidump. Attached

HRDLogbook_20200127_121823.mdmp (580,952 bytes)


2020-01-28 02:41

viewer   ~0009569

Improper argument popup is gone.
Lookups are working fast


2020-02-02 23:40

administrator   ~0009570

Aside from one thing, the build has closed all the items related to this.

Two things remain and one is minor and the other is something that's never worked anyway.

#1 (probably minor)Get DXCC number to display in the Country tab of the ALE when Country = [None] Whenever Country = [None], the DXCC numeric value for [None] should be displayed. It is 0 (zero). This is the only thing left in the test script that needed fixing.Here's a screenshot of what it is now:
The "United States" line shouldn't be there. Only the country that shows up in the Country field above. (The value of the "[None]" is otherwise correct.)
If we can fix this easily, we're ready to build a Release.

#2 - May not be so minor.

The other thing has to do with records that import as ADIF where DXCC = 0. Whatever logic parses these imports doesn't have "0" as a value. So it's falling back to a prefix analysis of the Callsign and it ends up important as "United States" (in this example).
This last point may not be quick. I dunno. If it's easy to add a condition into the existing logic for DXCC=0, awesome. If not, I'll create a defect about this and we'll tend it later.



2020-02-02 23:41

administrator   ~0009571

Image of Country tab in the ALE showing two entries for Country. Should be only one that matches what's shown in the upper ALE in the Country field (with DXCC numeric).

CountryTab.PNG (43,288 bytes)
CountryTab.PNG (43,288 bytes)


2020-02-03 00:14

viewer   ~0009572

MIke: You did not mention this issue below in version .259... from 1/26/20...
"A recurrent problem that still exists in version 259 in the Log Book is that on start up, it appears to work perfectly. Enter a call sign previously worked and you get the proper call sign and country information. After an amount of time (1-3 hrs?) the look up function partially continues to work from the perspective that the "licensee" info come up, but data on the previously worked call and Country" in the ALE window is completely blank. It looks like the program loses connection to the logbook database to show previous data on callsign and Country worked information"
Pete - W2PJ


2020-02-03 05:18

viewer   ~0009573

Entering WA9PIE/AM or /MM in the ALE in the Country tab of the ALE I see :-
Active Country DXCC
  Yes United States 291
  Yes [None] 0


2020-02-03 18:45

viewer   ~0009575

Rechecked the issue above on version .260 . i started Logbook this AM. Came home from work and there is not change. After some period of time (hours) the Call Sign and Country fields for previously worked stations remains blank on entry of a previously worked call, and the only field that updates is "Licensee" info.
"Enter a call sign previously worked and you get the proper call sign and country information. After an amount of time (1-3 hrs?) the look up function partially continues to work from the perspective that the "licensee" info come up, but data on the previously worked call and Country" in the ALE window is completely blank. It looks like the program loses connection to the logbook database to show previous data on callsign and Country worked information"
Pete - W2PJ


2020-02-03 18:52

viewer   ~0009576

Was this replicated or looked at?  The post from Doug suggested he would look into in when I reported it.

Doug said on 1/26..."I have occasionally noticed behavior similar to what you are describing. I will see if I can pin that one down."
Any work to replicate resolve this annoying problem? Only way to fix it is to shut down Logbook and re-start. Works for a while and then same problem recurs.

Pete - W2PJ


2020-02-04 03:26

viewer   ~0009577

Nailed it.

Capture.JPG (48,943 bytes)
Capture.JPG (48,943 bytes)


2020-02-04 05:40

viewer   ~0009578

.261 looks good for me too.


2020-02-04 23:36

administrator   ~0009580

I verified the final completion of this very challenging change myself.

Grateful for the efforts of all our developers, our beta team, our staff... and our customers.

Thank you!

Issue History

Date Modified Username Field Change
2019-11-19 06:32 WA9PIE New Issue
2019-11-19 06:33 WA9PIE Relationship added related to 0003125
2019-11-19 06:33 WA9PIE Relationship added related to 0002306
2019-11-19 07:50 g3ucq Note Added: 0009399
2019-11-19 07:51 WA9PIE Note Added: 0009400
2019-11-19 19:36 vk2byi Note Added: 0009404
2019-11-19 21:59 WA9PIE Note Added: 0009405
2019-11-20 08:09 WA9PIE File Added: Callsign Lookup Addition.docx
2019-11-20 08:09 WA9PIE Note Added: 0009431
2019-11-20 08:38 g3ucq Note Added: 0009432
2019-11-20 08:39 KB3NPH Note Added: 0009433
2019-11-20 08:44 g3ucq Note Added: 0009434
2019-11-20 21:15 vk2byi Note Added: 0009435
2019-11-21 14:51 WA9PIE Assigned To => DOUG
2019-11-21 14:51 WA9PIE Status new => assigned
2019-11-21 15:00 WA9PIE Note Added: 0009444
2019-11-21 16:29 g3ucq Note Added: 0009445
2019-11-21 17:47 vk2byi Note Added: 0009448
2019-11-21 18:59 vk2byi Note Added: 0009449
2019-11-21 19:21 WA9PIE Note Added: 0009450
2019-11-21 19:38 vk2byi Note Added: 0009452
2019-11-21 19:52 WA9PIE Note Added: 0009453
2019-11-21 20:54 WA9PIE Tag Attached: 6.7 defects
2019-11-27 01:03 DOUG Note Added: 0009457
2019-11-27 12:12 WA9PIE File Added: DM780-CallsignLookupPane-distance_and_heading.PNG
2019-11-27 12:12 WA9PIE File Added: Logbook-CallsignLookupPane-distance_and_heading.PNG
2019-11-27 12:12 WA9PIE Note Added: 0009458
2019-11-27 12:13 WA9PIE Note Edited: 0009458 View Revisions
2019-11-27 15:22 g3ucq Note Added: 0009459
2019-11-27 15:26 g3ucq Note Added: 0009460
2019-11-27 16:27 DOUG Note Added: 0009461
2019-11-27 19:45 vk2byi File Added: Country Lookup Test Results.xlsx
2019-11-27 19:45 vk2byi Note Added: 0009462
2019-11-27 19:55 WA9PIE Note Added: 0009463
2019-11-27 21:15 WA9PIE File Added: Suffixes That Do Not Count for a DXCC Country.docx
2019-11-27 21:15 WA9PIE Note Added: 0009464
2019-11-27 21:33 WA9PIE File Added: BearingDistance.PNG
2019-11-27 21:33 WA9PIE Note Added: 0009465
2019-11-27 23:18 vk2byi Note Added: 0009466
2019-11-27 23:22 WA9PIE Note Added: 0009467
2019-11-27 23:26 vk2byi Note Added: 0009468
2019-11-27 23:31 WA9PIE Note Added: 0009469
2019-11-27 23:34 vk2byi Note Added: 0009470
2019-11-28 00:01 WA9PIE Note Added: 0009471
2019-11-28 03:18 g3ucq Note Added: 0009472
2019-11-28 08:43 g3ypp File Added: HRD6_7_0_254_Prefix.JPG
2019-11-28 08:43 g3ypp Note Added: 0009473
2019-11-28 08:48 g3ucq Note Added: 0009474
2019-11-28 08:57 g3ypp Note Added: 0009475
2019-11-28 11:22 WA9PIE Note Added: 0009476
2019-11-28 12:12 WA9PIE Note Added: 0009477
2019-11-28 12:14 WA9PIE Note Edited: 0009477 View Revisions
2019-11-28 19:09 vk2byi Note Added: 0009478
2019-11-30 21:35 DOUG Note Added: 0009480
2019-11-30 21:57 WA9PIE File Added: Callsign Lookup Addition v2.docx
2019-11-30 21:57 WA9PIE Note Added: 0009481
2019-11-30 22:08 WA9PIE Note Added: 0009482
2019-12-01 03:33 g3ucq Note Added: 0009483
2019-12-02 10:13 g3ypp Note Added: 0009486
2019-12-08 14:53 DOUG Note Added: 0009491
2019-12-08 15:20 WA9PIE Status assigned => resolved
2019-12-08 15:20 WA9PIE Resolution open => fixed
2019-12-08 15:20 WA9PIE Fixed in Version =>
2019-12-08 15:20 WA9PIE Note Added: 0009492
2019-12-08 19:55 vk2byi Note Added: 0009493
2019-12-09 01:05 w4elp Note Added: 0009494
2019-12-09 02:17 vk2byi File Added: 1-character prefix.jpg
2019-12-09 02:17 vk2byi File Added: 2-character prefix.jpg
2019-12-09 02:17 vk2byi Note Added: 0009495
2019-12-09 03:24 g3ucq Note Added: 0009496
2019-12-09 03:29 g3ucq Note Added: 0009497
2019-12-09 04:29 vk2byi Note Added: 0009498
2019-12-09 06:15 WA9PIE Note Added: 0009499
2019-12-09 07:36 g3ypp Note Added: 0009500
2019-12-09 09:46 g3ucq Note Added: 0009501
2019-12-13 19:47 WA9PIE Note Added: 0009506
2019-12-14 19:01 WA9PIE Status resolved => assigned
2019-12-14 19:01 WA9PIE Resolution fixed => reopened
2019-12-14 19:02 WA9PIE File Added: Callsign Lookup Addition v3.docx
2019-12-14 19:02 WA9PIE Note Added: 0009507
2019-12-22 22:49 DOUG Note Added: 0009510
2019-12-22 22:57 DOUG Note Added: 0009511
2019-12-25 20:19 WA9PIE File Added: None.png
2019-12-25 20:19 WA9PIE Note Added: 0009513
2019-12-26 05:33 g3ucq Note Added: 0009515
2019-12-26 08:23 g3ucq Note Added: 0009516
2019-12-27 05:17 g3ypp Note Added: 0009517
2019-12-27 05:23 g3ypp Note Added: 0009518
2019-12-27 06:51 PD9FER File Added: Knipsel.JPG
2019-12-27 06:51 PD9FER Note Added: 0009519
2019-12-29 05:10 g3ucq Note Added: 0009520
2019-12-30 08:04 w2pj Note Added: 0009521
2019-12-30 08:05 w2pj Note Added: 0009522
2019-12-30 21:23 DOUG Note Added: 0009524
2020-01-02 12:49 w2pj Note Added: 0009525
2020-01-03 07:25 WA9PIE Note Added: 0009526
2020-01-03 09:32 WA9PIE File Added: 3598 Test Script.xlsx
2020-01-03 09:32 WA9PIE Note Added: 0009528
2020-01-03 15:21 g3ucq File Added: g3ucq.xlsx
2020-01-03 15:21 g3ucq Note Added: 0009529
2020-01-04 02:02 WA9PIE Note Added: 0009530
2020-01-04 03:28 g3ucq Note Added: 0009531
2020-01-04 03:41 WA9PIE Note Added: 0009532
2020-01-12 17:41 DOUG Note Added: 0009543
2020-01-12 20:53 WA9PIE Status assigned => resolved
2020-01-12 20:53 WA9PIE Resolution reopened => fixed
2020-01-12 20:53 WA9PIE Fixed in Version =>
2020-01-13 08:02 g3ucq Note Added: 0009546
2020-01-13 08:03 g3ucq File Added: g3ucq-2.xlsx
2020-01-14 06:13 WA9PIE Note Added: 0009548
2020-01-14 06:15 WA9PIE Status resolved => assigned
2020-01-14 06:15 WA9PIE Resolution fixed => reopened
2020-01-14 06:15 WA9PIE Fixed in Version =>
2020-01-14 16:14 g3ucq Note Added: 0009550
2020-01-14 16:46 g3ucq File Added: g3ucq-3.xlsx
2020-01-14 16:46 g3ucq Note Added: 0009551
2020-01-15 03:41 PD9FER Note Added: 0009552
2020-01-26 16:18 DOUG Note Added: 0009555
2020-01-26 16:45 g3ucq Note Added: 0009556
2020-01-26 17:20 w2pj Note Added: 0009557
2020-01-26 19:08 DOUG Note Added: 0009558
2020-01-26 19:47 WA9PIE File Added: 3598 Test Script (259).xlsx
2020-01-26 19:47 WA9PIE File Added: NoneEquals0.png
2020-01-26 19:47 WA9PIE Note Added: 0009559
2020-01-26 19:57 WA9PIE Note Edited: 0009559 View Revisions
2020-01-26 20:11 WA9PIE File Added: GettingNoneOutOfDXCC.docx
2020-01-26 20:11 WA9PIE Note Added: 0009560
2020-01-26 22:03 WA9PIE Note Added: 0009561
2020-01-27 04:37 g3ucq Note Added: 0009562
2020-01-27 06:13 w2pj Note Added: 0009563
2020-01-27 06:15 w2pj Note Added: 0009564
2020-01-27 06:23 g3ypp Note Added: 0009565
2020-01-27 06:56 g3ucq Note Added: 0009566
2020-01-27 10:32 g3ypp File Added: HRDLogbook_20200127_121823.mdmp
2020-01-27 10:32 g3ypp Note Added: 0009567
2020-01-28 02:41 PD9FER Note Added: 0009569
2020-02-02 23:40 WA9PIE Status assigned => resolved
2020-02-02 23:40 WA9PIE Resolution reopened => fixed
2020-02-02 23:40 WA9PIE Note Added: 0009570
2020-02-02 23:41 WA9PIE File Added: CountryTab.PNG
2020-02-02 23:41 WA9PIE Note Added: 0009571
2020-02-03 00:14 w2pj Note Added: 0009572
2020-02-03 05:18 g3ucq Note Added: 0009573
2020-02-03 18:45 w2pj Note Added: 0009575
2020-02-03 18:52 w2pj Note Added: 0009576
2020-02-04 03:26 g3ucq File Added: Capture.JPG
2020-02-04 03:26 g3ucq Note Added: 0009577
2020-02-04 05:40 g3ypp Note Added: 0009578
2020-02-04 23:36 WA9PIE Status resolved => closed
2020-02-04 23:36 WA9PIE Fixed in Version =>
2020-02-04 23:36 WA9PIE Testing Not Started => Beta Successful
2020-02-04 23:36 WA9PIE Note Added: 0009580
2020-02-04 23:38 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe