Project

General

Profile

Actions

Bug #6461

closed

gmrsuv1.py needs custom valid_tuning_steps

Added by Riley Avron about 5 years ago. Updated about 5 years ago.

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
Debug Log:
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

Also available in: Atom PDF