Actions
Bug #6461
closedgmrsuv1.py needs custom valid_tuning_steps
Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
02/16/2019
Due date:
% Done:
0%
Estimated time:
Chirp Version:
daily
Model affected:
gmrs-v1
Platform:
Windows
I read the instructions above:
Description
The gmrsuv1 driver doesn't override the @valid_tuning_steps@ attribute. Since "3589a27c8c5f":https://chirp.danplanet.com/projects/chirp/repository/revisions/3589a27c8c5f made the default for @valid_tuning_steps@ much more conservative, the driver now needs its @valid_tuning_steps@ overridden. It might be possible to override those values in baofeng_common, instead, but I don't own any other Baofeng radios with which to test that.
The radio supports the following steps:
2.5, 5.0, 6.25, 10.0, 12.5, 20.0, 25.0, 50.0
The issue can be checked by attempting to set a memory in the radio to 462.7125, for example.
To my surprise, this bug causes two validation errors:
First is "Tuning step 12.5 not supported" "here":https://chirp.danplanet.com/projects/chirp/repository/annotate/chirp/chirp_common.py#L927. I don't understand this because gmrsuv1 doesn't set @mem.tuning_step@, and that attribute "should default to 5.0":https://chirp.danplanet.com/projects/chirp/repository/annotate/chirp/chirp_common.py#L258. I would appreciate someone who understands the codebase better explaining what's going on. Since I haven't attempted any dynamic analysis, only read through code, I'm probably just missing something.¶
Second is "Frequency requires 12.5kHz step" "here":https://chirp.danplanet.com/projects/chirp/repository/annotate/chirp/chirp_common.py#L971, which makes total sense, and should be fixed by properly setting the @valid_tuning_steps@ for gmrsuv1 (or possibly baofeng_common).¶
Actions