Project

General

Profile

Actions

Bug #11545

open

CHIRP does not take into account VALID_BAND on subclassed drivers

Added by Francisco M 2 months ago. Updated 2 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
09/16/2024
Due date:
% Done:

0%

Estimated time:
Chirp Version:
next
Model affected:
Retevis RT22
Platform:
Windows
Debug Log:
I read the instructions above:
Yes

Description

Detected while experimenting with Baofeng BF-T20 and re-writing the subclassed RT22 driver.

Retevis RT22 driver:

rf.valid_bands = [(400000000, 520000000)]

Baofeng BF-T20 driver:

@directory.register
class BFT20_TestDriver(RT22Radio):
    """Baofeng BF-T20"""
    VENDOR = "Baofeng"
    MODEL = "BF-T20"
    VALID_BANDS = [(400000000, 470000000)]

    _fileid = [b"P330h33",
               b"P32073" + b"\xF8\xFF",
               ]

Added the documented VALID_BANDS for the BF-T20 and changed the driver name just to check if modifications where actually taking effect:

Tried to introduce out of range frequency value for the new BF-T20 VALID_BANDS, and value was accepted. Expected behaviour did not occur:

Tried to introduce out of range frequency value for the RT22 primitive driver VALID_BANDS, and value was not accepted:


Files

Actions #1

Updated by Dan Smith 2 months ago

It's not meant to. The value that matters for a given radio is what is returned from get_features(). Some implementations have used VALID_BANDS= as a thing that gets referenced from a base class's get_features() but the core of CHIRP does not look at that.

Actions

Also available in: Atom PDF