[chirp_devel] [PATCH] [btech] Delay writes statically, to avoid invalid header-response from KT-8900. Fixes #3993

[Michael Wagner]

# HG changeset patch
# User Michael Wagner <michael.wagner at 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.html
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: