[chirp_devel] [PATCH][BTECH] Fixed Bug with the upload for BTECH 2501+220, fixes #3015

[Dan Smith]

> diff -r ac18b334d894 -r 635de0a2e218 chirp/drivers/btech.py
> --- a/chirp/drivers/btech.py    Mon Mar 28 16:50:21 2016 -0400
> +++ b/chirp/drivers/btech.py    Tue Mar 29 16:26:07 2016 -0400
> @@ -182,7 +182,6 @@
>  MSTRING = "\x55\x20\x15\x09\x20\x45\x4d\x02"
>  
>  
> -
>  def _clean_buffer(radio):

Random whitespace change here :)

> -def _do_ident(radio, status):
> +def _do_ident(radio, status, upload=False):
>      """Put the radio in PROGRAM mode & identify it"""
>  
>      #  set the serial discipline
> @@ -384,6 +383,22 @@
>                        (radio.MODEL, util.hexprint(id2)))
>              raise errors.RadioError("The extra ID is wrong, aborting.")
>  
> +        # this radios have a trick only the upload, they must send a \x06
> +        # and read a one or two bytes depending on the radio,
> +        # always ending on an ACK
> +        if upload is True:
> +            # send a ACK
> +            _send(radio, ACK_CMD)
> +            # read answer depending on the radio type, KT-8900 just one.
> +            ack = _rawrecv(radio, 1)
> +
> +            # but 2501+220 send two with the ACK at the end, read it
> +            if "+220" in radio.MODEL:
> +                ack = _rawrecv(radio, 1)
> +
> +            if len(ack) != 1 or ack != ACK_CMD:

I don't think you need the len check here, right? What are you looking
for that isn't covered by "ack != ACK_CMD" ?

Unrelated to this patch in general:

Possibly partly my fault for being slow in applying these (this week has
been hectic, sorry), I think it's probably worth you rebasing and
re-sending all your patches. I think that because of the one patch to
raise instead of break, the rest of your patches are out of sync with
me. I tried to apply them in a couple different orders, but they all
generate conflicts now.

Can you pull and rebase and then send a new stack? I'll try to apply
quicker this time :)

Thanks!

--Dan