View Issue Details

IDProjectCategoryView StatusLast Update
00035983 - Current Dev ListBugpublic2019-12-02 10:13
ReporterWA9PIEAssigned ToDOUG 
PrioritynormalSeveritymajorReproducibilityalways
Status assignedResolutionopen 
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.

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