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.