CHIRP

Do you know that this firmware is compatible with the OEM memory format?

I can't give any technical details, but when this firmware is programmed the previous memories are retained and work fine.
FYI This firmware is compatible with Quansheng UV-5R too.

This firmware is becoming very popular as there is a hardware MOD to wideband the radio. A memory management program like Chirp would be a great advantage.
http://www.hamskey.com/2024/03/introduction-to-uv-k5-hf-fullband.html#more

https://github.com/phdlee/uvk5cec/releases/tag/v_01HF
Source code for the firmware.

Young Kim wrote:

from newest firmware of CEC of UV-K5 quansheng, it is not recognized from newest CHIRP. I guess, his versioning rule is CEC_0.x[a-z] as of now.
Can you include this? his greatest update enable waterfall from handy ;)

His firmware versioning rule is somewhat strange. 0.2 for CW. 0.4 for HF.
Cec_0.2v > [a-z] is version and 0.x is model.
It has worked with prog or CPS.

Dan Smith wrote in #note-1:

Do you know that this firmware is compatible with the OEM memory format?

Richard Ebbs wrote in #note-4:

https://github.com/phdlee/uvk5cec/releases/tag/v_01HF
Source code for the firmware.

Issued firmware can be downloaded from ;
https://github.com/phdlee/uvk5cec/releases/download/v0.2v/cec_0.2VC.packed.bin

Hmm, that looks to me like #11212 now, so I'm not sure. The radio is not in programming mode right?

Dan Smith wrote in #note-9:

Hmm, that looks to me like #11212 now, so I'm not sure. The radio is not in programming mode right?

If I share steps what I have done for test.

1. open chirp and go help
2. select load module from issue and select issue number 11243
3. turn on UV-K5, just turn on and make a USB cable connection
4. From chirp, select Radio menu > Download from radio > verify port/vendor/model and ok
5. follow instruction . turn off/turn on again > verify cable connection > select ok

I suppose programming mode is turn on with PTT button. If yes, yes, it was not in programming mode.

The changes in that file don't impact the cloning at all, so I don't think it's related to the original report. However, can you confirm that my module does download the radio but fails to decode the contents (i.e. errors in the data/settings after download is complete) and not that you got the "header short read" message?

Be extra careful about using developer mode to load untrusted modules like that. Anyone could trick you into loading a module with malicious code inside which could destroy data or expose you to a threat!

Hello.

I think I found two issues in that python driver, preventing the latest 0.3C version to be flashed to radio with Unsupported device error.
There is an issue with k5_approve_firmware method in classes UVK5Radio(UVK5RadioBase)and class UVK5HFRadio(UVK5RadioBase).
'CEC_' allowed prefix is not correct. Driver reads from radio ' CEC_' prefix. With space character.

Can you please provide details about git repo, so I can create a pull request, or I can just paste fixed methods here...

Sure, I was just trying to distill the changes in the driver that was posted into a subclass. The hacked up driver that just modified the UV-K5 in place is obviously not something we can put into chirp, but a subclass like I have done here is the right way. I don't have a CEC-firmware K5 to try, but if you want to take what I did and fix it as a PR, you can submit it here:

https://github.com/kk7ds/chirp/

Please also add a test image to tests/images like the _egzumer one.

Thanks!

Sergey, your change makes the new subclass always match any firmware, so that one gets chosen for every other model as well (which causes it not to work for them anymore).

Can you grab an image and a debug log from after you download from the radio please so I can look? If you're using the current build, you might try using the

Help->Report or update a bug

function which will grab the open image, and debug log and send it here. Thanks!

Okay I'll have a look, but I really need a .img file before I can commit this to the tree for the automated tests. Can you grab and attach one please?

Dan Smith wrote in #note-19:

Okay I'll have a look, but I really need a .img file before I can commit this to the tree for the automated tests. Can you grab and attach one please?

Sorry, i'm not familiar with chirp dev procedures.
I just fixed the driver for my own usage (and to help others) :)
What is an .img file and where I supposed to get it?

Just download from your radio, File->Save, attach the file you get. Please also grab the debug log per How_To_Report_Issues. You should also be able to automate all this with Help->Report or update a bug.