View Issue Details

IDProjectCategoryView StatusLast Update
0003464Ham Radio DeluxeBugpublic2019-11-08 02:32
ReporterWA9PIEAssigned ToWA9PIE 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionreopened 
Product Version 
Target VersionFixed in Version6.7.0.244 
Summary0003464: Some fields missing from QRZ.com call sign lookup
DescriptionThe specification for this change spelled out how the country data should be populated when QRZ.com's XML service was used.

The following fields are not being populated:
COL_QSL_VIA
COL_QSO_AGE
COL_QSO_CONT
COL_QSO_COUNTRY
COL_HRDCOUNTRYNO

The specification requires that the DXCC value in the QRZ.com XML data be used in order to populate the Country, Continent, and HRD Number fields by looking up the DXCC value in the HRD Country List and populating Country, Continent, and HRD Number from that lookup. The FLD_QSL_VIA and FLD_QSO_AGE fields are not being populated.
Steps To Reproduce- Launch Logbook
- Go to Tools > Configure > Callsign Lookup

In the Enable tab, refer the Enabled Methods...
- ensure that QRZ.com XML Subscription is enabled
- no other lookup methods enabled

Open the ALE. Enter WA9PIE and cause the lookup (either by tab or clicking the Lookup button).

Result:
- Country field is empty (the DXCC should have been used to do a lookup in the HRD Country List and returned "United States")
- Continent field is empty (the DXCC should have been used to do a lookup in the HRD Country List and returned "NA")
- HRD Country number is empty ((the DXCC should have been used to do a lookup in the HRD Country List and returned "291" for HRD Country Number")
- FLD_QSL_VIA (in the QSL tab) is empty. It should contain the contents of <qslmgr>
- FLD_QSL_AGE (in the Contact tab) is empty. It should contain a value calculated by subtracting the <born> value from the current year

The rationale behind this is that the data in the QRZ lookup is more specific (more likely to be correct) than the "source of last resort" (HRD Country List)
TagsNo tags attached.
ModuleLogbook
Sub-ModuleCall lookup
Testing Beta Successful

Relationships

related to 0003001 closedWA9PIE Callsign lookup function does not appear to be working as designed 
related to 0003492 closedWA9PIE Complete the Callsign Lookup function for the Country List method 
related to 0003493 closedK7ZCZ Complete the Callsign Lookup function for the QRZCQ method 
related to 0003495 closedK7ZCZ Complete the Callsign Lookup function for the Callook.info method 
related to 0003496 closedWA9PIE Complete the Callsign Lookup function for the QRZ.com Subscription method 
related to 0003497 closedWA9PIE Complete the Callsign Lookup function for the Logbook method 
related to 0003498 closedWA9PIE Complete the Callsign Lookup function for the UCSDB (Public) method 
related to 0003499 closedWA9PIE Complete the Callsign Lookup function for the UCSDB (Private) method 
related to 0003544 closedK7ZCZ QRZ.com Subscription, the Callsign Lookup does not correctly assign HRDCountry 

Activities

K7ZCZ

2019-09-26 09:34

administrator   ~0008700

This report doesn't look like it's complete.

WA9PIE

2019-09-27 21:02

administrator   ~0008713

I'm attaching the files needed to reproduce this. It's a common use-case when the customer (a) has a log with a given callsign used for multiple countries and (b) selects enabled lookup methods in a particular order. I'll provide the rest of the detail in the description and repro steps.

CallsignLookupMapping32 (most_current).xlsx (25,244 bytes)

WA9PIE

2019-09-27 21:40

administrator   ~0008714

Actually, I think there may be a larger problem here. I'm going to test each lookup method against the spec.

WA9PIE

2019-09-28 19:37

administrator   ~0008719

Forgetting the test page for the moment...

The following is specific to QRZ.com's XML data:

I did a lookup in the ALE with my own call (WA9PIE), the following fields were not populated (just to pare this down to a solvable problem):
FLD_QSL_VIA; should be populated with the contents from the <qslmgr> field in the XML
FLD_QSO_AGE; should be populated by subtracting the <born> field from today's year
FLD_QSO_CONT; should be populated by taking the <dxcc> from the XML and looking up Continent in the HRD Country List for that DXCC number
FLD_QSO_COUNTRY; should be populated by taking the <dxcc> from the XML and looking up Country in the HRD Country List for that DXCC number

I'm attaching a copy of my XML data.

There are a couple other fields we'll need to discuss. But these four above are the current problem.

wa9pie.xmldata.qrz.xml (1,371 bytes)

WA9PIE

2019-09-29 10:15

administrator   ~0008720

I figured out a pictorial way to show the flow for Country, Continent, and HRD Country Number.

Attached

LookupFlowForCountryContinent.jpg (956,209 bytes)

K7ZCZ

2019-09-29 17:00

administrator   ~0008722

Work stopped on the specification and I assumed that meant it was finished. After it was split into two documents (a spreadsheet and the original document), questions in the document were never resolved. It seems quite possible the specification was never finished and is incomplete.

I've added code to pull the QSL manager and compute the age from the data returned by the QRZ.com. That much is in these change sets:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5177
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5178


Note that, in the 6.6 release and earlier, the Test pane ignores the Logbook and Country List settings; those data sources aren't explicitly consulted for lookup information.

The drawing doesn't seem to match this bug report. The report says that QRZ.com should be the only enabled lookup source, which means the HRD Country List is not enabled. The drawing and the text in the "Result" heading, above say that data returned by QRZ.com should be used with the HRD Country List, even though it's disabled.

What does this contradiction really mean? Maybe it means that later sources in the list of enabled sources actually process data returned by other sources earlier in the list instead of just using the call sign and QSO date as their inputs. Maybe it means that the HRD Country List is unconditionally consulted as a part of processing a QRZ.com lookup, and may be revisited as a final step in the look up process. Or, maybe it means something else ... ?

The specificaiton says that only the the country comes from the callsign. I don't understand how the country comes from a callsign -- strictly by prefix matching? -- but here maybe we're saying that the DXCC ID number is used to look up the country, *plus* HRD country number and the continent. Which is the desired behaviour?

This issue is further compounded by weakly established nomenclature. I can't find any mention of "Unique Callsign Database" in the code. It's mentioned in a setting in the options page, which is largely ignored in the code. The only reference in the product documentation seems to be this:

CAVEAT: The HRD Country File includes a list of unique calls in a Unique Callsign Database (UCSDB). That information
takes priority over all the enabled methods by design.

which is almost circular -- that the "HRD Country File" is actually the same as the "Unique Callsign Database". The only docs I can find are in a PDF file we seem to accidentally ship (see Mantis 3027) named "HRD Logbook - Country Data.pdf".

From the UI in the Logbook, we can use the "Manager" command in the "Countries" menu to reach a view that shows a list of countries. This list includes DXCC number, HRD Number, a country name, and some other information. The definitions are scoped to be active for a certain time -- between start and end dates, which might or might not present -- presumably to implement open-ended bounds of validity time.

The "Countries" view presents a "Unique Calls" button on its tool bar. This button leads to a prompt for editing either a "public" or "private" list of call signs. Is this "Countries" view the "HRD Country File"; and are the public and private unique call sign lists the public and private "UCSDB" mentioned here?

WA9PIE

2019-10-01 13:32

administrator   ~0008728

I don't think the specification says that the country comes from the prefix. This is a reflection of a very old model that has a high error-rate, given the reuse of specialized calls for DXpeditions and so on. I hope we didn't put that in the specification. (We do need to also have a separate conversation about the ADIF import process.)

"The drawing doesn't seem to match this bug report. The report says that QRZ.com should be the only enabled lookup source, which means the HRD Country List is not enabled." [No. Enabling QRZ.com as the only enabled lookup source assumed that the HRD Country List is the final "catch-all" method. So yes, HRD Country List would be enabled as last.]

Yes, "it means that the HRD Country List is unconditionally consulted as a part of processing a QRZ.com lookup (or any other lookup), and WILL be revisited as a final step in the look up process."

There are sections in the HRD Country List. But I'm not referring to the UCSDB (Public or Private). I'm referring to the country section in the HRD Country List. (ie. even though the UCSDB is physically inside the same file where the country data exists, we don't think of the HRD Country List as the entire file... we think of it as just the country data within the file)

When a service like QRZ.com is used as a primary lookup, it has known problems with country data. As a result, we can't use the country data from these sources. We DO need to use the DXCC numeric value from a service like QRZ.com and then 'augment' that QRZ.com lookup data with data from the HRD Country list in order to fill-in gaps in the QRZ data. That's not the same as moving the HRD Country List into the path of the primary lookup.

Here's why.

Again, assuming that the UCSDB (Public and Private) are the first unconditional sources and the HRD Country List is the last unconditional source... there are use-cases where various enabled methods (in the middle) can return conficting information. Here's one of those use-cases...

In-general, the intention of ordering the callsign lookup methods is to put the most accurate methods at the top of the chain... and the least accurate methods at the bottom. But for those methods (in the middle) there was debate about which of them is most accurate.

When methods like QRZ.com Subscription (and the other online methods) are used, the lookup of the DXCC numeric in the HRD Country list is ONLY to augment the information provided by this enabled method. In reality, unless the user had no enabled methods (and thus only the UCSDB and HRD Country List would be used), the HRD Country List would rarely be the source that popualtes the record because any other method would be more specific (but would still need augmented for Country or Continent using the DXCC numeric).

My original repro case (I posted I think in 3001) was one where I had a callsign - K5K - in my logbook as Kingman Reef (DXCC=134). But if you search QRZ.com right now for K5K, you'll get Hurricane Harvey and Kingwood Texas... Kingwood, TX 77339 (DXCC=291).

If a user enables these (in the middle) methods - Logbook and QRZ.com XML Subscription... the order of these SHOULD affect the outcome.

Some could debate whether or not their logbook is a more accurate sources than QRZ.com. But playing these through...

Scenario 1
Enabled Methods:
- HRD Logbook
- QRZ.com Subsciption
- (HRD Country List used unconditionally as the source of last resort)

K5K returns:
- HRD Logbook; DXCC=134
- QRZ.com Subscription; DXCC=291
- (HRD Country List - since the only useful information in this source is Country and Continent, it won't really be used as a source)

In this scenario, because the first enabled method returned DXCC=134, then the Country must be Kingman Reef and the Continent must be OC.

Scenario 2
Enabled Methods:
- QRZ.com Subsciption
- HRD Logbook
- (HRD Country List used unconditionally as the source of last resort)

K5K returns:
- QRZ.com Subscription; DXCC=291
- HRD Logbook; DXCC=134
- (HRD Country List - since the only useful information in this source is Country and Continent, it won't really be used as a source)

In this scenario, because the first enabled method returned DXCC=291, then the Country must be United States and the Continent must be NA.

Whether the user orders Logbook first or QRZ.com (or similar) first is a point of personal preference. But the fact remains, the QRZ.com (and other services) must have its data augmented with data that we have in the HRD Country List in order to render an accurate result. Here's why...

Scenario 3
Enabled Methods:
- QRZ.com Subsciption (or HRD Logbook)
- HRD Logbook (or QRZ.com Subscription)
- HRD Country List used unconditionally as the source of last resort and - in the case where we are not augmenting QRZ data from the HRD Country List - the Country and (probably) Continent only get populated from the HRD Country List. That's not good. Here's why.

K5K returns:
- With regards to Logbook or QRZ (or similar) only the DXCC numeric is useful. Country and Continent are either not available or accurate. So...
- HRD Country List; in this case, if the previous lookup sources are not augmented by looking up the DXCC numeric, then the HRD Country List will always be used to populated Country and Continent (and HRD Country Number) and that will render a result with lower accuracy.

I think my image in my previous post accurately describes how the QRZ (and other) lookup sources are augmented with data from the HRD Country List in order to achieve a more accurate result.

PD9FER

2019-10-02 09:42

viewer   ~0008731

Tested Alpha 6.7.0.231
Also on the same Lookup the eQSL and LoTW registered fields are not populating (needs a new mantis??)

PD9FER

2019-10-02 10:03

viewer  

2019-10-02_16-59-55.png (99,999 bytes)
2019-10-02_16-59-55.png (99,999 bytes)

K7ZCZ

2019-10-06 13:32

administrator   ~0008759

Ferry, the specification for this work makes no mention of the eQSL or LoTW registered fields. Please open a separate issue with a description of your concern, including repro steps, so we can examine it and evaluate a fix.

WA9PIE

2019-10-07 06:10

administrator   ~0008763

I suggest we stick with one thing at a time. Ferry - we'll get back to that point about eQSL and LOTW... probably in a separate Mantis issue.

In this one...

FLD_QSO_AGE works in 6.7.0.232.

FLD_QSL_VIA; not yet fixed

FLD_QSO_CONT; not yet fixed due to cross-reference topic listed above where HRD Country List needs to be used to augment QRZ data using DXCC numeric
FLD_QSO_COUNTRY; not yet fixed due to cross-reference topic listed above where HRD Country List needs to be used to augment QRZ data using DXCC numeric
FLD_HRD_NUMBER; not yet fixed due to cross-reference topic listed above where HRD Country List needs to be used to augment QRZ data using DXCC numeric

K7ZCZ

2019-10-07 09:49

administrator   ~0008765

I'm working on code that will looking aside to the Country List with the response from QRZ during the QRZ lookup itself.

However, it's starting to sound like the specification is incomplete and inaccurate. I think we should take a pass over it before proceeding much further.

K7ZCZ

2019-10-07 19:46

administrator   ~0008768

This change set: https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5190 uses the QRZ DXCC number to look up the country name and continent name during the QRZ lookup. The country name returned from QRZ is still used for the mailing address, as this is what the specification indicates. With that change, I think this specific issue is resolved.

Other issues might exist, and they should be given new Mantis issues. Using an individual Mantis issue for each issue in the product facilitates tracking and documentation, expedites fixes, and make testing easier. Other issues raised here include:


  • FLD_HRD_NUMBER should somehow be populated. The specification doesn't seem to mention this field.

  • There are concerns about the eQSL or LoTW registered fields. I don't see these in the specification.

  • The specifcation says: "The Ham Radio Deluxe Country List is visited to retrieve the callsign’s country (FLD_QSO_COUNTRY). No other fields are retrieved from this source. The Country List data source is used unconditionally." I think the callsign list provides a regular expression to match call signs to countries. That feature can be demonstrated with these steps:


1) Start up the logbook. Don't need a database at all.
2) Use the "Manager" command in the "Countries" menu
3) In the "Countries" tab toolbar, mark the "Lookup" box
4) Type in a call. "3G3G", for example. Press TAB.
5) The drop down next to the Lookup edit now says "Chile", and "Chile" is selected in the list. Here, Chile is selected because it matches the regular expression in the "Prefix list" column.
6) Type in another, like "JI7UKN". "Japan" is now selected, since this call matches the regular expression for that country.

