# HG changeset patch # User Michael Wagner michael.wagner@gmx.at # Date 1474652598 -7200 # Fri Sep 23 19:43:18 2016 +0200 # Node ID 0e35f539fc38800907e088ab95d9d3a6c0071748 # Parent 1f9ff67ec2cdfe4ba55cb98fb741be712f3ebaf6 [btech] Delay writes statically, to avoid invalid header-response from KT-8900. Fixes #3993 Much simpler approch to ommit the "0x05"-Respone-Bug on KT-8900 (and other radios) mostly on linux. Instead of detecting platform or only delaying only on case of previous errors, the write is now always delayd. Result of following thread: http://intrepid.danplanet.com/pipermail/chirp_devel/2016-September/004264.ht... 73, OE4AMW

diff -r 1f9ff67ec2cd -r 0e35f539fc38 chirp/drivers/btech.py --- a/chirp/drivers/btech.py Tue Sep 20 19:34:00 2016 -0400 +++ b/chirp/drivers/btech.py Fri Sep 23 19:43:18 2016 +0200 @@ -21,6 +21,7 @@

LOG = logging.getLogger(__name__)

+from time import sleep from chirp import chirp_common, directory, memmap from chirp import bitwise, errors, util from chirp.settings import RadioSettingGroup, RadioSetting, \ @@ -396,6 +397,15 @@ try: for byte in data: radio.pipe.write(byte) + # Some OS (mainly Linux ones) are too fast on the serial and + # get the MCU inside the radio stuck in the early stages, this + # hits some models more than others. + # + # To cope with that we introduce a delay on the writes. + # Many option have been tested (delaying only after error occures, after short reads, only for linux, ...) + # Finally, a static delay was chosen as simplest of all solutions (Michael Wagner, OE4AMW) + # (for details, see issue 3993) + sleep(0.002)

# DEBUG if debug is True: