Bug #10515


Unable to communicate with radio starting with version 20230411

Added by David Muoio about 1 year ago. Updated 12 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Chirp Version:
Model affected:
Kenwood TM-V71A
I read the instructions above:


I am using Chirp-Next and found that with the latest version of 20230411 I can no longer communicate with the radio. If I go back to older versions then communication works again.

I am running on a MacBook Air with M2 chip and MacOS Ventura 13.3.1.
The radio is a Kenwood TM-V71A
Using a USB-C to Serial adapter with current FTDI chipset

Repro of bug is pretty simple:

  1. Launch Chirp-Next
  2. From Radio Menu, select "Download from radio"
  3. I of course select the usb-serial adapter, Kenwood vendor and TM-V71 for Model. After pressing OK button the following appears after a delay.

"Error communicating with radio"
"No response from radio"

If I run an older version of Chirp-Next it works fine. This includes the immediately prior version of 20230409 .


chirp_debug-ydf160z1.txt (5.97 KB) chirp_debug-ydf160z1.txt DebugLog-20230414 build David Muoio, 04/14/2023 08:21 AM (62.8 KB) Dan Smith, 04/14/2023 03:07 PM
Actions #1

Updated by Dan Smith about 1 year ago

  • Status changed from New to In Progress
  • Assignee set to Dan Smith
  • Target version set to chirp-py3

Yeah, so the change in #10510 probably broke you. I'm guessing something in your cable requires DTR to be asserted, potentially to power a level converter (although I'd think not on a V71). Either way, the outcome of that bug was that despite us attempting to not assert RTS for most radios, a bug in python-serial meant that we were. That fix likely went too far by also de-asserting DTR by default, which for most 3-pin cables is "correct". However, a day after merging it, I realized that would probably break at least one Yaesu I know of that requires DTR for level-shift power. So, assuming this is your problem, "thanks" for the confirmation :)

Your testing of versions (thanks for that) lines up with that change and nothing else could really explain it, so I think it's pretty clear. I'll introduce a separate flag for DTR so that a driver can disable it if needed, but default it back to asserted, which is what has apparently been the case forever despite us not asking for it and the default being de-asserted in the python-serial API.

Look for another build likely tomorrow with that change, and please come back here to report if it fixes you.

Actions #2

Updated by Dan Smith about 1 year ago

  • Status changed from In Progress to Closed
  • % Done changed from 0 to 100
Actions #3

Updated by David Muoio about 1 year ago


I just downloaded and ran today's build (20230414) and have to report no joy. Still get the same error. I can attach the debug log if you think it might be useful. I couldn't see how (or I don't have permission) to reopen this ticket so hopefully you will see this.

Actions #4

Updated by Dan Smith about 1 year ago

  • Status changed from Closed to In Progress

Yeah, debug log please. Unless that change didn't actually do the thing it was supposed to, there's really nothing else that changed between the working and non-working builds that could be related. Let's see the debug log and go from there.

Actions #5

Updated by David Muoio almost 1 year ago

OK, have attached the log.

Actions #6

Updated by Dan Smith almost 1 year ago

Can you tell me about your cable downstream of the USB adapter? Is it just three wires (TX, RX, GND) to the radio, or more pins? Your log shows that DTR is asserted, so RTS is the only thing that isn't being asserted now, which shouldn't even make it to the radio if it's it's just a three-pin cable.

Actions #7

Updated by David Muoio almost 1 year ago

It's a cable made by Kenwood for connecting the radio to a PC. Part #PG-5G with 8-pin Mini DIN on the radio end. Looking at the user manual for the radio shows 5 pins: RTS, CTS, TX, RX and GND.

Actions #8

Updated by Dan Smith almost 1 year ago

Okay, I made my own cable for those radios years ago and don't remember it having the other pins, but I must be wrong. If so, all those related radios will need it I guess. Perhaps since RTS has been on all these years even though we didn't realize I should change the default back and exclude specific radios.

Either way, if you could try loading the attached module with LoadingTestModules and confirm it resolves your problem, that will at least make sure we're on the right track.

Actions #9

Updated by David Muoio almost 1 year ago

Yep that patch seems to work well. I can read and write memory locations to the radio. FYI: Your method for loading test modules is pretty slick.

Actions #10

Updated by Dan Smith almost 1 year ago

Okay, well, glad we at least know the deal now. I'll try to work on getting this resolved over the weekend. Thanks for your help.

Actions #11

Updated by Dan Smith 12 months ago

Okay, queued up for tomorrow. I'll leave this open until you confirm, thanks.

Actions #12

Updated by David Muoio 12 months ago

I just tested out today's build (20230416) and it seems to work fine with the Kenwood TM-V71A. I also tested it with two Kenwood handhelds. A TH-F6A and TH-D74. Worked with both of those as well. I think this ticket can now be closed.

Thanks for the support.

Actions #13

Updated by Dan Smith 12 months ago

  • Status changed from In Progress to Closed

Cool, thanks for confirming!


Also available in: Atom PDF