Format for lockout and priority files

[john-]

Ham2mon uses different formats for priority files and lockout files. Also, it does not support a file for general configuration of frequency metadata. For frequencies, it only displays the frequency in Mhz. It would be good if it also displayed user friendly labels for scanned channels.

What are your thoughts on a file with a YAML format something like this:

frequencies:
  - label: "Active mobile channel"
    single: 450.225
    priority: true
  - label: "Mobile UHF of interest"
    lo: 450
    hi: 452
    priority: true
  - label: "data"
    single: 151.675
    lockout: true
  - label: "FRS channels 1-7"
    lo: 462.5625
    hi: 462.7125
    lockout: true
  - label: "70cm FM Simplex Calling"
    single: 446.0
  - label: "FRS channels 8-14"
    lo: 467.5625
    hi: 467.7125

This format would consolidate the lockout and priority files as well as provide user friendly descriptions for frequencies in general.

The UI could be modified to display the label instead of (or in addition to) the frequency.

The format can be extended with other metadata. In addition, other configuration information could be added (command line options supplied would take precedent).

I haven't though through how practical this is yet. There is current;y is no "save" option for priority or lockout information so that would need to be considered.

[john-]

Here is the branch which implements this change and other changes.

Summary of breaking changes:

• Priority and lockout configuration is now in a single YAML connfiguration file
  • -p and -l options are replaced by the -F option
  • All frequency values are now in Mhz and no longer in Hz
  • See the example file for details
• Frequency entry at the command line is in Mhz and no longer in Hz

Non breaking changes:

• Priority frequency ranges can now be specified in addition to specific priority frequencies
• User interface can now show labels for frequencies
• Refactored channel metadata handling
• Channel log functionality moved from demodulators to scanner (where @lordmorgul originally had it)
  • This allows channel logger to contain additional metadata such as assigned priority
• Refactored cursesgui to only redraw screen where data changes
  • No changes were made to SPECTRUM section

Testing completed:

• Tested against master with no configuration, with lockouts, with priority channels, with both lockout and priority channels configured
• Priority and lockout ranges

[lordmorgul]

I have not pulled this code yet but I like the idea and the file format.
It would be nice to be able to specify showing freq only, label only (unless a demod gets assigned and no label available), or both. Toggling labels on and off with keystroke would be more dynamic option.

One of the issues with assigning labels or priority channels that I wanted to work on before is that sometimes the channel binning detects a bin immediately next to a priority frequency, but slightly off (like being 2.5k low of a 15k channel center). This ended up creating a new log entry, save wav file, and not detecting as priority for that demod period and could flicker back and forth on and off freq for the same signal. Using a wider channel bandwidth entirely causes misses on peak frequency. This may be just something that needs more hand tuning of the right channel BW to pick, but it seemed like for a small number of frequencies you would not want to mis-detect peak if you know that priority is what you want to hear.

My plan was a setting in the label/priority input for "sticky channel", or a BW assigned to the channel, which would then detect any bin close enough to center of an assigned channel as being that frequency and force the demod assignment to get on frequency instead of shifted.

We have a global setting for this, the channel BW, but with the wideband scanning now the channel bandwidth may not be ideal to keep the same across scanning ranges either.

I have not thought about how hard changing channel BW would be per scanning range, and have now forgotten if we already talked about that.

[john-]

I have not pulled this code yet but I like the idea and the file format. It would be nice to be able to specify showing freq only, label only (unless a demod gets assigned and no label available), or both. Toggling labels on and off with keystroke would be more dynamic option.

For sure those features can be added.

One of the issues with assigning labels or priority channels that I wanted to work on before is that sometimes the channel binning detects a bin immediately next to a priority frequency, but slightly off (like being 2.5k low of a 15k channel center). This ended up creating a new log entry, save wav file, and not detecting as priority for that demod period and could flicker back and forth on and off freq for the same signal. Using a wider channel bandwidth entirely causes misses on peak frequency. This may be just something that needs more hand tuning of the right channel BW to pick, but it seemed like for a small number of frequencies you would not want to mis-detect peak if you know that priority is what you want to hear.

My plan was a setting in the label/priority input for "sticky channel", or a BW assigned to the channel, which would then detect any bin close enough to center of an assigned channel as being that frequency and force the demod assignment to get on frequency instead of shifted.

We have a global setting for this, the channel BW, but with the wideband scanning now the channel bandwidth may not be ideal to keep the same across scanning ranges either.

I have not thought about how hard changing channel BW would be per scanning range, and have now forgotten if we already talked about that.

We probably have talked about all of this and I need to get my head around it. Is frequency specific BW addressing the core issue? I can look at this if you think it is the case...I am just not clear on the problem to say myself what the correct way to address it is.

[lordmorgul]

Yes I would say frequency specific (in bands) BW is the enhancement. Not really an issue, and probably still not a priority to consider it, but I think this format change sets up doing it later.

[john-]

This is now merged into master branch. As indicated there are breaking changes.