Bug #10885
closedUnable to connect to Kenwood TM-V7A
100%
Description
I am using a Lenovo Laptop with Win10 22H2, Connected to a Kenwood TM-V7A with a Bluemax49ers PG-4S cable. When using the latest version 20231003 I am unable to connect to the radio, I get and error message "No Response from Radio". If I install the Legacy version I am able to communicate with the radio just fine. I then tried going back to the 20231003 version and again it did not communicate with the radio.
Files
Updated by Benjamin Young about 2 months ago
I am seeing the same issue on Windows 10 and Mac OS Sonoma 14.5, both using "CHIRP next-20240807". I am using an RT Systems USB-K4S cable.
However, on Chirp Legacy using Windows 10 I am able to connect to the radio.
Updated by Dan Smith about 2 months ago
- I read the instructions above set to Yes
I'll be honest, I haven't even laid eyes on a V7A in about 15 years. That said, I'm surprised it doesn't "just work" given how the kenwood_live driver works.
Can one of you capture a debug log from the legacy version showing it talking to the radio so I can see? The log from -next shows it totally not getting a response from the radio which is both odd and not very helpful/actionable.
Updated by Benjamin Young about 1 month ago
Woops sorry for the delay, I forgot to watch this issue. I was going to try and debug the issue locally this weekend. I will capture a trace from the windows legacy version and attach it.
Also do you have any tips for how to debug this using the python3 serial driver?
Updated by Benjamin Young about 1 month ago
Here is the debug log for the successful connection and reading all all 200 memory registers from the windows legacy chirp version
Updated by Dan Smith about 1 month ago
Your legacy log shows the radio responding to ID\r at 9600 baud, but when the new version tries to do that the radio doesn't respond. Perhaps a driver issue on the new machine? Same cable?
Updated by Benjamin Young about 1 month ago
Yes same cable. I was able to use the chrip legacy and chrip latest version on the same windows computer. Only the legacy version worked. I have tried the newer version on mac and linux and they did not work as well. Same issue of no connection.
Updated by Benjamin Young about 1 month ago
- File kenwoodtmv7_hack.patch kenwoodtmv7_hack.patch added
Ok found the potential bug. It is with the setting of "rtscts" on the serial module. It needs to be set to False in order to work.
I create a quick script to test this out, and then verified with the full application and it was able to read all of my memory settings correctly.
I will work on finding a better place to configure this for the kenwood module later this week. Let me know if you have any ideas. I will also try this on my mac in a bit.
Updated by Dan Smith about 1 month ago
- File kenwood_live.py kenwood_live.py added
Try this with LoadingTestModules
Updated by Benjamin Young about 1 month ago
I tried your script but it did not work. I needed to set "HARDWARE_FLOW = False" in the TmV7 class and that worked!
Updated by Dan Smith about 1 month ago
Okay, to be clear, only HARDWARE_FLOW=False and not the WANTS_RTS line?
Updated by Benjamin Young about 1 month ago
- File kenwoodtmv7.patch kenwoodtmv7.patch added
Correct only the HARDWARE_FLOW = False was needed. I removed the WANT_RTS line.
Updated by Dan Smith about 1 month ago
- Status changed from New to Closed
- % Done changed from 0 to 100
Applied in changeset github|0e5163b465000a3aee94bc252ddd1574048917f1.
Updated by Benjamin Young about 1 month ago
Thanks Dan! Fix looks good.
I also hope any inherited radios from this class need this value set to False.
Updated by Dan Smith about 1 month ago
Yeah, I suspect the G707 is identical since it's basically the same radio. The others are very obscure and I don't know of anyone who has used them in many years. If someone tries and fails as a result we can happily flip a subclass back.