Bug #11594
closed"Unable to determine firmware version" on Quansheng UV-K5(8)
0%
Description
Radio: Quansheng UV-K5(8) from AliExpress. As received from AE, no mods/updates done.
Machine: OSX 21.6.0 Monterey
Process:
Download CHIRP next 20241003
Connect USB to Mac
Start CHIRP
Power on Radio
Connect cable to radio
Radio Menu -> Download From Radio
Select USB Serial Port / Quansheng / UV-K5 (+ OSFW,unsupported,egzumer)
Click OK
Click OK on Experimental driver warning
Click OK to Download Instructions
Error window “Error communicating with radio. Unable to determine firmware version”
Click OK
Checked debug log to see if anything was being received (which it looks like it is)
Check with different USB cable (no change)
Unable to test with OEM software, as it’s all Windows not Mac.
Tested Baofeng BF-88E (BF-888) on same machine/same cable. All as expected.
Haven’t tested with other firmware(s) yet in case further diagnostics are needed.
Thanks.
Files
Updated by Mark Boyce 7 months ago
- File config.txt config.txt added
- File debug_log.txt debug_log.txt added
[Uploaded from CHIRP next-20241003]
Updated by Dan Smith 7 months ago
FWIW, radios coming from aliexpress are known to have non-standard firmware, so beware of that. However, the response coming from the radio looks more like you're in firmware programming mode than not (i.e. regular programming mode). It's not even the response you'd expect from the radio if it has some other firmware variant installed.
Not sure what to suggest really. Make sure you're dialed to a quiet frequency and that the radio is not transmitting when you're trying. You might try powering on the radio with the connector already connected. Note that if your cable is like mine, it erroneously triggers transmit on the radio until it has been read by software at least once. So I connect the cable to the computer and the powered-off radio, make chirp try and fail to read the radio. Then I power on the radio, which sits in receive as expected, and then I have chirp try again.
Updated by Mark Boyce 7 months ago
- File config.txt config.txt added
- File 2024-10-06 Quansheng_UV-K5_20241006 Factory Defaults.img 2024-10-06 Quansheng_UV-K5_20241006 Factory Defaults.img added
- File debug_log.txt debug_log.txt added
[Uploaded from CHIRP next-20241003]
Hi
Radio doesn't appear to be in programming mode as far as I can tell. Display shows frequencies, Menu allows me to go and hit Reset -> All
So after more fiddling … I think it may be a physical cable issue:
Just for notes - cable appears to echo sent packets when not connected
- Cable connected to Mac only
- CHIRP Loaded - try and fail. Interestingly with same error? Cable is Echo'ing packets directly back when not connected?
[2024-10-06 15:18:08,672] chirp.wxui.clone - DEBUG: Serial opened: Serial<id=0x118207fd0, open=True>(port='/dev/cu.usbserial-30', baudrate=38400, bytesize=8, parity='N', stopbits=1, timeout=0.25, xonxoff=False, rtscts=False, dsrdtr=False) (rts=True dtr=True) [2024-10-06 15:18:08,672] chirp.drivers.uvk5 - DEBUG: Sending hello packet [2024-10-06 15:18:08,672] chirp.drivers.uvk5 - DEBUG: Sending command (unobfuscated) len=0x0008: 000: 14 05 04 00 6a 39 57 64 ....j9Wd [2024-10-06 15:18:08,679] chirp.drivers.uvk5 - DEBUG: Received reply (unobfuscated) len=0x0008: 000: 14 05 04 00 6a 39 57 64 ....j9Wd
So, this only works with one of my two cables!
- Insert cable as hard as you can, then press harder, you think you’re going to break it, keep pressing
- Turn on radio
- Run CHIRP as normal !
My second cable still does not work.
Updated by Dan Smith 7 months ago
That "press harder than you think you need" step is true of most of the cheap chinese radios, so that tracks. Lots of people trim their connectors. Also, some cables echo because they have TX and RX tied physically together, although I didn't think these radios use that type of cable, although I'd have to look a the code closer to see.
But, sounds like you've figured it out and I can close this as not a bug?
Updated by Mark Boyce 7 months ago
Thanks Dan, I think this is definitely a hardware issue and can be closed as 'not a bug'. I was trying to include detail of the debug process for those that follow. From what you say there will be more people with the same issue.
One thought - Feature request maybe? Assuming I'm reading the debug logs right. Would it be safe to say that if sent command is the same as an unrecognised received reply the error could be "Local echo. No radio connected?". Which would have lead me straight to the problem rather than assuming I'd got a new/strange firmware version.
Cable disconnected (tested 2 cables, baofeng twin connector and generic multi-connector)
[2024-10-07 06:51:04,675] chirp.drivers.uvk5 - DEBUG: Sending hello packet
[2024-10-07 06:51:04,675] chirp.drivers.uvk5 - DEBUG: Sending command (unobfuscated) len=0x0008:
000: 14 05 04 00 6a 39 57 64 .... j9Wd
[2024-10-07 06:51:04,682] chirp.drivers.uvk5 - DEBUG: Received reply (unobfuscated) len=0x0008:
000: 14 05 04 00 6a 39 57 64 .... j9Wd
[2024-10-07 06:51:04,682] chirp.drivers.uvk5 - INFO: Found firmware:
[2024-10-07 06:51:04,682] chirp.wxui.clone - ERROR: Failed to clone: Unable to determine firmware version
Cable connected (both tested)
[2024-10-07 07:00:39,957] chirp.drivers.uvk5 - DEBUG: Sending hello packet
[2024-10-07 07:00:39,957] chirp.drivers.uvk5 - DEBUG: Sending command (unobfuscated) len=0x0008:
000: 14 05 04 00 6a 39 57 64 ....j9Wd
[2024-10-07 07:00:39,979] chirp.drivers.uvk5 - DEBUG: Received reply (unobfuscated) len=0x0028:
000: 15 05 24 00 32 2e 30 31 ..$.2.01
008: 2e 33 35 00 d4 e2 00 00 .35.....
016: 00 00 00 20 00 00 00 00 ........
024: be 0e 30 61 39 6a cb 4b ..0a9j.K
032: 61 b0 0f 61 a0 e6 54 48 a..a..TH
[2024-10-07 07:00:39,979] chirp.drivers.uvk5 - INFO: Found firmware: 2.01.35
Updated by Dan Smith 7 months ago
- Status changed from New to Not a bug
Yeah, it's a good idea, but the cable will echo whether the radio is connected or not, even if it's connected and it's off or doesn't respond to the interrogation request. It's hard to craft an error message that is meaningful when there are so many possibilities. Also, some drivers support echoing and non-echoing cabling (not sure if this one does, I'd have to look) which further complicates it.