If the last mandatory lookup for the Country List isn't meant to be using these regular expressions, then the specification should be refined to explain exactly what it is meant to do.

WA9PIE

2019-10-09 07:42

administrator   ~0008771

The mandatory lookup that uses the Country List as "the source of last resort" should - in-fact - be using the regular expression logic. The problem we're having isn't related to the mandatory lookup that uses the Country List.

The problem is with the enabled methods that precede it.

I'm attaching a file that shows the new logfile from the existing lookup in the 6.7.0.232 build.

This file also has a "mock-up" of what it should be doing for the enabled methods that precede it. I hope that looking at this mock-up helps clarify what was in the specification for the population of Country, Continent, and HRDCOUNTRYNO as a method to augment and data received by enabled methods.

Current Callsign Lookup in 6_7.docx (14,130 bytes)

K7ZCZ

2019-10-09 09:00

administrator   ~0008772

Why was this issue re-opened? It couldn't possibly have been tested, as no build with yesterday's fix has been made available.

WA9PIE

2019-10-09 17:09

administrator   ~0008774

I have a modified copy of the logfile in the hopes that this will describe what needs to happen. Because I'm using K7ZCZ for this example, I'm going to email you the file.

Let me know if you have any questions after reading this one. Happy to clarify from here.

K7ZCZ

2019-10-10 11:32

administrator   ~0008782

If there are specific concerns about this issue, please raise them here. New issues should get their own Mantis issue to facilitate tracking, testing, and discussion. Please see my note 8768 in this issue for more details.

WA9PIE

2019-10-11 21:18

administrator   ~0008787

Thanks. I think it's a good idea to work from the spec. So I'm attaching the field mapping spec (I found a v3.2 of that spec that I didn't have yesterday).

In the attached spec, I have highlighted in RED those things that aren't working. I've highlighted in YELLOW those things that partially work. I've highlighted in ORANGE those things that I've revised (very few minor things based on improved insight into how this works). I would recommend ignoring non-shaded things for now (even if they have comments). Once we get beyond the current items, I'll go back through it again and see if we need to change the approach for other items.

My ability to test these things were limited by what data certain callsigns have in these systems. The callsigns I used were WA9PIE, K7ZCZ, T30GC, KH2A, and KH0A.

I've run through all the enabled methods except those that require me to have a CD. I'm happy to test those if I can get my hands on them.

CallsignLookupMapping32 (most_current)b.xlsx (25,754 bytes)

K7ZCZ

2019-10-12 11:53

administrator   ~0008788

Please use new Mantis issues to track new requests. Granular tracking makes communication clearer and facilitates tracking progress and testing.

WA9PIE

2019-10-13 05:29

administrator   ~0008795

Mike, these aren't "new requests." This is the same request as 3001.

At this point, there are probably 100 different field mappings that were in the field mapping spec that have never been completed. So you want me to create a separate Mantis for every field mapping in the spec that's not built to the spec?

K7ZCZ

2019-10-13 10:48

administrator   ~0008804

Actually, these are very much new requests. The spec was flawed, and so the software doesn't meet the intent. Now that the spec has been revised, we need to find the rest of the flaws in the software and get the software to catch up with the spec.

This issue is about a few fields from the QRZ that didn't work as desired. I think they're fixed. If there are more issues with missing or incorrect fields related to QRZ, they could be added to this issue. But at this point, it's probably best to create a new issue even for those just so that the problem can be clearly communicated. For sure, a single issue (Mantis 3001) tracked the complete re-write of the call sign lookup feature; but single large issues are cumbersome to manage and don't facilitate granularity in reporting issues or progress.

If you think 100 different issues need to be opened, feel free to do so. But it might be more sensible to group the issues you're finding by the data source which is involved. Then, at most, there should be a dozen or so for this iteration. Since each data source can be readily tested in isolation, the issues will be easy to document, address, resolve, and test than if more than 100 different issues were added to a re-used, broad-scope Mantis issue.

Please review my more detailed response here: https://development.hamradiodeluxe.com/view.php?id=3001#c8685

I don't think disrupting Mantis to make a point is a mature way to proceed, so I'm hoping this is the last time I have to resolve this issue. As soon as we can move forward with clear, granular reports, I'm sure we'll be able to make great progress.

WA9PIE

2019-10-13 10:53

administrator   ~0008806

I'm not sure what more I can give you.

I haven't made significant changes to the field mapping spec. In-particular, the method for populating Country, and Continent haven't changed since before the spec was written. Actually, there were numerous email conversations about the method.

I documented it exactly as it was described and that piece of the spec hasn't changed.

WA9PIE

2019-10-23 04:24

administrator   ~0008943

I went through this myself as part of the 0003001 cases. This is working correctly for QRZ now.

Overall, this is a big win. It wasn't working very well at all before.

Issue History

Date Modified Username Field Change
2019-09-25 23:23 WA9PIE New Issue
2019-09-26 09:34 K7ZCZ Assigned To => WA9PIE
2019-09-26 09:34 K7ZCZ Status new => feedback
2019-09-26 09:34 K7ZCZ Note Added: 0008700
2019-09-27 21:02 WA9PIE File Added: K5K.ADI
2019-09-27 21:02 WA9PIE File Added: CallsignLookupMapping32 (most_current).xlsx
2019-09-27 21:02 WA9PIE Note Added: 0008713
2019-09-27 21:17 WA9PIE File Deleted: K5K.ADI
2019-09-27 21:22 WA9PIE Steps to Reproduce Updated View Revisions
2019-09-27 21:40 WA9PIE Note Added: 0008714
2019-09-28 19:37 WA9PIE File Added: wa9pie.xmldata.qrz.xml
2019-09-28 19:37 WA9PIE Note Added: 0008719
2019-09-28 19:44 WA9PIE Assigned To WA9PIE => K7ZCZ
2019-09-28 19:44 WA9PIE Status feedback => assigned
2019-09-28 19:44 WA9PIE Description Updated View Revisions
2019-09-28 19:44 WA9PIE Steps to Reproduce Updated View Revisions
2019-09-29 09:42 K7ZCZ Summary Callsign lookup function does not appear to be working as designed #4 => Some fields missing from QRZ.com call sign lookup
2019-09-29 10:15 WA9PIE File Added: LookupFlowForCountryContinent.jpg
2019-09-29 10:15 WA9PIE Note Added: 0008720
2019-09-29 17:00 K7ZCZ Note Added: 0008722
2019-09-29 17:00 K7ZCZ Assigned To K7ZCZ => WA9PIE
2019-10-01 13:32 WA9PIE Note Added: 0008728
2019-10-01 13:32 WA9PIE Assigned To WA9PIE => K7ZCZ
2019-10-02 09:42 PD9FER Note Added: 0008731
2019-10-02 10:03 PD9FER File Added: 2019-10-02_16-59-55.png
2019-10-05 20:21 K7ZCZ Relationship added related to 0003001
2019-10-06 13:32 K7ZCZ Note Added: 0008759
2019-10-07 06:10 WA9PIE Note Added: 0008763
2019-10-07 09:49 K7ZCZ Note Added: 0008765
2019-10-07 19:46 K7ZCZ Note Added: 0008768
2019-10-07 19:46 K7ZCZ Assigned To K7ZCZ => WA9PIE
2019-10-07 19:46 K7ZCZ Status assigned => resolved
2019-10-07 19:46 K7ZCZ Resolution open => fixed
2019-10-09 07:42 WA9PIE File Added: Current Callsign Lookup in 6_7.docx
2019-10-09 07:42 WA9PIE Note Added: 0008771
2019-10-09 07:42 WA9PIE Assigned To WA9PIE => K7ZCZ
2019-10-09 07:42 WA9PIE Status resolved => assigned
2019-10-09 07:42 WA9PIE Resolution fixed => reopened
2019-10-09 09:00 K7ZCZ Note Added: 0008772
2019-10-09 09:00 K7ZCZ Assigned To K7ZCZ => WA9PIE
2019-10-09 17:09 WA9PIE Note Added: 0008774
2019-10-09 17:11 WA9PIE Assigned To WA9PIE => K7ZCZ
2019-10-09 17:12 WA9PIE Description Updated View Revisions
2019-10-10 11:32 K7ZCZ Assigned To K7ZCZ => WA9PIE
2019-10-10 11:32 K7ZCZ Status assigned => resolved
2019-10-10 11:32 K7ZCZ Resolution reopened => fixed
2019-10-10 11:32 K7ZCZ Note Added: 0008782
2019-10-11 21:18 WA9PIE File Added: CallsignLookupMapping32 (most_current)b.xlsx
2019-10-11 21:18 WA9PIE Note Added: 0008787
2019-10-11 21:19 WA9PIE Assigned To WA9PIE => K7ZCZ
2019-10-11 21:19 WA9PIE Status resolved => assigned
2019-10-11 21:19 WA9PIE Resolution fixed => reopened
2019-10-12 11:53 K7ZCZ Assigned To K7ZCZ => WA9PIE
2019-10-12 11:53 K7ZCZ Status assigned => resolved
2019-10-12 11:53 K7ZCZ Note Added: 0008788
2019-10-13 05:29 WA9PIE Assigned To WA9PIE => K7ZCZ
2019-10-13 05:29 WA9PIE Status resolved => assigned
2019-10-13 05:29 WA9PIE Note Added: 0008795
2019-10-13 05:55 WA9PIE Relationship added related to 0003492
2019-10-13 06:37 WA9PIE Relationship added related to 0003493
2019-10-13 07:25 WA9PIE Relationship added related to 0003495
2019-10-13 07:46 WA9PIE Relationship added related to 0003496
2019-10-13 08:30 WA9PIE Relationship added related to 0003497
2019-10-13 09:03 WA9PIE Relationship added related to 0003498
2019-10-13 09:15 WA9PIE Relationship added related to 0003499
2019-10-13 10:48 K7ZCZ Note Added: 0008804
2019-10-13 10:49 K7ZCZ Assigned To K7ZCZ => WA9PIE
2019-10-13 10:49 K7ZCZ Status assigned => resolved
2019-10-13 10:53 WA9PIE Assigned To WA9PIE => K7ZCZ
2019-10-13 10:53 WA9PIE Note Added: 0008806
2019-10-21 17:01 K7ZCZ Fixed in Version => 6.7.0.235
2019-10-23 04:24 WA9PIE Assigned To K7ZCZ => WA9PIE
2019-10-23 04:24 WA9PIE Status resolved => closed
2019-10-23 04:24 WA9PIE Testing Not Started => Beta Successful
2019-10-23 04:24 WA9PIE Note Added: 0008943
2019-11-04 22:06 K7ZCZ Relationship added related to 0003544
2019-11-08 02:12 WA9PIE Fixed in Version 6.7.0.235 => 6.7.0.244
2019-11-08 02:32 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe