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

[Richard Cochran]

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
+ at 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 at sonic.net




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20160226/45d0a0e8/attachment-0001.html