[chirp_devel] How to best handle slight radio variations (issue #3387)
I’m the guy who developed most of the Yaesu FT-2900 driver. An issue has recently been reported where the driver doesn’t work with one variant of the radio. Apparently the radio has had some solder bridges changed, to alter the configuration.
The way the cloning process for this radio works is that, on download, the radio sends a short IDBLOCK to the computer, which the computer looks at, compares with what it expects, and then discards (or reports an error). The radio then sends a series of regular-sized data blocks, and finally, it sends a checksum, which is checked and discarded. Only the standard data blocks are saved in the .img file. This is the strategy used in the FT-2800 driver, which I used as inspiration for the FT-2900 upload/download.
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.
There was a similar issue reported long ago with the European versus US version of that radio (the Euro/USA modification can also be done by altering the solder bridges). It was addressed by registering a separate version of the radio, with an overridden variable containing the appropriate IDBLOCK.
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.
For anyone interested in the gory details, this is the diff that seems to fix the problem.
--- a/chirp/drivers/ft2900.py Mon Feb 22 09:52:12 2016 -0800 +++ b/chirp/drivers/ft2900.py Fri Feb 26 09:40:08 2016 -0800 @@ -658,3 +658,15 @@ MODEL = "FT-2900E/1900E" VARIANT = "E" IDBLOCK = "\x56\x43\x32\x33\x00\x02\x41\x02\x01\x01" + +# the FT2900Mod is a version of the radio that has been modified to +# allow transmit on a greater range of frequencies. It is almost +# identical to the standard version, except for the model number and +# ID Block. We create and register a class for it, with only the +# needed overrides +@directory.register +class FT2900ModRadio(FT2900Radio): + """Yaesu FT-2900Mod""" + MODEL = "FT-2900Mod/1900Mod" + VARIANT = "Opened Xmit" + IDBLOCK = "\x56\x43\x32\x33\x00\x02\xc7\x01\x01\x01"
My purpose in sending this query to the list is to find out if anyone else has run across a similar problem and figured out a more technically elegant solution.
Richard Cochran ag6qr@sonic.net
On Fri, Feb 26, 2016 at 12:42 PM, Richard Cochran via chirp_devel chirp_devel@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
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.
Thanks so much for the feedback. It confirms that, while there are alternate approaches, they’re not without their drawbacks, and the approach I chose was reasonable. I’m going with it. I’ve emailed the patch to the list.
Richard Cochran ag6qr@sonic.net
participants (3)
-
Pavel Milanes (CO7WT) -
Richard Cochran -
Tom Hayward