Low Tune / High Tune

[john-]

I see the following behavior:

1. User does not use command line switch to set Low Tune and High Tune
2. In ham2mon, user uses "/" to change RF Freq
3. The Low Tune/High tune values in the UI do not change

I would expect these values to change when user does not specify Low and High Tune and RF Freq is changed.

Is the Low/High Tune feature being used? The other bug in this area that was fixed combined with this one makes me think it is not.

I ask this because if we start to add options to step through big/multiple ranges this will all get even more complex.

If we feel Low/High tune is needed I will take a look at fixing it before starting on any other scanning changes.

[lordmorgul]

This was a feature I added quickly while doing some others and I personally do not use it. Agree it was not thoroughly tested. The intent was to allow a wideband SDR sampling but limit range of signals of interest; an alternate way versus specifying channels of interest.

I think an amateur listening to scanner may want to be able to keep nearby commercial license frequencies from getting selected, but that is the only use case I has for that. They could just be expected to limit the SDR sampling range instead.

[lordmorgul]

Those values were supposed to be getting changed in the scanner.py set_center_freq() function, I think it is just the UI is not getting updated but the tune limit is. Agree that maintaining those while scanning ranges does not make sense, at least would expect to shift those out to the freq range of hardware for each band scanned if the feature is kept.
Ok either way removing this or not.

[john-]

Thanks for the insight.

For now I will take a stab at fixing this feature. This is because there may be a need to use something related to it with the wide range scanning: When the wide range is broken up there maybe portions that are only part of the full sampling rate. I will diagram that out and run it by you but that is down the road.

I haven't thought through the base feature but would it make sense to move the GUI representation into the SPECTRUM display? Maybe use the color grey or something to denote the section being filtered out? This would be instead of the Low/High Tune entries in the RECEIVER section.

It looks like you did the spectrum bar coloration feature so please let me know if this makes sense or is even feasible.

[lordmorgul]

Yes I think it would be pretty easy to visually indicate the filtered out area. I had thought of doing that both with color (Grey is good) and a different character to draw the spectrum power bars. I wanted to mark lockout in the soectrum display as well, possibly with orange but had not worked that out.

[john-]

As I get deeper into it may be as you mentioned: Just being a gui update issue. In fact it may not even be that as I am not sure what we want the behavior to be when RF Freq changes.

I still lean towards getting these values out of the RECEIVER section and will look into that.

[lordmorgul]

For the multiple band scanner feature I would think that these values perhaps aren't used anyway, or they are forced to the max range of the band identified to scan. I think that makes sense because you're retuning the scan range fairly quickly anyway, and you would expect the user to have defined a valid range they want not dynamically change that range. The intent of these low/high were more to allow changing the valid range interactively while the program is running and the total scan bandwidth and sampling is already set and going. So for that it makes sense to do visually in spectrum, keystrokes would just start greying out more bins on left or right sides basically.

[lordmorgul]

issue may be that self.low_bound and self.high_bound are never updated when frequency is changed. The channels are removed by being within those bound variables (these are referenced in baseband, not RF) while the set_center_freq function and the receiver display window only use the min_freq and max_freq variables (these two are in RF in Hz). In ham2mon.py when rxwin.center_freq is changed by hard keypress then scanner.center_freq is updated, the rxwin freq_low and freq_high are not changed to match.

I think the freq_low and freq_high variables are unneeded and should be removed, it is basically duplicating the bounds and confusing to update both. Limiting the spectrum's channel assignable range can be done in baseband by the bounds, and the command line input for that can be immediately converted from RF to baseband. Then, when set_center_freq is called to change frequency the min_freq and max_freq are updated as already being done, but the lower and upper bound does not need to be changed because it is baseband and stays that way.

[john-]

Thanks for the info.

I did rework how this functions. Later today I will update this thread with a squashed branch that you can take a look at. I did make some assumptions that can be revisited.

Here is the summary:

1. Low/High Tune now operate as a lockout: Like a frequency lockout, all the frequencies between low and high are locked out.
2. The values are removed from the RECEIVER section.
3. They are configured through an extended version of the lockout file (enabled with -l/--lockout).

Unlike current lockout, they cannot be added dynamically. However, down the road a keystroke based selection can be added. For example, "<" to start setting the low bound and arrow keys to move it in the spectrum.

Also, in the legacy functionality I do not see capability to save dynamically added lockouts. At some point this needs to be added.

[john-]

Here is the branch that changes lockout of ranges. This is a breaking change as the format of the lockout file has changed.

Legacy: Text file where each line was a frequency in Hz to lockout
This branch: YAML file that can be used to specify frequency in Mhz or range in Mhz to lockout. There is an example file that shows this.

So previous file used Hz but I did this in Mhz. Is there a reason Hz should be used? This can easily be changed. I find Mhz more comfortable but maybe there are cases I am missing.

https://github.com/john-/ham2mon/tree/lockout_range_squashed

Of course more testing is needed but as long as I didn't break single frequency lockout it should be an improvement :)

Update: I just realized that my git skills are such that this branch also contains a smaller one that migrates python deprecated optparse to the newer argparse. It does a couple of other smaller things as well.

[john-]

Also, I am holding off merging things into my master until we can get things synced up between our repositories a little better. I will open a separate discussion on this topic.

[lordmorgul]

MHz should be fine and I have no concern with migration to YAML. I saw the argparse change but haven't reviewed or tested anything deliberately there. I've been running your master branch and my latest with priority updates side by side for a month plus I just have not had time to code. Trying to get back to that and sync the prioritization into a branch in your repo in coming week or two then we can consolidate all the branches.

[john-]

I need to get back into this myself...lost in the branches :)

[john-]

An important thing to note:

Previously, low tune/high tune was a range was a pass type filter: Frequencies outside this range were ignore.

With the branch I mentioned in the Dec 2 comment, this is not like lockout frequencies: Frequencies in the range are ignored.

This consistency allows them to appear int the LOCKOUT gui section.

[john-]

Closing this as it has been merged into my repository.