[chirp_devel] [PATCH] [FT2900] add support for xmit modded FT2900E

[Daniel Clerc | DC2ZP]

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 logged
> > +            LOG.debug("Radio successfully identified!")
> >              break
> >  
> >      if 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
> > + at 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 at intrepid.danplanet.com
> http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
> Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
Url : http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20160414/05d5e628/attachment-0001.bin