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.