[chirp_devel] [PATCH][BTECH] Simplified second ID proc, add QYT KT-8900, fixes #3015
In this patch: - Simplified the procedure for the second ID of some radios in preparation to add the QYT KT-8900 radio. - Added support for the QYT KT-8900. - Fixing the variable naming for the QYT KT-UV980.
Also related to issue #2673 (support for the QYT KT-8900)
This radio needs a extra step before an upload, and also the QYT KT-8900 that looks like a predecessor of the BTECH.
Also related to issue #2673 (support for the QYT KT-8900)
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 ACKif 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 itif "+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
El 31/03/16 a las 12:51, Dan Smith via chirp_devel escribió:
def _clean_buffer(radio):
Random whitespace change here:)
PEP8 says two white lines not three between defs not in a class, last check with pep8 complained about this, so I remove the 3rd line ;-)
73
PEP8 says two white lines not three between defs not in a class, last check with pep8 complained about this, so I remove the 3rd line ;-)
Yeah, not arguing with the change, just that it's mixed with other things. It's nice to keep functional and cleanup changes separate to help differentiate between things that should have no functional change and things that should.
Anyway, I'll not be that picky, I just can't not point it out :)
--Dan
El 31/03/16 a las 12:51, Dan Smith via chirp_devel escribió:
# 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" ?
Right, maybe I pass this out or it was related to the previous code and I missed to fix it, no problem, will do.
73
El 31/03/16 a las 12:51, Dan Smith via chirp_devel escribió:
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!
No problem, we all have our worries and bad days.
Will save & pull now to rebuild the patches in the night and will send it the morning.
73
participants (2)
-
Dan Smith -
M.Sc. Pavel Milanes Costa