Thanks Rick, but what I meant is that the tuning steps are valid and some frequencies are not tunable but the radio, so CHIRP should adjust an [imported] frequency to one that matches a valid tuning step.
Brad Schuler
On Dec 20, 2020, at 3:49 PM, Rick (AA0RD) DeWitt aa0rd@yahoo.com wrote:
Try setting features- rf.has_nostep_tuning = True and to disable the tuning step column in the UI- rf.has_tuning_step = False
<Signature-RIck-AA0RD-Image.jpg> On 12/20/2020 2:07 PM, Jim Unroe via chirp_devel wrote:
On Wed, Dec 2, 2020 at 5:56 PM Brad & Cindy Schuler via chirp_devel chirp_devel@intrepid.danplanet.commailto:chirp_devel@intrepid.danplanet.com wrote:
Is there a convention for how a driver should handle frequencies that are not tunable due to tuning step capabilities?
For instance, the radio cannot tune 450.611 so the radio refuses user entry (onboard keypad), but when 450.612 is entered the radio automatically adds 500 Hz to make 450.6125.
In what functions of the software might the driver raise an exception and where might it auto-adjust a given frequency to fit an available tuning step?
Thanks for the guidance,
Brad Schuler
K0BAS
Brad,
After seeing Dan's reply, this reminded me that I just did this same thing for the anytone.py driver. The frequency 450.6125 is stored in the radio as 450.612 but the radio knows to tune the correct frequency. Here is how I coded CHIRP to know how to show the full frequency.
https://chirp.danplanet.com/projects/chirp/repository/revisions/3d796d647766...
Jim KC9HI _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.commailto:chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
