[chirp_devel] [PATCH] [FT2900] add support for xmit modded FT2900E
Hi Guys!
Please find attached a patch to make Chirp work with a xmit modded Yaesu FT2900E. I am happy for review on this or you can merge it. I am releasing my code to public domain, so you can use how ever you like.
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.
73, Daniel DC2ZP
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
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
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.
CHIRP already has this functionality built in, you just need to make those classes implement the matching mechanism:
http://chirp.danplanet.com/projects/chirp/repository/entry/chirp/drivers/ft2...
Right now it's just comparing file size, which is identical between all of them.
Is there already test code to mock the ID string for testing?
If you put an image for your radio in tests/images then run_tests.sh will validate that no two models are matched twice.
Thanks!
--Dan
El 14/04/16 a las 11:30, Dan Smith via chirp_devel escribió:
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.
CHIRP already has this functionality built in, you just need to make those classes implement the matching mechanism:
http://chirp.danplanet.com/projects/chirp/repository/entry/chirp/drivers/ft2...
Right now it's just comparing file size, which is identical between all of them.
I will suggest to read the tk760g driver in chirp, I have a trick for a single driver to support every radio model and variant in the market for that radio family (yet left the handheld UHF segment, I have not time nor radio to test it now)
A little explanation:
http://chirp.danplanet.com/projects/chirp/repository/entry/chirp/drivers/tk7... From this line and forward there is a comment and a definition for each radio model that has his own variants and this complexity is hidden from the user that choose just TK-760G from the list not knowing that that particular radio has a few variants with different options, ranges, etc.
I declare a dict var (radio.VARIANTS) that holds the partial id as passed by the radio as key (the last bytes are used as a flag for trunking board and password protected ones), and the data for that key is a tuple with channel count, freq ranges and commercial designation for that radio variant.
in http://chirp.danplanet.com/projects/chirp/repository/entry/chirp/drivers/tk7... I make a general match model procedure checking first for the size and then the model match that is handled here http://chirp.danplanet.com/projects/chirp/repository/entry/chirp/drivers/tk7...
I extract the ID segment from the img file (or just downloaded data from radio) and check for it's presence in the VARIANT dict for the current radio model.
All this from the file, in the download process I just check for a partial string inside the id string (the radio.TYPE var) and deal later for the specific model, just here after the download is complete in the self.process_mmap() that get executed for both cases (download and file opened) http://chirp.danplanet.com/projects/chirp/repository/entry/chirp/drivers/tk7...
Once there (_set_variant() ) I check for the specific model and complain if not, if success then set the freq ranges, amount of channels and banks if it has it. Late I build a string to identify (to show to the user) just like the OEM does for compatibility.
I hope this example helps you to understand and build a solution for this.
73 CO7WT.
participants (3)
-
Dan Smith -
Daniel Clerc | DC2ZP -
Pavel Milanes (CO7WT)