View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003142||3 - Current Dev List||Enhancement||public||2019-01-31 00:15||2019-02-16 18:07|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0003142: Logbook does not offer a list of satellites; this causes problems with LOTW upload (and probably awards)|
|Description||A satellite operator informed me that they use another logging program because HRD Logbook does not use the supported lists of satellites that makes it compatible with LOTW. I'm gathering information and sources about this.|
But it seems to me that the "Ant/Sat" tab in the ALE needs to have a pre-built standard list of satellites that the operator can choose from... or we populate it from whatever information we get from HRD Satellite Tracking.
"If the QSO was made via a satellite, its propagation mode must be set to SAT, and it must specify the name of the satellite used."
|Tags||No tags attached.|
Based on the data found on the ARRL's website that describes the requirements for satellite QSOs uploaded into LOTW, the following two fields are required in the ADIF export (example, based on included mock-up image):
Satellite Name: <SAT_NAME:4>AO-10
Propagation Mode: <PROP_MODE:3>SAT
The reasons for pointing this out is are as follows:
The SAT_NAME must match the list enumerated at https://lotw.arrl.org/lotw-help/frequently-asked-questions/#sats
Any time the SAT_NAME is filled with one of these enumerated values, the PROP_MODE must automatically be changed to "SAT".
I have tested the ADIF export and - with valid data properly entered into these two fields, the ADIF file is correct. No need to do work on it.
The purpose of this is to provide the correct list of enumerated satellites in a dropdown list for ease of use and LOTW compatibility.
Satellite tab.png (53,458 bytes)
Satellite tab.png (53,458 bytes)
Looks like this will need at least a little design work. Here are my questions so far:
I sometimes jump from problem straight to solution without the explanation.
A user wrote me to indicate the following:
"It’s been a long long time since I last tried to use HRD for satellite operation and logging. It sounds like others are steering you in the right direction. Of course Doppler tuning management is essential as is accurate rotor control. I seem to recall both has been problematic but I also remember another objection was about logging. Some of us changed to using Log4OM as it accurately logs satellite QSOs with the proper information. Maybe you can take a look at that and get some ideas, maybe that shortcoming has been solved. I hope you get there as I’ve gone back recent,y to using HRD and really like it. Id like nothing better than to do all my logging including satellite QSOs and everything else using HRD."
Furthering the dialog with him to find out, "Why doesn't HRD accurately log satellite QSOs?" I started digging into this.
It turns out, there are several problems. But for this item, I'll stick to the point.
First thing I had to conclude is that there's very little value in assuming that the way HRD does something is the correct way to do it. So what is that "mode" field in the Satellite tab? Well, SAT_MODE is listed in the ADIF spec. But there's no useful information about it at all. Further - if you look at what LOTW is expecting, there's no mention of SAT_MODE. So I conclude that it is of no use whatsoever.
Per https://lotw.arrl.org/lotw-help/satellite-qsos/ we can see that PROP_MODE is what's required (along with SAT_NAME). PROP_MODE is listed under the Propagation tab... and when a SAT_NAME is listed, then the PROP_MODE 'MUST' be "SAT" every single time. Otherwise, LOTW won't accept the QSO.
Further, allowing users to type a satellite ID into to a text box is not working. As mentioned in the ARRL documentation, the ID must be exact. So it would be AO-7... and not AO7 or AO-07 or anything else. It must be AO-7.
The fact that we've allowed people to type text into this box... and we don't populate PROP_MODE automatically when a satellite is selected in the Satellite tab is the basis for many errors. It's something we need to fix.
Given that the SAT_MODE field isn't used for anything, I doubt that anyone will miss it. Leaving it seems confusing... given that the ARRL doesn't use it.
So... it seems like a failed attempt to satisfy the LOTW requirements for PROP_MODE, but it put SAT_MODE there instead.
If we leave SAT_MODE there, it's confusing and useless. I'm advocating we hide it. But I could be talked out of it. It just leads the user to a confusing end. I suppose we could duplicate the PROP_MODE here (as we do with Locator in other situations). I'd just hide the field and leave the data. It's meaningless.
If a satellite is selected from the list (which is not enumerated by the ADIF standards... but it is enumerated by the ARRL in the provided links), then the PROP_MODE must equal SAT. The PROP_MODE is blank, by default and should remain that way. The data in the satellite ID field (and the corresponding sat name) can still be a string field. We just need to give them a pre-populated list that match what LOTW is looking for. Conceptually, this is no different from IOTA (which is also not enumerated in the ADIF standard... enumerated elsewhere... and we use that source of truth for the list of IOTAs).
If customers already have data in these fields, leave the data. If they want to update the records, they can come back and edit the records later from the enumerated list we provide.
If the user selects a satellite ID, we should populate the name.
But there are no cases where I can see us going back into someone's log and attempting to correct the mess created by the incorrect initial implementation of this. I'll leave it to the release notes and/or newsletter to explain that.
Finally, as you point out... the ADIF standards don't match what the ARRL references are. I'm not going to spend a lot of time being shocked by this. But the ARRL specifies a list of IDs... and Names. The ID exports as SAT_NAME... while the name field is not used by LOTW. Because the ADIF standard doesn't match the LOTW's enumeration, my recommended approach solves this problem. The satellite is correctly referred to by it's "ID". We correctly export that to SAT_NAME. No changes are needed with regards to exporting data. It's already fine. I verified that earlier. Yes, it was intentional... and necessary in order to address the inconsistency between the ADIF standard and the ARRL's enumeration.
Here's what I've got so far:
Does that look right? Anything missing?
We need to remove the existing "Sat Mode" and "Sat Name" fields from the UI.
[No. We need to keep them both. (I'm reversing my position on the "Mode" thing. I'll get to that in a moment.) We're changing the Sat Name field from a free-form text field to a dropdown list of satellite IDs from the ARRL's list. We'll relabel the "Mode" field to "Sat Mode" and leave it. It's going to cause confusion without a change that I'll answer further down.]
To protect customer data, the COL_SAT_MODE and COL_SAT_NAME fields stay in the database. But customers lose the ability to edit or view these fields with any part of the application. The fields are removed from the product: the logbook database view doesn't show them anymore, not visible in filters, and so on.
[No. We're not removing any fields from the product. We're changing how they get filled... and we're adding one field that doesn't have a corresponding ADIF tag. Let me try this:
Satellite Name field (COL_SAT_NAME) in the UI gets a label change to "ID". Henceforth, it will be populated from a dropdown list provided by the ARRL under "ID". For ADIF import/export, this is <SAT_NAME>. (Unfortunately, it's not the name, it's the ID. So we'll need to create a column for the satellite name as shown under "Name" in the ARRL's list.) Whatever data customers already have there should remain in-tact and displayed if they go back to reveiw the record. But it's no longer a free-form text field. They have to select one from the dropdown list. (This is actually the current behavior for Country when the user doesn't allow HRD to update the Country name on import. That is - it retains its old value until someone updates it.
Mode field in the "Ant/Sat" tab remains, but with a label change. Let's call it "SAT Mode" in the UI. No changes needed for ADIF import/export. It's a completely useless field and it's going to confuse people, unless we go after this next item.]
If the Satellite ID field is set on the Ant/Sat tab, the Propagation mode field on the Propagation tab is set to "Satellite".
[Correct. Otherwise, folks are going to think that the SAT_MODE field is where PROP_MODE is set and they won't get it set. Then their LOTW uploads won't properly get registered as satellite QSOs.]
If the Propagation mode field on the Propagation tab is set to anything but "Satellite", the Satellite ID field on the Satellite tab is cleared.
[I don't think we're changing anything about the initial population of the PROP_MODE. I would state it this way - the ID dropdown being populated is what changes the PROP_MODE field from empty to Satellite. If someone changes it from empty to Satellite without having a satellite selected in the Ant/Sat ID field, that's fine. But there aren't any changes we need to make about this. But no, I don't want to clear the items in the Satellite ID field if someone changes data in the PROP_MODE field from Satellite to something else. They'll just figure out that they need to change it to Satellite if they want it to be recognized in LOTW and other systems.]
The "name" field in the new Satellite group-box in the Ant/Sat tab is not editable.
[Correct. There's no need for users to edit this because it's already defined by the ARRL and every satellite "ID" has a name. Allowing users to edit that makes no sense.]
The database gets a new field called COL_SAT_ID. The only valid values are from the ID column of the ARRL list of satellites.
[I wouldn't do it that way. It seems like too much trouble and it screws with people who have already put data there. I mentioned some of this above, but what I would recommend is this:
ID in the UI = COL_SAT_NAME = <SAT_NAME> for ADIF import/export
Name in the UI = new column in the database; maybe COL_SAT_FULLNAME = <app_hamradiodeluxe_sat_fullname>
COL_SAT_MODE = Sat Mode in the UI = <SAT_MODE> for ADIF import/export
At ADIF import, <SAT_NAME> is set to COL_SAT_ID.
At ADIF export, COL_SAT_ID populates <SAT_NAME>. COL_SAT_MODE and COL_SAT_NAME are ignored.
[No. See above.]
If we're keeping both the "Sat Mode" and "Sat Name" fields, then we should provide an accurate mock-up to reduce confusion and facilitate a common view of the intended design. The image above has removed both of the fields.
If we keep the existing COL_SAT_MODE and COL_SAT_NAME fields, but change how they get filled from a free-entry edit field to a drop-down list, then we're obliged to find a way to handle data that exists in the database for those fields, but doesn't exist in the list of valid choices in the drop-down. Otherwise, the existing data can't be shown to the user.
To be precise, it's not possible to implement this as described:
> Whatever data customers already have there should remain in-tact and displayed if they go back to reveiw the record. But it's no longer a free-form text field. They have to select one from the dropdown list.
Or, at least, not possible to implement it as I understand it.
At this time, the COL_SAT_NAME field has an unconstrained domain: anything (including nothing) could be entered in that field. Using a drop-down list enforces a domain. Maybe nothing is in the field, and that's fine. But if something is in the field, it must be a value that's from the pre-populatd drop-down list.
Anything the user might have in the field in a pre-existing record which isn't in the set of values in the drop-down can't be displayed to the uesr.
How do we best handle existing data?
> They'll just figure out that they need to change it to Satellite if they want it to be recognized in LOTW and other systems.
I want to understand how they'll "figure it out". If I understand the process by which users learn that, and why it's prefereable to actively enforcing the edit rules in the product, I might be able to better understand the intended design.
I've updated the mockup. I'm not suggesting we remove any fields. Hopefully the new mockup makes it clear.
As for this...
"If we keep the existing COL_SAT_MODE and COL_SAT_NAME fields, but change how they get filled from a free-entry edit field to a drop-down list, then we're obliged to find a way to handle data that exists in the database for those fields, but doesn't exist in the list of valid choices in the drop-down. Otherwise, the existing data can't be shown to the user."
[I have found in the past with changes like this that the user will still see the data that was previously put there. They can change it to one of the values from the dropdown list. I'd suggest that we build it and see if this is true (and I believe that it is). There are other examples of this. If you import an ADIF where the Country name is "Nowhere"... then the import process will absolutely import "Nowhere" and place it into the Country field. The user can see it in that record. They can change it to any value in the dropdown. We see this a lot when folks are importing from other programs that do not follow the naming standard for Countries, IOTAs... etc. Let's try it and find out.
As for this...
> They'll just figure out that they need to change it to Satellite if they want it to be recognized in LOTW and other systems.
"I want to understand how they'll "figure it out". If I understand the process by which users learn that, and why it's preferable to actively enforcing the edit rules in the product, I might be able to better understand the intended design."
[So. We agree that when the user changes the value in the ID field (which is really COL_SAT_NAME = <SAT_NAME> with a new label), then we can automatically set PROP_MODE to Satellite (SAT). That's good.
The default value for COL_PROP_MODE is empty.
So help me understand how this would work...
If they populate a Satellite name in the ID field in the UI... this sets the PROP_MODE to Satellite (SAT). But if they go back to the Propagation tab and change PROP_MODE to something that makes no sense for a satellite QSO (like Tropospheric Ducting)... then we're going to do what?
Are we going to popup something that says, "You've got a satellite entered in the ID field in the Ant/Sat tab. This requires PROP_MODE = Satellite (SAT)" and prevent them from changing it?
Are we going to allow them to change it, but then go and clear the contents of ID (and thus, name) on the Ant/Sat... because something other than PROP_MODE = SAT is an invalid combination?
Satellite tab (2).png (81,269 bytes)
Satellite tab (2).png (81,269 bytes)
> There are other examples of this. If you import an ADIF where the Country name is "Nowhere"... then the import process will absolutely import "Nowhere" and place it into the Country field. The user can see it in that record. They can change it to any value in the dropdown.
This approach seems to be at conflict with the previously asserted goal of "The SAT_NAME must match the list enumerated at arrl.org".
If, instead, we want to implement a control that encourages (but doesn't enforce) the user to use one of those pre-defined values, lets them keep existing arbitrary values (not in the enumeration), and no longer allows free-form editing, we can do that. But we should re-state that goal so that it's consistent with the approach we're actually taking.
The resulting control isn't quite the simple drop-down list that was previously discussed. It's an awkward use of the control, and a bit more cumbersome to implement when compared to a generic drop-down list. But it can be done.
I think a fundamental goal of a database application is to help the user enter correct data. That goal includes rejecting bad data as well as helping the user find and repair bad data.
While the suggested approach would have new data entered come from the limited list, it doesn't help with finding or repairing existing data in this column that no longer fits the newly defined domain for the column.
What are the longer-term results of such a decision? Seems like we'll never be able to reliably use this data in any consistent way because the data itself is inconsistent.
Is that limitation adequate for our needs? Are there other resulting limitations which we should evaluate?
"This approach seems to be at conflict with the previously asserted goal of "The SAT_NAME must match the list enumerated at arrl.org"."
I don't think that's the case. I've been consistent here.
1) In the first row, we need to relabel the field from "Name" to ID. It needs a dropdown to limit the choices to the list of satellite "IDs" provided by the ARRL. Users would only have no option to put a satellite in there that is not accepted by LOTW (which prevents people from putting data in their log that doesn't match the accepted values). The field name remains COL_SAT_NAME. The ADIF import/export is <sat_name>. (Yeah, it's a bummer that - way back when this useless feature was added, that someone referred to the ID as Name. But we're not removing any fields. We're changing labels in the UI.)
2) In the second row, we need to display the corresponding satellite "name" from the ARRL list for the user selected "ID". For example, when ID=AO-10, then the "Name" displayed is "AMSAT-OSCAR 10". This can't be changed independent of the ID... because there is no other name for AO-10 than "AMSAT-OSCAR 10". Create a new field to save this in. There is no equivalent ADIF value for this.
3) In the third row, we're leaving the existing "Mode" field and relabeling it to "Sat Mode". This is COL_SAT_MODE. ADIF import/export is <sat_mode>.
4) Whenever someone populates the ID field with a satellite from the list, the PROP MODE should change to "Satellite". ADIF import/export is <prop_mode>.
5) I don't see any point in trying to parse the existing data in COL_SAT_NAME to figure out whether or not "AO10" or "AMSAT-OSCAR 10" should be changed to "AO-10".
6) I don't know of any other limitations to this approach. The existing approach is completely useless (this coming from folks other than me). I'm not too worried about the ramifications of taking something doesn't work and changing it to something that does work. AMSAT users gave me examples of two other logging programs that do exactly the same thing. It seems that sat operators expect this.
Let's say a customer has an existing database with some QSOs. Any version of the product previous to this change allows any input (at all) into the COL_SAT_NAME database field. Perhaps a user has these rows, with the corrsponding COL_SAT_NAME values:
Row 1: "AO-92" // happy case, it matches a known satellite Row 2: "AO92" // doesn't match. Close, but not exact. Row 3: "Fooey" // not even close Row 4: "" // empty, no entry Row 5: "AMSAT-OSCAR 92 (Fox-1D)" // the name (that's what we asked for!) not the ID
Only one of these (Row #1) matches the ARRL list. I guess Row #4 is okay, too, since not claiming a satellite contact is fine, so an empty field is allowed.
The rest of the rows don't contain a value that matches the ARRL ID list.
Your #5 says we don't see any point in trying to match values.
Since we're using a drop-down list to display these values, we must populate the list part of the drop-down with the ARRL list, then load the record from the database. If the COL_SAT_NAME field has a mathch, we're fine. If it's not a match, it must be added to the drop-down list and only then can it be selected and displayed. This is pretty cumbersome, and not what users really expect of such a control.
We can't treat all of the COL_SAT_NAME values in this database valid ARRL satellite IDs; they're not. If we try to send these to LOTW, we can't guarantee that we're sticking to the LOTW requirements because we've allowed data incompatible with the ARRL requirements to remain in the field. The domain of the COL_SAT_NAME is all strings, not all strings that match the ARRL ID list.
How can we reconcile the presence of rows 2, 3, and 5 with the rule that values in COL_SAT_NAME must be a member of the ARRL ID list?
I recommend a more prudent approach. Using a new column enables the establishment of a tight constraint and ensures all values in the field are valid. It partitions old rows (before this change) away from new rows (entered after this change). Additionally, the columns get meaningful names -- we're not making excuses and instead fixing the problem actively. And instead of creating technical debit with fudged names and overloaded values.
Data integrity is a key tenent of good database application design. It's difficult for me to abide a design which actively avoids the opportunity to make improve data integrity. Indeed, other parts of this product do that. But I think those are defecits, not features which should be emulated or patterns to be replicated.
Using a new column basically loses the user's ability to see the data they entered previously... and it seems virtually impossible to parse and correct data that's already there.
What will happen after these new columns are parsed? Do users have access to them in the UI?
I don't see how we can come to the conclusion that the fact that users have entered useless data in their database... already uploaded it to LOTW... wrong data... is of any vale at this point. This doesn't change the fact that the user would have to find old QSO records... correct them... and upload them to LOTW again.
I'm opposed to adding items to the dropdown list that are not valid for LOTW credit.
What do we do now?
> loses the user's ability to see the data they entered previously
We can still display it, read-only. Maybe let it be copied if it's valid, maybe make a "guess" button. We can investigate solutions and figure out what we want.
> What do we do now?
Right now, there's no validation at all. (Really, that's true for many of the fields -- there are few field validations, and almost no cross-field validations.) COL_SAT_MODE and COL_SAT_NAME are both 32 characters, and that's that: no checking against any reference lists, no looking for valid or invalid characters or formats or patterns, nothing. So the domain of each column is any string.
> This doesn't change the fact that the user would have to find old QSO records... correct them... and upload them to LOTW again.
I don't know how this fact was established. Maybe you're thinking of a use case with which I'm not familiar?
> I don't see how we can come to the conclusion that the fact that users have entered useless data in their database
I don't think we have the conclusion that the data in the COL_SAT_NAME column is useless. We don't know that it is useful, though. We don't know if it's useful or not because the data is not validated by the application when it is added to the database. Anything can show up in there.
The shortcoming of the Logbook which I presume this Mantis issue is meant to address is that the Logbook isn't helping. If it validated entered data to be correct, it would add some value to the process.
Seems like there's a pattern in which the COL_SAT_NAME data gets validated by users indirectly, though. They enter or load some data into this field, then try to upload to their favorite logging site -- LOTW, maybe. Records with bad data are rejected, so they adjust them. Through trial-and-error, they discover that COL_SAT_NAME needs to be an ARRL-specified ID, and they fix up their data to match. Once they learn that lesson, going forward they always remember to use the ARRL-specified ID.
If this supposition is true, then I think we can build a new column populated from the old one. Let's try this proposal as straw man:
Maybe we pick different names, whatever sounds good.
For ADIF import and export, maybe we need to consider using app-specific fields. We'd have to reason that through. If people use ADIF as a way to backup their HRD database (not XML?) them it's a strong reason to do so with full fidelity over round-trips.
If our belief that COL_SAT_NAME usually is a correct ARRL satellite ID, then this works out very well. Correct data is move to a column where we know all rows, all the time, have a correct Sattelite ID. And the user keeps (and can see, and can edit) the invalid data they might have lying about in the existing COL_SAT_NAME field.
We end up with almost the same UI as the "satellite tab (2)" picture. ID is strictly a drop-down, no funny business. Name is editable (not editable in the picture), and Sat Mode is remains.
I prefer this because it advances the product forward. We add a pick list for satellite names. But we also help improve data quality because we build a column that we know always contains valid satellite IDs for each row.
||Good conversation. We came to agreement. Reassigning back.|
We did make progress, but there werew a couple of items unresolved:
1) Do we show the old COL_SAT_NAMe column? Where, and how do we name it? There was a concern with it being "confusing", but no specific example of how we might remedy the anticipated problem.
2) How is the new colum named? I proposed COL_ARRL_SAT_ID.
3) There was discussion about moving fields, so it's not clear if we're keeping COL_SAT_MODE or moving it, or what we do with the existing data in that field.
1) I suggest we put something that looks like a hyperlink at the bottom of the Satellite tab that says, "Access to Legacy Satellite Fields" and then bring up a dialog box to enable folks to see these old fields. (I'll probably do a YouTube video for this because the whole thing - as a topic - is pretty expansive in concept.
2) Agreed (thought we did agree to this one).
3) We're keeping COL_SAT_MODE. But I will want to restrict it also. I've got a spreadsheet with guidance about this (attached).
In the new UI... we've got:
- the new COL_ARRL_SAT_ID... which is simply labeled "ID" in the tab/dialog box... adif import/export as <sat_name>. The contents of the field limited to the enumerated ARRL list
- we're displaying the corresponding ARRL Sat "Name" for that ID
- the "Mode" field should probably be labeled "Sat Mode". I'd like to populate Sat Mode automatically, based on the new standards for this as attached.
...then we have this hyperlink looking thing at the bottom as mentioned above
SatelliteMode.xlsx (10,464 bytes)
2) I proposed the idea, but there was never explicit agreement.
3) Actually, there was talk of putting Propagation and Satellite ID on a new tab. What you had said was this:
Propagation and Satellite seem to have more in-common than Antenna and Satellite. Maybe we should leave Antenna on it's own... and combine the Propagation and Satellite to a common tab so the use of PROP_MODE is clearer to the user?
and that's what I'm asking after. I don't see that issue answered in our chat, and it's not answered here, so I don't know what the desired design is. My understanding is that you were considering moving the Satellite fields to the "Propagation" tab.
The spreadsheet and "restriction" of COL_SAT_MODE is something completely new in the conversation and we should talk it over to resolution. It seems like we're really in the same boat as COL_SAT_NAME here because COL_SAT_MODE is a free-from string. There's no validation, existing data can be anything at all.
The spreadsheet seems to be saying that COL_SAT_MODE should be computed based on the uplink and downlink bands. Totally possible, but what do we do with previously stored values in COL_SAT_MODE?
And where do we find the bands? I don't think we store TX and RX frequencies separately in the logbook. There is provision to do so, but we don't actually show the edit control in the ALE. Since we don't have the separate frequencies, how are the necessary bands derived?
|2019-01-31 00:15||WA9PIE||New Issue|
|2019-01-31 23:58||WA9PIE||File Added: Satellite tab.png|
|2019-01-31 23:58||WA9PIE||Note Added: 0007189|
|2019-01-31 23:58||WA9PIE||Description Updated||View Revisions|
|2019-02-01 00:04||WA9PIE||Note Edited: 0007189||View Revisions|
|2019-02-01 00:08||WA9PIE||Assigned To||=> K7ZCZ|
|2019-02-01 00:08||WA9PIE||Status||new => assigned|
|2019-02-01 00:11||WA9PIE||Category||Bug => Enhancement|
|2019-02-06 14:44||K7ZCZ||Assigned To||K7ZCZ => WA9PIE|
|2019-02-06 14:44||K7ZCZ||Status||assigned => feedback|
|2019-02-06 14:44||K7ZCZ||Note Added: 0007295|
|2019-02-07 03:19||WA9PIE||Note Added: 0007302|
|2019-02-07 03:19||WA9PIE||Assigned To||WA9PIE => K7ZCZ|
|2019-02-07 11:07||K7ZCZ||Note Added: 0007306|
|2019-02-07 11:07||K7ZCZ||Assigned To||K7ZCZ => WA9PIE|
|2019-02-07 14:30||WA9PIE||Note Added: 0007307|
|2019-02-07 14:31||WA9PIE||Assigned To||WA9PIE => K7ZCZ|
|2019-02-07 19:51||K7ZCZ||Assigned To||K7ZCZ => WA9PIE|
|2019-02-07 19:51||K7ZCZ||Note Added: 0007312|
|2019-02-08 11:44||WA9PIE||File Added: Satellite tab (2).png|
|2019-02-08 11:44||WA9PIE||Note Added: 0007325|
|2019-02-08 11:44||WA9PIE||Assigned To||WA9PIE => K7ZCZ|
|2019-02-08 12:58||K7ZCZ||Note Added: 0007327|
|2019-02-08 12:58||K7ZCZ||Assigned To||K7ZCZ => WA9PIE|
|2019-02-08 17:59||WA9PIE||Note Added: 0007332|
|2019-02-08 18:00||WA9PIE||Assigned To||WA9PIE => K7ZCZ|
|2019-02-08 19:29||K7ZCZ||Note Added: 0007335|
|2019-02-08 19:29||K7ZCZ||Assigned To||K7ZCZ => WA9PIE|
|2019-02-08 20:10||K7ZCZ||Note Added: 0007336|
|2019-02-08 21:01||WA9PIE||Note Added: 0007337|
|2019-02-08 21:01||WA9PIE||Assigned To||WA9PIE => K7ZCZ|
|2019-02-09 09:32||K7ZCZ||Note Added: 0007338|
|2019-02-09 09:32||K7ZCZ||Assigned To||K7ZCZ => WA9PIE|
|2019-02-11 21:29||WA9PIE||Note Added: 0007356|
|2019-02-11 21:29||WA9PIE||Assigned To||WA9PIE => K7ZCZ|
|2019-02-11 21:29||WA9PIE||Status||feedback => assigned|
|2019-02-12 20:05||K7ZCZ||Assigned To||K7ZCZ => WA9PIE|
|2019-02-12 20:05||K7ZCZ||Note Added: 0007360|
|2019-02-13 00:40||WA9PIE||File Added: SatelliteMode.xlsx|
|2019-02-13 00:40||WA9PIE||Note Added: 0007367|
|2019-02-13 00:40||WA9PIE||Assigned To||WA9PIE => K7ZCZ|
|2019-02-13 21:09||K7ZCZ||Note Added: 0007387|
|2019-02-13 21:09||K7ZCZ||Assigned To||K7ZCZ => WA9PIE|
|2019-02-16 18:07||K7ZCZ||Relationship added||related to 0003181|