CHIRP

Yeah your debug log confirms that the radio is responding but with an empty firmware version. That's definitely a problem, of course because chirp doesn't know how to handle the radio (since there are so many firmware variants for these radios).

Have you updated your firmware since it worked with CHIRP in October? If so, can you point me to exactly what you installed? Is there an updated version available for you now? In October, CHIRP was not validating the firmware string, which is both a problem and a potential explanation for why it worked then and doesn't now.

Thx for the reply. My first contact with uvk# is February 2024. I am working with stock radios purchased in February which are still running the factory firmware. Updating firmware was the original plan but everything is broken.

I only infer that earlier Chirp versions were working with uvk6 because, before November, there is at least one reported issue referencing a ukv6 preset details (frequency steps during edit and something else). Apparently Chirp connected to uvk6 before November.

#background
Python bombs just trying to read firmware version (in programming mode). It does get 12 bytes from the radio. First field is two byte length (little endian) and version should be last 8 bytes (i think)? Next there is an XOR operation on those bytes that supposed to render them into ascii? Anyway, .decode() of those bytes (after XOR) errors on first char and is how python fails to get a version string.
#end python background

I know Chirp is in operational mode. Chirp apparently send "Hello" and radio should respond with version?

I suspect that all tools worked with all uvk# releases until a recent and major factory firmware change.

The radio should not be in programming mode for chirp to talk to it. Just connect the cable, power on the radio, and do the download in chirp. Your debug log looks like the response coming back is similar to the one in programming mode, so I'd expect that's the problem. If so, please just power on the radio and try again. Include a debug log of that attempt if it still fails.

sorry to confuse but radios were not in programming mode for the Chirp debug log submitted. I probably shouldn't have even brought up the python programming issue at all but I had hope it would illustrate the fundamental deadness of uvk6

by the by, issue 11068 is probably same issue with similar conclusion for my uv-k5(99) except he failed to provide debug log. Issue 11171 duplicates my uv-k6 issue (i suspect uv-k5(8) (at least later examples) are uvk6 prototypes)

As instructed from Chirp: I turn on radio (no mention or use of PTT button), note that flashlight is not illuminated indicating radio is not in programming mode, connect cable to radio, say ok to software connection params, Error.

with radio not in programming mode, radio seems to respond to Chirp's Hello string with an echo of Hello string?

again I hazard to bring up programming mode but I think programming commands and responses must start with abcd and terminate with dcba? Thus, I suggest that the debug log provided could not have been generated with the radios in programming mode

I suspect the politics behind this is that the FCC caught a modded radio transmitting where it shouldn't and threatened to pull Quansheng uvk#'s FCC certification unless Quansheng messed with the modders.

I am seeing the same issue on a K6 UVK5(8) I just purchased from Amazon. The radio is in normal mode, and is responding on the serial port (I see a different error if the radio us off), but the radio appears to echo the hello packet:

[2024-07-16 21:42:40,610] chirp.drivers.uvk5 - DEBUG: Sending hello packet
[2024-07-16 21:42:40,611] chirp.drivers.uvk5 - DEBUG: Sending command (unobfuscated) len=0x0008:
000: 14 05 04 00 6a 39 57 64   ....j9Wd

[2024-07-16 21:42:40,618] chirp.drivers.uvk5 - DEBUG: Received reply (unobfuscated) len=0x0008:
000: 14 05 04 00 6a 39 57 64   ....j9Wd

[2024-07-16 21:42:40,618] chirp.drivers.uvk5 - INFO: Found firmware: 
[2024-07-16 21:42:40,618] chirp.wxui.clone - ERROR: Radio serial detection failed: Firmware '' not supported

It appears the radio is echoing anything transmitted. I tweaked the command's last byte (0x64->0x65) and the first byte (0x14->0x15), and my modified message was sent back:

[2024-07-16 22:08:50,620] chirp.drivers.uvk5 - DEBUG: [mitchsw] Sending hacked packet
[2024-07-16 22:08:50,620] chirp.drivers.uvk5 - DEBUG: Sending command (unobfuscated) len=0x0008:
000: 14 05 04 00 6a 39 57 65   ....j9We

[2024-07-16 22:08:50,627] chirp.drivers.uvk5 - DEBUG: Received reply (unobfuscated) len=0x0008:
000: 14 05 04 00 6a 39 57 65   ....j9We

[2024-07-16 22:09:34,212] chirp.drivers.uvk5 - DEBUG: [mitchsw] Sending hacked packet v2
[2024-07-16 22:09:34,212] chirp.drivers.uvk5 - DEBUG: Sending command (unobfuscated) len=0x0008:
000: 15 05 04 00 6a 39 57 64   ....j9Wd

[2024-07-16 22:09:34,219] chirp.drivers.uvk5 - DEBUG: Received reply (unobfuscated) len=0x0008:
000: 15 05 04 00 6a 39 57 64   ....j9Wd

Ooops, please disregard my report in note #6. It turns out I didn't have the cable pushed in hard enough, and I must have caused some rx/tx loopback short circuit? I don't know if the new K6 mechanical design is different, but I had to push in the cable really hard, like I was about to break it. It snapped into place, and everything is working now!

Please close.

Yes my problem was also incomplete insertion. As previous poster said, push so hard you think you're going to break it.

If you see any metal or the plastic connector is not absolutely at the bottom of its recess, push harder. I also saw a post where someone had to Dremel the flex part to allow complete insert ... be careful there.

It seems to only apply to first break-in. Once you ram it in once, connectors are much more compliant