View Issue Details

IDProjectCategoryView StatusLast Update
00031423 - Current Dev ListEnhancementpublic2019-04-25 19:31
ReporterWA9PIEAssigned ToWA9PIE 
PrioritynormalSeverityminorReproducibilityhave not tried
Status assignedResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0003142: Logbook does not offer a list of satellites; this causes problems with LOTW upload (and probably awards)
DescriptionA 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.

Some resources:

https://www.amsat.org/logging-satellite-qsos-with-logbook-of-the-world/
https://lotw.arrl.org/lotw-help/frequently-asked-questions/#sats

https://lotw.arrl.org/lotw-help/submitting-qsos/
"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."
https://lotw.arrl.org/lotw-help/satellite-qsos/
TagsNo tags attached.
ModuleLogbook
Sub-ModuleData
TestingNot Started

Relationships

related to 0003181 resolvedK7ZCZ Logbook requires a database schema migration solution 

Activities

WA9PIE

2019-01-31 23:58

administrator   ~0007189

Last edited: 2019-02-01 00:04

View 2 revisions

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)

K7ZCZ

2019-02-06 14:44

manager   ~0007295

Looks like this will need at least a little design work. Here are my questions so far:


  • The product currently has "mode" field here; there are instructions to remove it. What becomes of the data that customers have stored in this field? It never sees the light of day again?


  • The screen shot is annotated with text thats says "whenever Satellite ID is filled with one of these values, Propagation Mode MUST be "Satellite"". What does this specifically mean for the UI? Maybe the Prop mode drop-down is set to "Satellite" and disabled when a satellite is chosen; and when "Satellite" is chosen as a prop mode, the form won't save if a specific Satellite name isn't chosen. Or, maybe some other design is desired.


  • The ADIF specification doesn't seem to say that SAT_MODE is an enumeration; it's just a string. What is meant to be stored there? The existing propagation field in the product is wired to the ADIF "PROP_MODE" field, which is an enumeration.


  • The current product shows an editable Name field, and I expect customers already have data in this field. In the screen shot, the "name" text appears to be static and not editable. Is that the intended design? That would mean customers can't ever edit the names they've previous input.


  • What becomes of existing customer data in the name field, then? Is it matched to an ADIF satellite name? If a match is found, is ID populated automatically? What if the name is not a match?


  • The nomenclature seems like it might be off. ADIF specifies a SAT_NAME field. The advice in this issue is that the satellite ID is exported in the SAT_NAME field, not the satellite name. Is that intentional?


WA9PIE

2019-02-07 03:19

administrator   ~0007302

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.

K7ZCZ

2019-02-07 11:07

manager   ~0007306

Here's what I've got so far:


  • We need to remove the existing "Sat Mode" and "Sat Name" fields from the UI.

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

  • If the Satellite ID field is set on the Ant/Sat tab, the Propagation mode field on the Propagation tab is set to "Satellite".

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

  • The "name" field in the new Satellite group-box in the Ant/Sat tab is not editable.

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

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



Does that look right? Anything missing?

WA9PIE

2019-02-07 14:30

administrator   ~0007307

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.

[See above]

At ADIF export, COL_SAT_ID populates <SAT_NAME>. COL_SAT_MODE and COL_SAT_NAME are ignored.
[No. See above.]

K7ZCZ

2019-02-07 19:51

manager   ~0007312

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.

WA9PIE

2019-02-08 11:44

administrator   ~0007325

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)

K7ZCZ

2019-02-08 12:58

manager   ~0007327

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

WA9PIE

2019-02-08 17:59

administrator   ~0007332

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

K7ZCZ

2019-02-08 19:29

manager   ~0007335

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?

K7ZCZ

2019-02-08 20:10

manager   ~0007336

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.

WA9PIE

2019-02-08 21:01

administrator   ~0007337

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?

K7ZCZ

2019-02-09 09:32

manager   ~0007338

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


  • We add COL_SAT_ARRL_ID to the database.

  • New databases are created with COL_SAT_ARRL_ID.

  • Existing databases are migrated by adding the COL_SAT_ARRL_ID column. COL_SAT_ARRL_ID is initially populated by examining each row's COL_SAT_NAME field. If the COL_SAT_NAME field is a valid ID from the ARRL list, its value is moved to COL_SAT_ARRL_ID and COL_SAT_NAME is cleared. Otherwise, no change is made to the record.

  • In the application, COL_SAT_ARRL_ID is populated from a drop-down, strictly. No extra entries, no fudging the list to include extra maybe-valid values. COL_SAT_NAME remains and is editable.

  • COL_SAT_NAME is editable as a text field, no constraints. Maybe we add a button that looks up the name from the matching ARRL ID. But since this field isn't used for reporting to LOTW, that's fine.

  • At ADIF export: COL_SAT_NAME is ignored. COL_SAT_ARRL_ID is set to <SAT_NAME>. COL_SAT_MODE is set to <SAT_MODE>.

  • At ADIF import: <SAT_MODE> populates COL_SAT_MODE. <SAT_NAME> populates COL_SAT_ARRL_ID or COL_SAT_NAME using the same rule as the migration does.



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.

WA9PIE

2019-02-11 21:29

administrator   ~0007356

Good conversation. We came to agreement. Reassigning back.

K7ZCZ

2019-02-12 20:05

manager   ~0007360

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.

WA9PIE

2019-02-13 00:40

administrator   ~0007367

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

So...

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

Good?

SatelliteMode.xlsx (10,464 bytes)

K7ZCZ

2019-02-13 21:09

manager   ~0007387

1) okay

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?

WA9PIE

2019-02-27 11:17

administrator   ~0007524

After reading further dialog on the AMSAT email reflector this came up:

https://lotw.arrl.org/lotw-help/configxml/?lang=en

They say that the list of satellites on the ARRL's web page is not always current. But they say that this file that TQSL pulls down is constantly updated for the list of satellites.

Question - should we be using this same file, obtained from its source, to build the list referenced in this change?

WA9PIE

2019-04-25 19:31

administrator   ~0007891

I finally got around to uploading my satellite QSOs to LOTW. Even after all my research into this, I still managed to manually enter my required information into our fields incorrectly. This confirms that this problem is real. A drop-down list is needed.

I found that the TQSL program has an updated list of satellites we could use. It's contained within: C:\Program Files (x86)\TrustedQSL\config.xml

Issue History

Date Modified Username Field Change
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
2019-02-27 11:17 WA9PIE Note Added: 0007524
2019-04-25 19:31 WA9PIE Note Added: 0007891