[chirp_devel] How to best handle slight radio variations (issue #3387)

[Tom Hayward]

On Fri, Feb 26, 2016 at 12:42 PM, Richard Cochran via chirp_devel
<chirp_devel at intrepid.danplanet.com> wrote:
> I have developed a fix for this issue by registering yet another variant of
> the FT-2900 radio, similar to what was done with the Euro version.  I got
> out my soldering iron, altered my own radio to duplicate the issue reported
> in issue #3387, and tested the altered driver, verified that it works, and
> then put my radio back to its original configuration.  So this strategy
> works, but I wonder if there’s a better way to avoid cluttering up the list
> of supported radios too much.

We've had issues with other Yaesu models where someone attempts to
upload an img from one variant to a radio with another. The radio
reports an error and they come to the mailing list asking what the
problem was. The way you've done it, the Euro and modded variants will
have different labels in Chirp, so it should be a little more apparent
to the user that they are different and incompatible.

Your solution is already "technically elegant"--a subclass is a
perfect way to handle a variant. The code is minimal and it's easy to
understand.

My vote is to keep doing it the way you've been doing it!

Tom KD7LXL