Feature Request: Behavior of logging fields

Hi WRL team

In discussion with other hams I am realizing that expectations for a logging mask can vary greatly. Based on these discussions, I submit the following feature request:

It would be great, if I could decide for each logging field whether it …

  • at the beginning is empty, or

  • at the beginning has the WRL default value (“599”), or

  • at the beginning contains a individual default value which I can determine myself (when chosing this option, the entry already specified is then set), or

  • at the beginning adopts the value from the last saved QSO, if this is not older than 15 minutes, otherwise is empty.

(The following shall continue to apply: Information received from the TRX via the CAT interface overrides any previous values.)

I could imagine that there is a tiny button above each logging field (to the left of the label) that allows you to switch between these four views. And WRL software saves this individual setting for each logbook I have.

73 de Pepe DL/HB9EVT/P

3 Likes

Hey Pepe,

I think having this as a part of the logbook settings would be a possibility. I’ll add it as a mini feature open for discussion and we’ll go from there. Thanks for the suggestion!

Thanks & 73
Brad K4AZE

1 Like

Hi Brad @K4AZE

The more I think about it (also in connection with the current beta tests), I realize that this is not simply “mini.”

In general a logbook field has the following properties:

  • It has a title and an ADIF name (when exporting).

  • It has a data format, which can be text, integer, date, time, URL, or selection menu (e.g. selection of band). And for selection menus there are two sub-types: Only an existing list entry can be selected, or another value can also be entered (this would make sense, for example, when selecting the mode, as new ones are constantly being invented).

  • When I enter a new contact, it can be empty (e.g., the “Their Locator” field), have a default value (“599”), or be filled with the value of the previous contact (as with the Power field when logging within WSJT-X).

With the introduction of individual log fields, a way should be created to assign these properties to an individual field. This is the only way to create exciting new logbook templates.

Since most of the features listed above already exist in connection with the existing logging fields, the challenge really lies in how to integrate a toolbox into the Template Creator.

73 Pepe

3 Likes

I wouldn’t get to caught up with the terminology its just what we call tasks that aren’t major features (ie the full custom logbook template creator, logging streaks, desktop app, etc etc). But yes your right its about how to integrate it properly.

Thanks & 73
Brad K4AZE

1 Like

@HB9EVT @K4AZE I definitely agree we should add some more logging settings, thanks for kicking off the discussion here.

It seems like the actual setting depends heavily on the field.

  • Frequency is heavily dynamic. It depends on spotting data, CAT control, etc. and requires a flow chart to really explain how it is controlled. We could add some options to give more control over how frequency is set, but once CAT control is enabled, it pretty much takes over and the other settings don’t matter as much.
  • RST Sent and RST Received - there is a good use case here for allowing them to be set to a default value or left blank, as a configurable option. I can’t immediately think of a case where you would want to persist the signal reports.
  • Mode - I could imagine a setting of 1) set mode automatically based on frequency or 2) manual mode selection only.
  • Power - this should always persist unless changed or cleared.
  • Their Park Number / SOTA etc. - this should always clear after the contact is logged. There is a use case for improving logging for two operators at the same activity site, but we can handle that in a better way.

After giving this some thought, I believe the most value for this feature will be by creating specific controls for the individual logbook field, rather than generic field controls (like persist or clear after each contact), since most of the fields have very specific behavior.

Let me know what you guys think.

1 Like

Hi James @N0WRL and Brad @K4AZE

Thank you for taking a look at my feature request.

Behavior of ‘Their Callsign’
The question of whether a field should be deleted, the last value entered should be retained, or the default value should be restored should only be asked if a contact has been saved or the ‘CLEAR’ button has been pressed.

But if I just delete the characters in the ‘Their Callsign’ field, please do not change the other fields. During a QSO, it sometimes happens that you realize after listening again that the callsign was misunderstood the first time it was called, and you want to correct it. If you now delete all characters from the callsign field and retype the callsign, all other information should not be lost.


CAT control

I agree


Frequency

I agree. This is not a field, where its behavior shouldn’t be influenced by the user.


Mode
When I make my first QSO of the day, it’s nice that the tool suggests the most likely mode based on the frequency. But if I then change it to ‘SSTV’ and save the first contact, I would be happy if ‘SSTV’ remained. My next QSO will most likely be in the same mode. :wink:

So my proposal is, to add a “3)” :smile:

or 3) set mode automatically when the logbook opens, afterwards keep the entry of the contact before.

Personally, I would always prefer “3)” and never choose “2)”. But there are certainly users who prefer “2)”, so I would pursue all three options.


Power

This is the behavior I personally am prefering. Nevertheless, I would also offer the “empty” option here. Sooner or later, a user will express exactly this wish.


Their OTA number

For the mentioned problem (2 Op at same activity site) I have two suggestions for a solution:

a) The last entry saved in the selection list is displayed at the top, followed by all the others in the usual order.

b) The last entry saved is displayed as a clickable button, and I can copy this OTA number into the field with a single click.

Just two ideas for your brainstorming.


Powerful individual fields

I like this approach.

And in general I recommend:

The standard logbooks should be kept simple and beginner-friendly.

(This is an USP[1] of WRL – compared to other large logging suites, where you are completely overwhelmed the first time you use them with the countless logbook fields that try to cover every possible variation of our wonderful hobby.)

On the other hand, the template creator should allow everyone to put together their own logbook with powerful features for advanced users. With this approach, WRL is the ideal solution for both: new and experienced hams.

73 Pepe


  1. Unique Selling Proposition ↩︎

2 Likes

Well said Pepe :clap::clap:

We’re well aligned here. Now it’s just about prioritizing and getting some of these enhancements in to the platform.

Thanks for taking the time to analyze this feature :folded_hands:t2:

1 Like