[chirp_devel] Kenwood TH-D74A MCP mode is proving to be a pain
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?
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
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,
Some more observations...
I was able to fix the exception problem by adding a close function to the proxy class.
I still had some problems going into program mode. It appears the baud rate can shift. I noticed the TH-D72 code has a baud detect function which is commented out in the TH-D74 sync_in function and missing in the TH-D74 sync_out function. I added the calls to the two functions and can go into programing mode more consistently.
I find it interesting that the download function between TH-D74 and TH-D72 classes are basically the same, but the upload functions are different. The TH-D74 upload function does not set the baudrate and RTS is set in a different place. This could cause communications problems. It also appears some of the actions in the TH-D74 upload function may be to correct problems caused by using a different sequence.
Empty memory locations are showing as error in the memory grid and the log show various errors.
73 Eric
participants (2)
-
Eric A. Cottrell -
Eric Wolak