Project

General

Profile

Actions

Bug #5759

closed

tuning steps general UI response

Added by Henk Groningen over 6 years ago. Updated almost 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
04/27/2018
Due date:
% Done:

0%

Estimated time:
Chirp Version:
daily
Model affected:
(All models)
Platform:
All
Debug Log:
I read the instructions above:

Description

This might be an issue, or just me beeing stupid ...

In the CHIRP UI I can't freely enter frequencies. They are limited to a default set of steps.
This is the UI since in the browser I an enter any frequency I want.
The shortcut is to define

rf.has_nostep_tuning = True

This is honoured and input is free.

But than I want to limit the input to 1 kHz steps.
so I get this:

        rf.has_tuning_step = True
        rf.valid_tuning_steps = [1,5,6.25,10,12.5,25] """ or whatever list """
        """ rf.has_nostep_tuning = False """ 

This does not allow me to enter 1 kHz steps. I've looked into several drivers and they use either the above method
or first define STEPS = [5,6.25, .. ] and later rf.valid_tuning_steps = list(STEPS).
So this appears to be the correct method. I tested with ub-B5 and BF-T1, but adding 1 to the list does not give 1 kHz steps in the UI.

I also tried appending the 1 kHz step to chirp_common.TUNING_STEPS, but that does not help either.
So has_nostep_tuning is honoured in the UI, has_tuning_step isn't. I would expect the UI to round the input
to the nearest fitting step.

I did find a small remark in chirp_common that seems to refer to this, so might be an issue allready tackled.

There is another confusing thing here: if has_tuning_step = false, why should I add has_nostep_tuning?
They seem to be mutual exclusive.

Any thoughts on this are appreciated

Regards,

Henk , PA3CQN

Actions #1

Updated by Henk Groningen over 6 years ago

Disregard this. Read some more in the source and the problem is already known, and I see why it is not an easy fix.
Scrap my remark about the two setting beeing mutual exclusive: the two variables are actually something completely different, despite beeing simular in name.
As I see it now the UI always uses chirp_common.TUNING_STEPS. Perhaps this should become rf.valid_tuning_steps if defined in the driver.
Anyway: more complicated than I expected.

Actions #2

Updated by Bernhard Hailer almost 5 years ago

  • Status changed from New to Closed
  • Chirp Version changed from 0.4.0 to daily
  • Platform changed from Windows to All

Closed; submitter suggested to disregard.

Actions

Also available in: Atom PDF