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

[Dan Smith]

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