View Issue Details

IDProjectCategoryView StatusLast Update
00035983 - Current Dev ListBugpublic2020-01-15 03:41
ReporterWA9PIEAssigned ToDOUG 
PrioritynormalSeveritymajorReproducibilityalways
Status assignedResolutionreopened 
Product Version 
Target VersionFixed in Version 
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
ModuleLogbook
Sub-ModuleCall lookup
TestingNot Started

Relationships

related to 0003125 acknowledgedWA9PIE 1 - Backlog 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 new 1 - Backlog /MM (Maritime Mobile) QSO added to DXCC Awards count 

Activities

g3ucq

2019-11-19 07:50

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

WA9PIE

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.

vk2byi

2019-11-19 19:36

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

WA9PIE

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

WA9PIE

2019-11-20 08:09

administrator   ~0009431

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.

Callsign Lookup Addition.docx (67,190 bytes)

g3ucq

2019-11-20 08:38

updater   ~0009432

That seems to cover all options.

KB3NPH

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?

g3ucq

2019-11-20 08:44

updater   ~0009434

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

vk2byi

2019-11-20 21:15

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

        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.

WA9PIE

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.

g3ucq

2019-11-21 16:29

updater   ~0009445

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

vk2byi

2019-11-21 17:47

updater   ~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 :)

vk2byi

2019-11-21 18:59

updater   ~0009449

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

WA9PIE

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.

vk2byi

2019-11-21 19:38

updater   ~0009452

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.

WA9PIE

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.

DOUG

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)

WA9PIE

2019-11-27 12:12

administrator  

WA9PIE

2019-11-27 12:12

administrator   ~0009458

Last edited: 2019-11-27 12:13

View 2 revisions

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

g3ucq

2019-11-27 15:22

updater   ~0009459

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

g3ucq

2019-11-27 15:26

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

DOUG

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?

vk2byi

2019-11-27 19:45

updater   ~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)

WA9PIE

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.

WA9PIE

2019-11-27 21:15

administrator   ~0009464

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

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

WA9PIE

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)

vk2byi

2019-11-27 23:18

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

WA9PIE

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

vk2byi

2019-11-27 23:26

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

WA9PIE

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.

vk2byi

2019-11-27 23:34

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

WA9PIE

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.

Thoughts?

g3ucq

2019-11-28 03:18

updater   ~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

g3ypp

2019-11-28 08:43

updater   ~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)

g3ucq

2019-11-28 08:48

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

g3ypp

2019-11-28 08:57

updater   ~0009475

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

WA9PIE

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

WA9PIE

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

vk2byi

2019-11-28 19:09

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

DOUG

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.

WA9PIE

2019-11-30 21:57

administrator   ~0009481

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.

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

WA9PIE

2019-11-30 22:08

administrator   ~0009482

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.

g3ucq

2019-12-01 03:33

updater   ~0009483

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

g3ypp

2019-12-02 10:13

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

DOUG

2019-12-08 14:53

developer   ~0009491

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

WA9PIE

2019-12-08 15:20

administrator   ~0009492

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

vk2byi

2019-12-08 19:55

updater   ~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

w4elp

2019-12-09 01:05

updater   ~0009494

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.

vk2byi

2019-12-09 02:17

updater   ~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
VK2BYI

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)

g3ucq

2019-12-09 03:24

updater   ~0009496

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.

g3ucq

2019-12-09 03:29

updater   ~0009497

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

vk2byi

2019-12-09 04:29

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

WA9PIE

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.

g3ypp

2019-12-09 07:36

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

g3ucq

2019-12-09 09:46

updater   ~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

WA9PIE

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.

WA9PIE

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)

DOUG

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.

DOUG

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.

WA9PIE

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)

g3ucq

2019-12-26 05:33

updater   ~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?

g3ucq

2019-12-26 08:23

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

g3ypp

2019-12-27 05:17

updater   ~0009517

W4ElP noted in the forum:

Installed 6.7.0.257 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 6.7.0.256 and all is well - no message.

I can replicate this.

g3ypp

2019-12-27 05:23

updater   ~0009518

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

PD9FER

2019-12-27 06:51

updater   ~0009519

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

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

g3ucq

2019-12-29 05:10

updater   ~0009520

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

w2pj

2019-12-30 08:04

updater   ~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...
73
Pete - W2PJ

w2pj

2019-12-30 08:05

updater   ~0009522

As reported by G3ypp I get the same results...
"Installed 6.7.0.257 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."

DOUG

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

w2pj

2020-01-02 12:49

updater   ~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

WA9PIE

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

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)

g3ucq

2020-01-03 15:21

updater   ~0009529

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

g3ucq.xlsx (11,303 bytes)

WA9PIE

2020-01-04 02:02

administrator   ~0009530

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

Thoughts?

g3ucq

2020-01-04 03:28

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

WA9PIE

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.

DOUG

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)

g3ucq

2020-01-13 08:02

updater   ~0009546

Updated excel file. There still some anomalies.

g3ucq

2020-01-13 08:03

updater  

g3ucq-2.xlsx (11,304 bytes)

WA9PIE

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.

g3ucq

2020-01-14 16:14

updater   ~0009550

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

g3ucq

2020-01-14 16:46

updater   ~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)

PD9FER

2020-01-15 03:41

updater   ~0009552

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

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 => 6.7.0.256
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 6.7.0.256 => 6.7.0.258
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 6.7.0.258 =>
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