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