Quansheng UV-K5 w/ an active development scene

[VK3KYY]

https://whosmatt.github.io/uvmod/ it is a modding platform for this radio, fairly easy to use.

I was just trying it out and it worked (but wait, did it crash my Windows 10 22H2? hahaha), including the webserial used for flashing the K5(8) I used to test it with.

Someone already posted that link

I'm not interested in modding bytes in the offial firmware, its not going to add any functionality etc

Someone needs to start writing new firmware for it from scratch.

[VK3KYY]

I tried to confirm that the OpenRTX is working on a new firmware for this radio but I can't find any info, as I am not familiar with their discussion platforms, and I am not on Twitter (and now you need an account just to read posts there), or should I say, X.

SOrry I started this thread, kinda distracting I must admit.

I saw that they said that they would eventually support this radio, but they say that about every radio they get asked about.

I recommend you post and issue to

https://github.com/OpenRTX/OpenRTX/issues

and see if you can get a definitive answer, rather than a "yes... sometime in the future."

[N1LSJ]

Just an update that a clone/open firmware for the UV-K5 has been developed and mods are going forward based on that. I have this one loaded on mine and it's awesome!
https://github.com/egzumer/uv-k5-firmwa ... m/releases

[G4EML]

I agree, the latest fork of the firmware for the UV-K5 from 'egzumer' is now very good.
Someone has done a great job of de-compiling the original firmware (or did they actually manage to get hold of the source from somewhere?) and creating a development environment that allows editing and recompiling. It is still based on the original firmware but has progressed from just patching the binary to being able to edit and recompile the source. I have even submitted a couple of PRs to fix some minor bugs.

The AM aircraft reception has been drastically improved. It now works really well as an aircraft receiver. The secret was to implement a software driven AGC loop which constantly adjusts the RF gain to keep the received signal level within the fairly narrow AM demodulation window.
It appears they are using an undocumented feature of the RF chip which demodulates AM but it only works within about a 20dB signal level window. They have even managed to get it to receive SSB using another undocumented feature. It's not possible to transmit though.

Having said all that there is not much scope left for any more enhancements. The Flash memory is very close to 100% used. in fact some of the less used original features have had to be disabled to get it all to fit.

Colin G4EML

[VK3KYY]

Someone has done a great job of de-compiling the original firmware (or did they actually manage to get hold of the source from somewhere?) and

I'd speculate that this is not a decompilation, and more likely to be based on the original source code, possibly a deliberate leak.
I've seem decompiled code that has all the function names and variable names.

Looking at the git history on the files and they all have full names for all the variables and functions from the initial commit,
Decompilation never has this. because the binary never contains the function names.

So either the decompiled and spent ages working out every single variable and function name, before comitting to github, or they had the source code

And logically there is no point in wasting time working out the internal function names for things like the display data transfer functions, before publishing the source code, as this would significantly delay when you could release the code



I could be wrong, but this does not look like a decompilation to me.

[N1LSJ]

They have even managed to get it to receive SSB using another undocumented feature. It's not possible to transmit though.

Rumor is that it is actually receiving DSBSC not USBSC so doesn't care if it's USB or LSB but obviously will crap out on a CB channel with both. One firmware claims to be able to transmit DSBSC

[Ik0nwg]

if you use the Fabrizio IU0IJV firmware you can transmit and receive in SSB with an excellent quality ... and the reception in AM is also fantastic... if you want to try it too you can find everything you need here

https://www.universirius.com/preppers/q ... rmware-IJV

Ciao
Sal

[G4EML]

Rumor is that it is actually receiving DSBSC not USBSC so doesn't care if it's USB or LSB but obviously will crap out on a CB channel with both. One firmware claims to be able to transmit DSBSC

Yes it is DSB, it is just using the baseband zero IF signal and the LO leakage provides the BFO. There is no filtering to remove the opposite sideband so it will receive USB and LSB.

Colin G4EML

[MM7FEE]

Hello, I was in the group on telegram watching as dualtachyon/userperson/...whatever-handle-he-uses-now decompiled the v.27 firmware. It took him about a month of nearly full time work and he was assisted by a number of hams who helped him to understand various things like CTCSS etc. This was done in parallel with the effort to reverse engineer a schematic as well. DT literally went through every function and renamed them all. This was all done in a private repo before it was uploaded to github. Not much is known about DT other than he has spent most of his professional life reversing firmware and he is probably one of the best of the best. After the K5 firmware he performed the same on the Retevis RT890 which uses many of the same components. Coincidentally he tried to join in with OpenGD77 but was shunned as he does not have a ham ticket. He has since moved on from ham radio for now and is presumably terrorising some other electronics manufacturer who thinks their product is secure. Finally it should be added that his reversed code is entirely legal.

Someone has done a great job of de-compiling the original firmware (or did they actually manage to get hold of the source from somewhere?) and

I'd speculate that this is not a decompilation, and more likely to be based on the original source code, possibly a deliberate leak.
I've seem decompiled code that has all the function names and variable names.

Looking at the git history on the files and they all have full names for all the variables and functions from the initial commit,
Decompilation never has this. because the binary never contains the function names.

So either the decompiled and spent ages working out every single variable and function name, before comitting to github, or they had the source code

And logically there is no point in wasting time working out the internal function names for things like the display data transfer functions, before publishing the source code, as this would significantly delay when you could release the code



I could be wrong, but this does not look like a decompilation to me.

[VK3KYY]

"Shunned" is a very strong work.

We no longer allow registrations on the forum for non-Hams, becuase this is the only way we can manage the huge number of bot and troll registrations which we started to receive.

Its always been site policy for people to use their callsign as their username, but we ended up having to enforce this as a requirement

I don't remember any of the developers telling me they had been contacted directly by whoever "DT" is.

But OpenGD77 will never run on the UV-K5 becasue the CPU is far too small, and also it lacks the C6000 DMR chip.