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

[Pavel Milanes (CO7WT)]

Hi, re-read this to put my answer in context:

El 26/02/16 a las 15:42, Richard Cochran via chirp_devel escribió:
>
> I can easily make the download routine more lenient, so that a 
> mismatch in the IDBLOCK doesn’t prevent a download.  But on upload, 
> the radio insists on getting the correct IDBLOCK, and will abort the 
> upload if the IDBLOCK isn’t exactly what it is expecting.   And the 
> only way I have of knowing which IDBLOCK to send is by having the user 
> choose the correct model radio.
>

 From my thinking you will have several paths: (#1 has my vote)

1 - Registering another radio class; as you did. This in fact is the 
approach I have followed with the recent Kenwoods included, there is 
just one driver to the entire family and then you have variations in the 
freq range, channel numbers, etc, see driver class tk760g.py, tk760.py 
and tk270.py all of this uses the same strategy, but this are different 
radio models that use the same driver.

I think the Baofengs uses the same approach with a different implementation.

2 - Look "beyond". I know the Yaesus are different beasts, but we 
recently discovered that the BTECHs for example have a mem space beyond 
the one used by the factory software, in that mem area reside the ID, 
you can try this is this yaesu is interactive.


3 - Attach the ID string to the image. Yes you can attach the Id string 
at the end of the image, so when you are going to write to the radio you 
know what ID is the correct one and you are preventing the users to 
overwrite different radio images. Of course this can cause troubles to 
the users already using the software (now with short saved images of the 
radio) but some code can fix that (and a notice to the users.)

My 5 cents, 73 CO7WT.