On 12/7/2017 2:40 PM, Eric Wolak via chirp_devel wrote:
Hello fellow CHIRP contributors,

I'm working on CHIRP support for the Kenwood TH-D74A, and it's turning
out to be far more difficult than I expected. The memory layout is
straightforward enough, but the serial protocol seems to have some
quirks to it. I'm pretty sure my code is having the same exchange as
the Kenwood MCP software is with the radio, but when CHIRP uploads to
the radio it glitches at page 1280 and the radio factory resets. It
also sometimes glitches at the beginning of the upload, though I
haven't been able to isolate and reproduce that yet.

Does anybody have ideas for what I might be missing here, or what I
should investigate? I'm reduced at this point to writing a tool that
replays sessions recorded using Device Monitoring Studio (and the
replay works), and then diffing it against what CHIRP is doing. Is
there some more well-trodden path for doing this sort of protocol
comparison?



https://chirp.danplanet.com/issues/4129

Hello,

I tried out the code you posted and only occasionally did my TH-D74 go into clone mode. Most of the time it turned off. I used RealTerm to experiment and got the same result. I dropped the baud rate down to 57600 and it got into clone more often. 38400 seemed solid.

I edited the baud rate in your code to 38400. The radio went into clone mode and downloaded. At the end I got an exception.
C:\Projects\Radio\CHIRP>python chirpw
Exception in thread Thread-2:
Traceback (most recent call last):
  File "C:\Python27\lib\threading.py", line 801, in __bootstrap_inner
    self.run()
  File "C:\Projects\Radio\CHIRP\chirp\ui\clone.py", line 260, in run
    self.__radio.pipe.close()
AttributeError: 'SProxy' object has no attribute 'close'

I suspect the high baudrate is causing overruns and the radio powers off.

73 Eric