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?
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