Project

General

Profile

Actions
Copy link

Bug #10885

closed

Unable to connect to Kenwood TM-V7A

Added by Steve Williams over 1 year ago. Updated 10 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
10/07/2023
Due date:
% Done:

100%

Estimated time:
Chirp Version:
next
Model affected:
Kenwood TM-V7A
Platform:
Windows
Debug Log:
I read the instructions above:
Yes

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

Download all files
debug.log (20.7 KB) debug.log Steve Williams, 10/07/2023 01:47 AM
debug.log (19.2 KB) debug.log MAC OS CHIRP next-20240807 Benjamin Young, 08/07/2024 06:23 PM
chirp_win_legacy_tmv7_debug.log (107 KB) chirp_win_legacy_tmv7_debug.log Benjamin Young, 08/24/2024 03:35 PM
kenwoodtmv7_hack.patch (772 Bytes) kenwoodtmv7_hack.patch Benjamin Young, 08/26/2024 05:44 PM
kenwood_live.py (52.3 KB) kenwood_live.py Dan Smith, 08/26/2024 05:51 PM
kenwoodtmv7.patch (406 Bytes) kenwoodtmv7.patch Benjamin Young, 08/26/2024 06:36 PM
Actions
Copy link
 #1

Updated by Benjamin Young 11 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.

Actions
Copy link
 #2

Updated by Dan Smith 11 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.

Actions
Copy link
 #3

Updated by Benjamin Young 10 months 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?

Actions
Copy link
 #4

Updated by Benjamin Young 10 months ago

Here is the debug log for the successful connection and reading all all 200 memory registers from the windows legacy chirp version

Actions
Copy link
 #5

Updated by Dan Smith 10 months 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?

Actions
Copy link
 #6

Updated by Benjamin Young 10 months 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.

Actions
Copy link
 #7

Updated by Benjamin Young 10 months ago

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.

Actions
Copy link
 #8

Updated by Dan Smith 10 months ago

Try this with LoadingTestModules

Actions
Copy link
 #9

Updated by Benjamin Young 10 months ago

I tried your script but it did not work. I needed to set "HARDWARE_FLOW = False" in the TmV7 class and that worked!

Actions
Copy link
 #10

Updated by Dan Smith 10 months ago

Okay, to be clear, only HARDWARE_FLOW=False and not the WANTS_RTS line?

Actions
Copy link
 #11

Updated by Benjamin Young 10 months ago

Correct only the HARDWARE_FLOW = False was needed. I removed the WANT_RTS line.

Actions
Copy link
 #12

Updated by Dan Smith 10 months ago

Cool, I'll push, thanks!

Actions
Copy link
 #13

Updated by Dan Smith 10 months ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100
Actions
Copy link
 #14

Updated by Benjamin Young 10 months ago

Thanks Dan! Fix looks good.

I also hope any inherited radios from this class need this value set to False.

Actions
Copy link
 #15

Updated by Dan Smith 10 months 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.

Actions
Copy link
 #16

Updated by Benjamin Young 10 months ago

Sounds good

Actions
Copy link

Also available in: Atom PDF

Copyright 2023 CHIRP Software LLC