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