Hi Dan!
Thank you very much for your answer. I read about the bug and I might have a proposal for a solution.
The model ID string for the FT2900 seems to be defined by the state of three solder bridges, which gives us a number of 8 possible states. We need to make sure, that a image is working for one version only, that is why we want the user to decide on which version is working upfront. I would propose to make use of the generator pattern and to generate the needed classes with their properties on the fly.
Later this evening I will sketch out my idea in a patch and we can see if this might be a cure to the bug with img writing behaviour as well.
Is there already test code to mock the ID string for testing?
Best,
Daniel
On Thu, Apr 14, 2016 at 08:09:21AM -0700, Dan Smith via chirp_devel wrote:
Hi Daniel, welcome!
I am wondering hwo is "owner" of ft2900.py. Because I would like to propose a more complex change to the code, than this little patch above.
Richard Cochran is that person. You should send patches and discussion to this list though.
diff -r e7747f518dcd -r 9d480aa8aab2 chirp/drivers/ft2900.py --- a/chirp/drivers/ft2900.py Mon Apr 11 21:02:43 2016 -0400 +++ b/chirp/drivers/ft2900.py Thu Apr 14 13:43:25 2016 +0200 @@ -56,13 +56,15 @@ LOG.debug("len(header) = %s\n" % len(data))
if data == radio.IDBLOCK:
# I think this is information is worth to be loggedLOG.debug("Radio successfully identified!") breakif data != radio.IDBLOCK: raise Exception("Failed to read header")
_send(radio.pipe, ACK)
You're adding whitespace here. Can you respin this patch without that?
# initialize data, the big var that holds all memory data = ""@@ -1251,3 +1253,15 @@ MODEL = "FT-2900/1900 (Modded)" VARIANT = "Opened Xmit" IDBLOCK = "\x56\x43\x32\x33\x00\x02\xc7\x01\x01\x01"
+# this is a modded version of the FT2900E. In this version a greater +# transmit range is allowed the ARS fits the european style. To archive +# this mod one need to blank all the jumpers in the control head, but the +# first +@directory.register +class FT2900ModERadio(FT2900Radio):
- """Yaesu FT-2900EMod"""
- MODEL = "FT-2900/1900 (Modded E)"
- VARIANT = "Opened Xmit E Version"
- IDBLOCK = "\x56\x43\x32\x33\x00\x02\xc3\x02\x01\x01"
So, we have an outstanding bug and test failure with the 2900 that Richard is currently working on. Maybe you can help with that, but I think merely adding the above makes the problem worse.
The problem is that we don't properly detect the difference between the current base and modded radios when opening them from a file. I believe your 2900EMod radio will add a third ambiguous option there.
Can you run the tests to reproduce and maybe have a go at fixing it? I'm not sure whether we should hold off on applying this until we fix that problem or not. Thoughts?
See the following references for more information:
http://intrepid.danplanet.com/pipermail/chirp_devel/2016-April/003907.html
http://chirp.danplanet.com/issues/3557
Thanks!
--Dan _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers