CHIRP

unit on order willing to loan and or pull files etc

If it helps, the original program software for the UV-K5 can be downloaded here.

https://txq-radio.com/DownLoad/105921.html

Eddi Wolf wrote in #note-2:

If it helps, the original program software for the UV-K5 can be downloaded here.

https://txq-radio.com/DownLoad/105921.html

The ANYSECU Download page also has the software.

http://www.szanysecu.com/h-col-106.html

The Quansheng Download Center has, what I would consider the "original", software and appears to be the most recent version.

http://en.qsfj.com/support/downloads/3002

Jim KC9HI

the software that works for it is terrible, cannot import .csv so if you have a collection of 50 plus frequencies you get to start all over again one by one.

Today, the firmware and programming software of UV-K5 have been upgraded again.

Firmware version :2.01.23
Programming Software version：1.0.38

http://qsfj.com/support/downloads/3002

Hongguang Yang wrote in #note-5:

Today, the firmware and programming software of UV-K5 have been upgraded again.

Firmware version :2.01.23
Programming Software version：1.0.38

http://qsfj.com/support/downloads/3002

Unless I am missing something, what I just downloaded is the same as it has been since 10-March-2023.

Jim KC9HI

After receiving my pair of UV-K5 radios, I did a quick serial port capture of one and from what I see the cloning protocol is nothing similar any other radio that CHIRP supports. Unless Quansheng is willing to share their cloning protocol details or other assistance, I won't be the one creating support for this radio. :(

Jim KC9HI

Jim Unroe wrote in #note-6:

Hongguang Yang wrote in #note-5:

Today, the firmware and programming software of UV-K5 have been upgraded again.

Firmware version :2.01.23
Programming Software version：1.0.38

http://qsfj.com/support/downloads/3002

Unless I am missing something, what I just downloaded is the same as it has been since 10-March-2023.

Check the download address link. Click on my link.View the bottom link address of the webpage.

Jim KC9HI

for those who want to experiment:

"Portable radio CPS" software use serial line baudrate 38400 to talk to radio, you can use

socat -x tcp4-connect:127.0.0.1:2445 /dev/ttyUSB0,rawer,echo=0,b38400

to redirect usbserial cable to windows virtual machine with virtual serial port bind to 127.0.0.1:2445 (qemu: -chardev socket,id=charserial1,host=127.0.0.1,port=2445,server=on,wait=off)

I contacted Quansheng via facebook and they have said they'd sent some documentation to the chirp vendor email.
"Quansheng Electronics Co., Ltd.
Ive contacted CHIRP engineer and sent the samples and document to him, but I need to wait for his time and work. I hope everything will go smoothly, but Im not sure. Thank you for your info, thank you."

I hope there will be sufficient information for the team to code something for this radio. I guess that will be down to the quality of the information provided.

I'm interested in chirp implementing this radio, I'm not familiar with reverse engineering of serial interface so I'm afraid I cannot be helpful

Someone on GitHub is working on reverse engineering the protocols and firmware:
https://github.com/amnemonic/Quansheng_UV-K5_Firmware
https://github.com/amnemonic/Quansheng_UV-K5_Firmware/blob/main/communication.md
https://github.com/amnemonic/Quansheng_UV-K5_Firmware/blob/main/cfg_mem_map.md

Hope this helps.

• Jon

Hi, i just got this radio a few days ago and managed to reverse engineer the protocol.

The programming protocol is indeed different from the usual Baofeng radio, because it is "protected" by crc-16, and further obfuscated by xoring with a static sequence. Fortunately the traffic from a new radio has a lot of 0xff and 0x00 byte sequences, so the xor sequence can be easily observed.

I've written software to read and write the eeprom:
https://github.com/sq5bpf/k5prog

This is enough to begin reverse engineering the eeprom contents. At first glance this is nothing out of the ordinary, for example 446.05625MHz is just 0x2A8A0B9 (44605625 in hex) with the bytes reversed.

I will do the reverse engineering of the eeprom in free time, and once that is done will try to implement support for this radio in chirp.

VY 73

Jacek / SQ5BPF

I've written software that emulates the UV-K5. So it's possible to run the Quansheng programming software in a windows VM under virt-manager, and have this emulator look like a real radio connected to the serial port.
The simulated eeprom contents are in a file. So it is possible to change something in the original software, and do a binary diff to see what has changed.

The emulator is here:
https://github.com/sq5bpf/k5emulator
(beware: this is a nasty hack, with almost no documentation etc).

The main aim is to reverse engineer the eeprom contents, however it can be also used to debug other radio programming software. I've used it for debugging k5prog, and in the future it might be used to debug chirp.

VY 73

Jacek / SQ5BPF

I've also documented my reverse engineering efforts here:

https://github.com/sq5bpf/uvk5-reverse-engineering

This includes a spreadsheet with most of the UV-K5 memory map reverse engineered, traffic dumps etc.

This should be enough to write a working driver without any vendor documentation (i will try to do it myself, but probably someone will beat me to it :)

VY 73

Jacek / SQ5BPF

I've written an experimental UV-K5 driver for chirp. For now it is in my UV-K5 reverse engineering repository:
https://github.com/sq5bpf/uvk5-reverse-engineering , the filename is uvk5.py

To use it:

• Install chirp-next, minimum version 20230515

• Find the chirp driver directory. It's best to search for some existing
  driver like uv5r.py. The path will differ, for example on my system it's in:
  ~/.local/pipx/venvs/chirp/lib/python3.11/site-packages/chirp/drivers

• Copy the uvk5.py file from my repository into this directory

• Download a copy of the radio memory with k5prog or chirp and keep it safe. You can restore the radio settings with it later.

Several features are unimplemented: FM radio, DTMF stuff, scan lists.

Please note that this is very experimental software, which might as well cause your radio to malfunction, brick it or worse. Use at your own risk.

VY 73

Jacek / SQ5BPF

The above instructions only worked for linux. Here are the instructions that will work on all OS-es:

• Install chirp-next, minimum version 20230515

• Enable Developer mode (Help -> Developer mode), restart chirp

• Download uvk5.py from the repository

• Load this file into chirp (File -> Load module , select the uvk5.py file)

• Download a copy of the radio memory with k5prog or chirp and keep it safe. You can restore the radio settings with it later.

VY 73

Jacek / SQ5BPF

Jacek Lipkowski wrote in #note-18:

The above instructions only worked for linux. Here are the instructions that will work on all OS-es:

• Install chirp-next, minimum version 20230515

• Enable Developer mode (Help -> Developer mode), restart chirp

• Download uvk5.py from the repository

• Load this file into chirp (File -> Load module , select the uvk5.py file)

• Download a copy of the radio memory with k5prog or chirp and keep it safe. You can restore the radio settings with it later.

VY 73

Jacek / SQ5BPF

If you would attach your test driver modules to this issue, then users of CHIRP-next could simply choose Help -> Load module from issue and key in 10478 to view a list of driver modules that are attached to this issue. Choosing the desired driver module from the list automatically downloads the driver and temporarily adds it to CHIRP-next for the current session. It works exactly the same no matter if the user is running Windows, Linux or macOS.

Jim KC9HI

It presents a list and shows them which one is latest, but lets them pick whichever they want. The debug log will include details about which one they pick.

And yes, please use this new workflow instead of encouraging regular users to enable developer mode. It's much better and safer for the average user to not turn on developer mode, load files from random places, and have a bunch of other things enabled with less error checking for sanity.

Thanks!

I switched from Windows 10 Pro 64-bit to Linux Mint and completed a download from both radios successfully.

Jim KC9HI

Able to download and upload with the uv-k5. Issue when copy/pasting or exporting csv with "could not convert string to float: 'high'"

Successfully made changes on radio. Thank you!!

Jim Unroe wrote in #note-23:

I switched from Windows 10 Pro 64-bit to Linux Mint and completed a download from both radios successfully.

Jim KC9HI

Thanks for testing. Unfortunately i don't have a windows box to test it on right now, but one person said that it worked for them on windows. Will look into it once i get windows installed somwhere. In the meantime, could you put a print("len",len(o)) before the failing line (line 245) and see what it prints on windows?

I will fix the out of range error, this one should be handled gracefully.

Mark: I will look into the csv export issues.

VY 73

Jacek / SQ5BPF

Jacek Lipkowski wrote in #note-25:

Jim Unroe wrote in #note-23:

I switched from Windows 10 Pro 64-bit to Linux Mint and completed a download from both radios successfully.

Jim KC9HI

Thanks for testing. Unfortunately i don't have a windows box to test it on right now, but one person said that it worked for them on windows. Will look into it once i get windows installed somwhere. In the meantime, could you put a print("len",len(o)) before the failing line (line 245) and see what it prints on windows?

I will fix the out of range error, this one should be handled gracefully.

Mark: I will look into the csv export issues.

VY 73

Jacek / SQ5BPF

How can we help? I can’t mail you a computer but maybe remote access? Testing on a VM without hardware access to a radio would be tough, but if you have another VM to run the radio that would work. What about using a free windows pre-installation environment (winPE) booting from SD card or USB stick to test with?

Jacek Lipkowski wrote in #note-25:

Thanks for testing. Unfortunately i don't have a windows box to test it on right now, but one person said that it worked for them on windows. Will look into it once i get windows installed somwhere. In the meantime, could you put a print("len",len(o)) before the failing line (line 245) and see what it prints on windows?

Adding this...

print("len",len(o))

Results in this...

NameError: name 'o' is not defined

Changing it to this...

print("len",len(header))

Results in this...

[2023-05-22 20:02:47,919] chirp.wxui.clone - DEBUG: Serial opened: Serial<id=0x1b23b7f3400, open=True>(port='COM5', baudrate=38400, bytesize=8, parity='N', stopbits=1, timeout=0.25, xonxoff=False, rtscts=False, dsrdtr=False) (rts=True dtr=True)
len 4
len 4
len 0
[2023-05-22 20:02:48,549] chirp.wxui.clone - ERROR: Failed to clone: index out of range

Jim KC9HI

After I commented out the lines 228 and 239 so that the CHIRP default timeout is used (I believe the default is 0.25)...

    # serial.timeout=0.5

...I am able to successfully download from my UV-K5 radio when using my Windows 10 computer.

It may not be the length of time that is important. I believe that changing the timeout value while communications is in progress can cause undesirable side affects with some drivers. So moving the timeouts to another place in the driver might also be a solution.

Jim KC9HI

We should always be reading constant lengths of data, so the timeout is really just to notice when something isn't responding. It should always be long enough to read whatever the radio is sending and in the correct amount. So unless something is very poorly written, the timeout should always be okay to be longer than it needs to be.

Also at 250ms-500ms time scales, it really shouldn't be OS-dependent and the difference is likely just the individual radio, the batching of chunks from the cable or whatever. Almost any time the timeout has to vary for different environments, it means the code is wrong.

Changing the timeout in the middle shouldn't be a problem, for what it's worth, but unless there's a (really) good reason, we shouldn't need to anyway.

Dan Smith wrote in #note-29:

Changing the timeout in the middle shouldn't be a problem, for what it's worth, but unless there's a (really) good reason, we shouldn't need to anyway.

I agree, it shouldn't. But if I leave the timeouts where they are and set to their current value of 0.5, the download always fails. Sometimes immediately, mostly after 1 or 2 blocks have been read, but one or two times it has made it to somewhere around 60%). If I leave the timeouts where they are and change them to the default value to 0.25, the download always fails. If I comment out the current timeouts and add one to _sayhello() before any serial activity begins (I added it to the line prior to "tries=5") with the timeout set to 0.5 (or I also tried 0.25), the download is successful every time.

Jim KC9HI

I agree, it shouldn't. But if I leave the timeouts where they are and set to their current value of 0.5, the download always fails. Sometimes immediately, mostly after 1 or 2 blocks have been read, but one or two times it has made it to somewhere around 60%). If I leave the timeouts where they are and change them to the default value to 0.25, the download always fails. If I comment out the current timeouts and add one to _sayhello() before any serial activity begins (I added it to the line prior to "tries=5") with the timeout set to 0.5 (or I also tried 0.25), the download is successful every time.

Okay, perhaps setting the timeout on windows dumps the incoming buffer or something. It definitely doesn't on linux and I've not noticed any problem doing it on windows before, but perhaps there are (serial) driver differences. However, setting the timeout in the send_command and receive_reply functions is definitely not where it should be anyway. Set it once at the start of sync_in and sync_out (or do_upload and do_download.

Really looking forward to getting this module working.
I tried on both a Windows 10 and Macbook M1 Pro (Ventura). Both getting the "index out of range".

Environment is:
CHIRP next-20230515 on Python 3.11.2 wxPython 4.2.0 gtk3 (phoenix) wxWidgets 3.2.2
Ubuntu 23.04
"load module from issue 10478"

• Download works, upload works (somehow)
• copy&paste from "EU LPD & PMR Channels" leads to error "some memories are incompatible" --> "#7: invalid literal for int() with base 10: 'High'"
• copying a repeater channel from UV-5R seems to work (freq and offset settings are displayed correctly in chirp), but the UV-K5 transmits on the wrong frequency (offset problem?)

Thank you very much for your work!
Regards,
Patrick

Jim Unroe wrote in #note-28:

It may not be the length of time that is important. I believe that changing the timeout value while communications is in progress can cause undesirable side affects with some drivers. So moving the timeouts to another place in the driver might also be a solution.

I see this switching to a short timeout and reading is used as a hack to flush buffers (in vgc.py and others).

Usually when i do serial programming, i don't like to set a single timeout for all communication, because devices will respond differently depending on the command they get. This was the reason to have it set in many places (for example the reply to a hello packet should be fast, while a memory write might be slow).

Please try this version on windows:
https://raw.githubusercontent.com/sq5bpf/chirp/master/chirp/drivers/uvk5.py
Note: only tried it on k5emulator, not on a real radio, so not sure if it works under linux (but should).

Maybe i will add some configurable timeouts to k5emulator, so that i can test the effects of the radio not responding instantly, and also see how the original UV-K5 software behaves when the emulated radio responds slower.

VY 73

Jacek / SQ5BPF

Jacek Lipkowski wrote in #note-34:

Please try this version on windows:
https://raw.githubusercontent.com/sq5bpf/chirp/master/chirp/drivers/uvk5.py
Note: only tried it on k5emulator, not on a real radio, so not sure if it works under linux (but should).

This is working 100% for me on Windows 10 Pro 64-bit with FTDI chip based programming cable.

Jim KC9HI

Hi!

Tested the new module:

• copy&paste looks better, no more errors (but see below)
• pasted simplex channels seem to work
• power level seems to work (now I can select low, mid and high, first module had only two options)
• pasted repeater channels still dont work. offset is displayed correctly in chirp but trx is on the wrong frequency
• only the first 16 channels seem to be uploaded. AFAIK the stock configuration had 16 memories programmed, maybe something is missing on the pasted channels?

Thank you very much and vy 73
Patrick

I did some more testing:

• downloaded from UV-K5 (where I see only 16 memories) to Chirp (where I see all uploaded memories) and exported to CSV (where I see all memories and find no difference between 1-16 and the rest).
• uploaded 16 simplex channels (copied from UV-5R). All are displayed in UV-K5 and look OK, some work, at least one doesnt (Memory 003).

Do you need any logs or dumps?

A lot of the "can't copy and paste channel from X" things will be fixed when the driver passes the tests it's currently failing. It's why the tests exist.

Also, if you're testing a module, please capture and attach a debug log (instructions How_To_Report_Issues) from your attempt as well as the image of the radio you're using for that test. Just saying "I can't copy and paste a channel" doesn't provide any actionable information to go on.

Thank you very much, Jacek!

I did a quick test of the latest module:

• The problem that I did only see the first 16 channels after upload is solved!
• The hint to check the extra properties helped: I had BCLO and "frequency reverse" switched on for many channels which caused most of my problems.

Hint for others testing: At my first attempt to load the module I received "Exception: Invalid or unsupported module file".
There was a "internal server error" from the webserver. Simply download again, on my second attempt it worked.

I will continue to test in the next days.

Regards,
Patrick

Hi!

I once again checked the "repeater channel"-Problem:
OFFSET and DUPLEX settings are displayed correctly in Chirp. After uploading the memories the "-" sign for the negative offset is missing in the TRX, the channel is configured as simples. If I change the duplex setting to "-" in the TRX the repeater channel works.
After downloading the "non working, - missing"-channels back to Chirp the DUPLEX settings again displayed as "-" in Chirp. Unsetting and re-setting DUPLEX to - in Chirp and re-uploading does not change the behavior.
The offset value (7.6000) is displayed and uploaded correctly. The problem is just with the duplex setting ("-").

Regards,
Patrick

Update to the DUPLEX setting problem:

I set the "-" duplex setting in the trx and saved the memory channel:

• downloaded to chirp: Channel name is empty (expected after saving in TRX?), offset and duplex look ok.
• re-upload the downloaded image: duplex setting "-" is still active.
• changed duplex to none in Chirp, upload --> duplex is off (expected)
• changed duplex to "-" in Chirp, enter offset 7.6000, upload --> duplex is still "off" --> not expected

So "duplex off" in Chirp overwrites duplex setting in TRX, but duplex "-" (or "+") in Chirp is not transferred to TRX. Wrong bit mask for FLAGS1_OFFSET_MASK?

Regards,
Patrick

Patrick K. wrote in #note-43:

So "duplex off" in Chirp overwrites duplex setting in TRX, but duplex "-" (or "+") in Chirp is not transferred to TRX. Wrong bit mask for FLAGS1_OFFSET_MASK?

Which firmware do you have? (read from radio and then settings -> radio information -> firmware version)

Not sure why the duplex setting does not work. Patrick, could you send me the image file downloaded from the radio using chirp or k5prog? (you will find the email in the driver sources)

BTW don't expect new versions over this weekend.

VY 73

Jacek / SQ5BPF

Jacek Lipkowski wrote in #note-44:

Patrick K. wrote in #note-43:

So "duplex off" in Chirp overwrites duplex setting in TRX, but duplex "-" (or "+") in Chirp is not transferred to TRX. Wrong bit mask for FLAGS1_OFFSET_MASK?

Which firmware do you have? (read from radio and then settings -> radio information -> firmware version)

Not sure why the duplex setting does not work. Patrick, could you send me the image file downloaded from the radio using chirp or k5prog? (you will find the email in the driver sources)

BTW don't expect new versions over this weekend.

VY 73

Jacek / SQ5BPF

When I tried the latest test driver module this morning, my radio was still in its factory state. I downloaded from the radio to create a tab compatible with the UV-K5.

Noticing that channel 16 was selected in the top display line of the radio, I edited channel 16 to be a UHF repeater channel (444.900 +5.000). I uploaded the change to the radio and the top line properly displayed the repeater programmed in channel 16.

Noticing that channel 1 was selected in the bottom display line of the radio. I edited channel 1 to be a VHF repeater channel (146.640 -0.600). I uploaded the change to the radio and the bottom line properly displayed the repeater displayed in channel 1 but the shift direction for the repeater in the top display line had changed to from '+' to '-'.

I temporarily set both channels back to simplex (Duplex = {blank}) in the radio and then programed them back as I did previously and the issue of the shift direction changing did not repeat. I then uploaded my "factory" back into the UV-K5 and repeated the process. This time the programming remained correct.

The firmware version is remains as received from Quansheng: k5_2.01.19

I will keep an eye on this and report back if I see this again, but as of right now I believe this was an issue with the radio.

Jim KC9HI

I tried to run on Manjaro Linux. After clicking Download from Radio, I got

WARNING: Last vendor/model not found
ERROR: Failed to clone: index out of range
Traceback (most recent call last):
File "/usr/lib/python3.10/site-packages/chirp/wxui/clone.py", line 66, in run
self._fn()
File "/home/v/Download/uvk5.py", line 554, in sync_in
self._mmap = do_download(self)
File "/home/v/Download/uvk5.py", line 410, in do_download
f = _sayhello(serport)
File "/home/v/Download/uvk5.py", line 338, in _sayhello
o = _receive_reply(serport)
File "/home/v/Download/uvk5.py", line 287, in _receive_reply
if header[0] != 0xAB or header[1] != 0xCD or header[3] != 0x00:
IndexError: index out of range


Adam Vigeron wrote in #note-48:

I tried to run on Manjaro Linux. After clicking Download from Radio, I got

WARNING: Last vendor/model not found
ERROR: Failed to clone: index out of range
Traceback (most recent call last):
File "/usr/lib/python3.10/site-packages/chirp/wxui/clone.py", line 66, in run
self._fn()
File "/home/v/Download/uvk5.py", line 554, in sync_in
self._mmap = do_download(self)
File "/home/v/Download/uvk5.py", line 410, in do_download
f = _sayhello(serport)
File "/home/v/Download/uvk5.py", line 338, in _sayhello
o = _receive_reply(serport)
File "/home/v/Download/uvk5.py", line 287, in _receive_reply
if header[0] != 0xAB or header[1] != 0xCD or header[3] != 0x00:
IndexError: index out of range


Are you running the latest test driver module? This looks like the same issue that I pointed out in note-22. It was addressed in the test driver module added in note-36 (and later).

Jim KC9HI

I know, I've used all the versions available here, no effect.

header = serport.read(4) return empty string
The radio doesn't seem to transmit any data

Message: 'Header short read: [%s] len=%i'
Arguments: (('', 0),)
ERROR: Failed to clone: Header short read
Traceback (most recent call last):
  File "/usr/lib/python3.10/site-packages/chirp/wxui/clone.py", line 66, in run
    self._fn()
  File "/home/vigeron/Pobrane/uvk5.py", line 566, in sync_in
    self._mmap = do_download(self)
  File "/home/vigeron/Pobrane/uvk5.py", line 416, in do_download
    f = _sayhello(serport)
  File "/home/vigeron/Pobrane/uvk5.py", line 344, in _sayhello
    o = _receive_reply(serport)
  File "/home/vigeron/Pobrane/uvk5.py", line 282, in _receive_reply
    raise errors.RadioError("Header short read")
chirp.errors.RadioError: Header short read

Adam Vigeron wrote in #note-50:

I know, I've used all the versions available here, no effect.

header = serport.read(4) return empty string
The radio doesn't seem to transmit any data

Maybe the programming cable does not work under linux?
Usually these problems are under windows, and they magically disappear under linux, but I know of one case where it's the other way around.

Could you try k5prog to read your radio?
Get the code from:
https://github.com/sq5bpf/k5prog
run:
./k5prog -r -v -f uvk5_backup1.img
And see if it works

Jacek Lipkowski wrote in #note-53:

And yet another version.

This fixes the tuning step for VFO channels.

BTW i have a temporary fork of chirp here:
https://github.com/sq5bpf/chirp
You will always find the newest driver there and a description of changes in the commit log.

VY 73

Jacek / SQ5BPF

Works perfectly for me: I programmed 200 channels in my radio by copy&paste from another radio. THANKS!!!!
Lorenzo

Wito Krasnal wrote in #note-56:

apparently no Duplex "split" mode in Quansheng? eq. the famous case of crossband link to ISS (437.000 / 145.990) cannot be simply copied and pasted from (for example) Baofeng UV-5R image (split option present) to experimental Quansheng image (no split option). I have included the error message. But the other way around (from quansheng to baofeng) works perfectly fine, and the (minus) 291.810 offset acceptable by Quansheng radio, is converted by CHIRP to Baofeng's "split" duplex.

This is a work in progress. Would you rather the developer hold back on releasing anything until the driver is totally finished? Or would you rather have the driver updated and released incrementally so it can be tested as development progress (like it is currently being done)?

Jim KC9HI

Jim Unroe wrote in #note-57:

Wito Krasnal wrote in #note-56:

apparently no Duplex "split" mode in Quansheng? eq. the famous case of crossband link to ISS (437.000 / 145.990) cannot be simply copied and pasted from (for example) Baofeng UV-5R image (split option present) to experimental Quansheng image (no split option). I have included the error message. But the other way around (from quansheng to baofeng) works perfectly fine, and the (minus) 291.810 offset acceptable by Quansheng radio, is converted by CHIRP to Baofeng's "split" duplex.

This is a work in progress. Would you rather the developer hold back on releasing anything until the driver is totally finished? Or would you rather have the driver updated and released incrementally so it can be tested as development progress (like it is currently being done)?

Jim KC9HI

Try upgrading the latest software image¶

• http://en.qsfj.com/products/3002

Try upgrading the latest software image¶

• http://en.qsfj.com/products/3002

Are you suggesting a firmware update? Unless that changes the format or interpretation of the memory contents, that shouldn't matter. However, the lack of a split function being described is purely a chirp driver limitation at this point. Please be careful about what you suggest to users here.

lorenzo maccone wrote in #note-55:

Works perfectly for me: I programmed 200 channels in my radio by copy&paste from another radio. THANKS!!!!
Lorenzo

Thanks for this Lorenzo!
Positive reports are needed too to keep the developer developing the driver.

VY 73

Jacek / SQ5BPF

Wito Krasnal wrote in #note-56:

apparently no Duplex "split" mode in Quansheng? eq. the famous case of crossband link to ISS (437.000 / 145.990) cannot be simply copied and pasted from (for example) Baofeng UV-5R image (split option present) to experimental Quansheng image (no split option). I have included the error message. But the other way around (from quansheng to baofeng) works perfectly fine, and the (minus) 291.810 offset acceptable by Quansheng radio, is converted by CHIRP to Baofeng's "split" duplex.

Wito, thanks for the report. The driver is a work in progress.

Please program this functionality into your radio with the original Quansheng software, verify that it works, read the radio with Chirp and provide the image file. Also provide the Baofeng reference image.

VY 73

Jacek / SQ5BPF

if I might add one little thing to my pathetic contribution: one small function is half-present in Jacek's driver, which is ABR (LCD backlight timeout). It is correctly read from and rewritten to the radio. I mean if the setting was set/changed in the radio, it is read and again rewritten as is, but if the radio setting was later changed and differs from the value within the image, the value in the radio is overwritten by the value from the image. Such behavior is correct and expected. But the setting itself is by now not present in the Settings tab, and thus unavailable from CHIRP. Thanks Jacek for the great work.

again to clarify because the post before published itself unexpectedly incorrectly formatted:

1. both radios were previously prgrammed to some 30+ channels; baofeng using chirp, quansheng using CPS
2. I have reset them both from their menus (reset: all) for the sake of this issue, so my custom channels should have been deleted.
3. now I have only programmed one channel on both of them, on CH-001, the ISS crossband link, but programmed them without using PC software nor CH340 cable, just from keyboard menus.
4. now I have read radio settings into chirp image.
5. Baofeng's CHIRP image is correct, only one channel present on CH-001, the rest empty, radio settings to default values
6. Quansheng CPS image mostly correct, only one channel present, the rest empty because deleted by the reset, majority of settings to default (except welcome message which remained custom)
7. Quansheng's CHIRP image: all channels, whose allegedly should be deleted by the reset, in reality still present in correct places (CHIRP cells), readable and editable through all their settings and values, except only custom channel names, whose were emptied but are now blank but editable; Settings tab initially shows error message, then appears blank. Browser and Info tabs available. Radio browser builds correctly. The channel CH-001 which was programmed from radio menu after reset, is correct in the image; previous values from before the reset were overwritten by new values from programming. In other words: current CHIRP driver works somehow like data recovery software. Inbuilt radio reset apparently does not empty the channels but only somehow flags them as empty, sth like "quick format". BUT: if a channel is deleted in CHIRP, and such modified image is uploaded to radio, and then redownloaded to CHIRP, deleted channel does NOT reappear. So CHIRP (Jacek's driver) correctly clears the memory cell, but the radio's inbuilt reset does not, or rather CHIRP still sees and can read channels "deleted" by inbuilt reset, in spite of that neither CPS software, nor the radio itself does not see them.

1. Both CPS and CHIRP are able to clear channels (delete their values) and not only clear channel index list. The initial issue about not being able to copy-paste a channel from baofeng image to quansheng image in case where the offset is "crossband" (treated as split in baofeng but as "normal" offset in quansheng) - this issue still remains, and I think might be an issue of the radio itself, not the driver.

No, I suspect it is a problem with the chirp driver. Lots of radios use "used flags" in other parts of memory. Software will often set this flag and clear the memory, but the radio often will only reset the flag to save time. The chirp driver is detecting used/empty from the contents of the memory channel itself, but it's likely that it needs to use a flag array instead. This also may manifest by the radio being unhappy about a memory that the current driver deletes, effectively setting the memory contents to something invalid, but leaving the flag set to "used". Try deleting a memory in chirp that was created with the OEM software or the radio itself and then dial to that memory on the radio.

Dan Smith wrote in #note-68:

Try deleting a memory in chirp that was created with the OEM software or the radio itself and then dial to that memory on the radio.
Tested a moment ago and:
Radio no longer dials to a channel deleted by CHIRP.
Repeat:
Radio does not dial to a channel which previously existed and was deleted using CHIRP.

Jacek Lipkowski wrote in #note-51:

Adam Vigeron wrote in #note-50:

I know, I've used all the versions available here, no effect.

header = serport.read(4) return empty string
The radio doesn't seem to transmit any data

Maybe the programming cable does not work under linux?
Usually these problems are under windows, and they magically disappear under linux, but I know of one case where it's the other way around.

./k5prog -r -v -f uvk5_backup1.img -p /dev/ttyUSB1
Quansheng UV-K5 EEPROM programmer v0.2 (c) 2023 Jacek Lipkowski sq5bpf@lipkowski.org

k5_prepare: try 0
****** Connected to firmware version: [app_2.01.17]
Sucessfuly read eeprom

This file helped me detect the problem. I had blocked ports, even changing to a different usb port did not result.
Working properly now. Thanks. Good Job.

./k5prog -r -v -f uvk5_backup1.img
Quansheng UV-K5 EEPROM programmer v0.2 (c) 2023 Jacek Lipkowski sq5bpf@lipkowski.org

k5_prepare: try 0
****** Connected to firmware version: [app_2.01.17]
Sucessfuly read eeprom

Is it ready to be added to the chirp production version to enable support?

Wito Krasnal wrote in #note-78:

The Busy Channel Lock setting per channel in Memory Properties - Other Tab does not work.

It works for me. I'm using chirp-next 20230515 (should probably upgrade), and the latest UV-K5 driver. There is no code in the driver to make this setting immutable.

What version are you using and what OS? Does the software signal any errors?

If you're under linux, then run it on the console with -vvv arguments and see if there are any errors besides gtk errors (ignore stuff like: (chirp:169510): Gtk-CRITICAL **: 20:38:59.565: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar, GTK developers have a strange understanding of what "ciritcal" means). Maybe you can do the same under windows.

VY 73

Jacek / SQ5BPF

Hi!
Using a windows 10 box with a known good cable. Com 10, standard port settings, C-N 20230606, issue 10478 revision 05T06:36:41Z.

I don't see a listing under any of the names (Anysecu UV-K5, Quansheng UV-K5, Radtel RT-590, Wurui K5,
LSENG UV-K5. I tried Baofeng UV-5R also.

Radio on, insert plug, insert usb, wait, turn on chirp, select issue, then read.

What am I missing?

I'll check back later today, Thanks!

Thanks!

Shawn Hughes wrote in #note-80:

Hi!
Using a windows 10 box with a known good cable. Com 10, standard port settings, C-N 20230606, issue 10478 revision 05T06:36:41Z.

I don't see a listing under any of the names (Anysecu UV-K5, Quansheng UV-K5, Radtel RT-590, Wurui K5,
LSENG UV-K5. I tried Baofeng UV-5R also.

Radio on, insert plug, insert usb, wait, turn on chirp, select issue, then read.

What am I missing?

I'll check back later today, Thanks!

Thanks!

My guess would be that you don't have any of the test driver modules loaded and running. See LoadingTestModules .

Jim KC9HI

Jim Unroe wrote in #note-81:

Shawn Hughes wrote in #note-80:

Hi!
Using a windows 10 box with a known good cable. Com 10, standard port settings, C-N 20230606, issue 10478 revision 05T06:36:41Z.

I don't see a listing under any of the names (Anysecu UV-K5, Quansheng UV-K5, Radtel RT-590, Wurui K5,
LSENG UV-K5. I tried Baofeng UV-5R also.

Radio on, insert plug, insert usb, wait, turn on chirp, select issue, then read.

What am I missing?

I'll check back later today, Thanks!

Thanks!

My guess would be that you don't have any of the test driver modules loaded and running. See LoadingTestModules .

Jim KC9HI

I listed the revision I was attempting to utilize. It stated the module loaded successfully. Should I see it listed under anysecu or quansheng?

Thanks for responding!

I don't see how to edit my last.

I now see it under Quansheng UV-K5, but now I am getting 'bad response header'.

Ok

turn radio on > plug cable into radio > plug cable into USB port > wait for port to enumerate > Start Chirp-Next in administrator mode > select help/load module from issue/10478/bottommost revision.

Works to download off of radio and upload!

I do see more than 200 rows of channels, unsure what the last ones are, or if they are modifiable. Thank you, I'll return to lurking unless I can help somehow.
Best

Shawn

So this updated version has the ability to pick two radio models: UV-K5 and UV-K5 (modified firmware). If you pick the latter, then it is possible to program all frequencies up to 1.3GHz. You can program channels, and use the frequency as the channel name, which should display correctly on these radios.

We'll need to figure out a different way to handle this. The vendor/model needs to be timeless, and presumably there will be more tweaks after this. If you're modifying the firmware, hopefully there's a string you can tweak or something to be able to detect it from chirp.

We have one example where we made this mistake in the past and it has been ugly ever since. But at least that radio reports as a different model when it's been modified, so that you can't use the wrong driver against the modified or stock configuration.

Dan Smith wrote in #note-86:
fferent way to handle this. The vendor/model needs to be timeless, and presumably there will be more tweaks after this. If you're modifying the firmware, hopefully there's a string you can tweak or something to be able to detect it from chirp.

I'm not modifying the firmware myself (working on it, but others could provide working versions much faster), but asked the authors to patch the first letter of the version string (easy 1-byte patch). It is accepted, but i haven't checked if they have really done it in the released versions.

I do plan on raising an exception when using an unmodified radio with the modified radio model.

We have one example where we made this mistake in the past and it has been ugly ever since. But at least that radio reports as a different model when it's been modified, so that you can't use the wrong driver against the modified or stock configuration.

There is no harm in using the "no limits" driver version with an unpatched radio. It's just that the radio wont work on the channels with out-of-range frequencies.

That said, you are right, this version can evolve into something that will not be compatible with a regular radio (now this is not a problem).

If they start releasing firmware with a modified version string, then i will quickly implement a check that will raise an exception during uploading the config to the radio. At the beginning of this process a hello packet has to be sent, and the reply is the firmware version, so this is easy to implement.

VY 73

Jacek / SQ5BPF

I'm not modifying the firmware myself (working on it, but others could provide working versions much faster), but asked the authors to patch the first letter of the version string (easy 1-byte patch). It is accepted, but i haven't checked if they have really done it in the released versions.

Cool.

There is no harm in using the "no limits" driver version with an unpatched radio. It's just that the radio wont work on the channels with out-of-range frequencies.

That said, you are right, this version can evolve into something that will not be compatible with a regular radio (now this is not a problem).

If they start releasing firmware with a modified version string, then i will quickly implement a check that will raise an exception during uploading the config to the radio. At the beginning of this process a hello packet has to be sent, and the reply is the firmware version, so this is easy to implement.

Cool, sounds good. If it won't cause harm then there are a couple of ways we could make it a soft toggle sort of thing, but I'd very much prefer to have a firmware version we can key off of and just make the driver do the right thing. Even if it's not harmful now, future versions could have any number of substantial changes. We can store the firmware version in the metadata of the image if you don't have it already in the actual memory space somewhere. Then the driver can properly adjust the valid_bands it reports to the UI based on the firmware that the image came from. That plus a check that you're not uploading an image from a modified radio into another unmodified one will be ideal.

We have to be careful here and not unnecessarily open the possibility for bricking people's radios. 99% of people will run with unmodified firmware, so that's the case we need to optimize for (and the users we need to protect).

These appear to be current from the manufacturer (pulled from the native app)
Software version: k5_2.01.26
Hardware version: 1.0
My radio is very recent so I can run some tests on it if you can instruct me. Not sure how that helps you.

Boris K wrote in #note-89:

My radio is very recent so I can run some tests on it if you can instruct me. Not sure how that helps you.

The basic test is "use it and see if it works" :) As dumb as that may sound, there are probably a few cases when the software doesn't work as it should.

VY 73

Jacek / SQ5BPF

Jacek Lipkowski wrote in #note-79:

Wito Krasnal wrote in #note-78:

The Busy Channel Lock setting per channel in Memory Properties - Other Tab does not work.

It works for me. I'm using chirp-next 20230515 (should probably upgrade), and the latest UV-K5 driver. There is no code in the driver to make this setting immutable.

This I understand, thus my hesitation.

What version are you using and what OS? Does the software signal any errors?

If you're under linux, then run it on the console with -vvv arguments and see if there are any errors besides gtk errors (ignore stuff like: (chirp:169510): Gtk-CRITICAL **: 20:38:59.565: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar, GTK developers have a strange understanding of what "ciritcal" means). Maybe you can do the same under windows.

VY 73

Jacek / SQ5BPF

the OS is Windows 11, the CHIRP version was/is -next 20230515 through 20230608.
The same thing worked fine in CHIRP-legacy.
the same bug appears with Baofeng UV-5R driver - thus my hesitation.
no errors signalled by the software
it's just that once unchecked, the particular BCL checkbox cannot be "permanently" rechecked again
and the BCL setting does not really change to "on" again, what you can confirm through Radio Browser tab (this is with Bao driver; but I don't know yet where this setting is located in QS driver).
changing the setting does work from "on" to "off" but then cannot be again set to "on"; after confirmation OK and when reopened, the tab again presents the BCL checkbox unchecked.

Wito are you talking about the UV-5R or the K5? All these settings work fine for me on the UV-5R driver. If that's what you're talking about, please open a separate bug and let's discuss there.

Wito, good that you compared how this works in other radio drivers.

This doesn't appear under chirp-next 20230515 under linux, so may be something related to your installation (different wxwidgets library etc). There was recently a bug where the extra settings could not be brought up when chirp was used under linux and this was related to the wxwidgets library. Maybe now it's the other was around.

But for sure this is something related to your installation, i guess many people use chirp under windows and would report the bug sooner.

Like Dan suggested, please discuss this in another issue.

VY 73

Jacek / SQ5BPF

Dan Smith wrote in #note-94:

Wito are you talking about the UV-5R or the K5? All these settings work fine for me on the UV-5R driver. If that's what you're talking about, please open a separate bug and let's discuss there.

I have opened a separate bug elsewhere before, about Bao UV-5R. I'm discussing it here in UV-K5 thread, because I noticed similar bug also with UV-K5. The problem appears both in UV-K5 and UV-5R. I don't know about other drivers because I do not own another radios. But now this appears somehow resolved: The problem disappeared after deleting the localization files from CHIRP\wx\locale. My localization is Polish. When Polish localization files were deleted, and CHIRP switched itself to wholly English, the Extra tabs and their checkboxes started to behave and work properly in both cases. Because when I deleted all localization files, then only restored Slovak file to CHIRP\wx\locale and renamed the folder from sk to pl, then the GUI was in Slovak, but the bug reappeared, so I think all the localization files, the whole localization engine, is affected. I'm very sorry for raising the issue here in incorrect thread, but as said before, I have already raised a separate thread before elsewhere, and here it was to remind about it.

The system where the bug appears is Windows 11. I'm unable to test it on Linux.

Jacek Lipkowski wrote in #note-95:

Wito, good that you compared how this works in other radio drivers.

This doesn't appear under chirp-next 20230515 under linux, so may be something related to your installation (different wxwidgets library etc). There was recently a bug where the extra settings could not be brought up when chirp was used under linux and this was related to the wxwidgets library. Maybe now it's the other was around.

But for sure this is something related to your installation, i guess many people use chirp under windows and would report the bug sooner.

Yes I thought so, so I was confused.

Like Dan suggested, please discuss this in another issue.

Yes: as said before, I have raised a separate issue before, no reaction, nobody noticed.

VY 73

Jacek / SQ5BPF

I don't know what can be wrong with my installation. I don't know what are external dependencies of CHIRP (some VC++ runtimes etc?) but all internals are in place, it's a normal installation from a version-described CHIRP-next *.exe installer, no custom settings, everything default. As said before, the bug disappears after deletion of localization files from CHIRP\wx\locale. If this folder is emptied, CHIRP works without it, with the whole GUI switched to English, and in such case the bug disappears and the Extra tab with its checkboxes behaves properly both in UV-5R and UV-K5. Restoring of any another language (and renaming it to pl) causes the bug to reappear.

Bug #10578 27 days ago.

Ok,
I used Tuna's expanded bin on the QS UV-K5. I was able to front panel program some CRAZY frequencies! Using a widebanded antenna, I was able to receive in several bands. I didn't see a major change in sensitivity in the 2m/440 band.

I forgot about the modified version of the chirp. I tried to down and upload with the factory; it would not let me key in out of band frequencies. I then tried the chirp (loading 10478/last revision). It also downloaded and uploaded fine, but would not allow pc programming of out of band listening frequencies.

I came here and read the notes, then went back and used the modified version to download. It allowed me to key in one out of band frequency (26.965 US citizen's band), but would not allow me to key in any others. I tried in a low number memory and a high number in case that was a thing. I will cold restart all of it and see if that changes things. I also will download todays distro of chirp in there as well.

(I seem to recall there is a proper way to bug report, I am sorry I can't find it right now. )

Shawn Hughes wrote in #note-103:

I forgot about the modified version of the chirp. I tried to down and upload with the factory; it would not let me key in out of band frequencies. I then tried the chirp (loading 10478/last revision). It also downloaded and uploaded fine, but would not allow pc programming of out of band listening frequencies.

Use the last version. There will be 3 Quansheng radio models in chirp: TG-UV2+, UV-K5 and UV-K5 (modified firmware) nolimits. If you want to program a radio with the hacked firmware, use the last one.

VY 73

Jacek / SQ5BPF

Question:

Is it possible to add to the list of things the programmable side buttons can do? I'd like to be able to change the LCD from name>frequency>channel, for instance, or map the scan feature there, or add nuisance channel scan delete.

... Don't get me wrong, this is amazing work. I just wonder if it is something already being contemplated.

Thanks!

Forgot to ask, how does one program a GHz frequency from the front panel?

Thanks again

Shawn Hughes wrote in #note-106:

Forgot to ask, how does one program a GHz frequency from the front panel?

This is not a general UV-K5 support group. Questions about using the radio should be posted elsewhere.

Regarding the chirp driver, this is work in progress, you can read all comments to get an idea how quickly features are added and bugs fixed.
I've released it now, so that people could benefit from it before it's 100% complete, and also report bugs (opensource "release early, release often" methodology).

Currently the following features are missing: dtmf contacts, programmable keys (and maybe something i've missed).

VY 73

Jacek / SQ5BPF

excuse me again for my interruption.
some features missing in the driver as yet, or forgotten to add:

• ABR (LCD backlight timeout) in Settings
• force 10-character limit in channel names and logo strings
• how to add channels to scanlists 1 & 2 (or remove from)

Updated by Jacek Lipkowski about 15 hours ago

Shawn Hughes wrote in #note-106:

Forgot to ask, how does one program a GHz frequency from the front panel?

This is not a general UV-K5 support group. Questions about using the radio should be posted elsewhere.

considering there is no way to do this on a factory flash, I assumed asking how to do that in here was ok. Appears I have worn out my welcome. Apologies.

Hello friends,
I have bought one of these radios a few weeks ago, recently I found this issue and have been trying both this driver for the uv-k5 and the modified firmware.
Everything has been working brilliantly, but one thing I noticed is that in vfo mode all sorts of crazy frequencies work. The odd thing is when I program, say 27.305 in chirp and upload to radio although chirp accepts it no problem, in the actual radio it gets saved as 50.0000 and I'm not sure if this is chirp or the radio fault.
One other question I have is if it or will be possible to inhibit TX per channel like one does on a baofeng.
Best regards
Ps: I have both window and Linux (Ubuntu) inhalations of chirp and can test stuff for you with some gidence

Nuno Lobo wrote in #note-110:

Everything has been working brilliantly, but one thing I noticed is that in vfo mode all sorts of crazy frequencies work. The odd thing is when I program, say 27.305 in chirp and upload to radio although chirp accepts it no problem, in the actual radio it gets saved as 50.0000 and I'm not sure if this is chirp or the radio fault.

If you are programming 27.305, then it won't work on normal firmware. You can use modified firmware and then maybe it will work.

VY 73

Jacek / SQ5BPF

Jacek Lipkowski wrote in #note-111:

Nuno Lobo wrote in #note-110:

Everything has been working brilliantly, but one thing I noticed is that in vfo mode all sorts of crazy frequencies work. The odd thing is when I program, say 27.305 in chirp and upload to radio although chirp accepts it no problem, in the actual radio it gets saved as 50.0000 and I'm not sure if this is chirp or the radio fault.

If you are programming 27.305, then it won't work on normal firmware. You can use modified firmware and then maybe it will work.

VY 73

Jacek / SQ5BPF

Yes i know I've been using the "k5_26_encrypted_18to1300MHz_500k_Step.bin" firmware.
If I punch in 27.305 in the vfo it works and even transmits to about 5km, but if I try to save it thru chirp with name and everything it appears to work but in the actual station it gets saved as 50.0000.
Weirdly if I read from radio again it apears normal (it shows 27.305)

Nuno Lobo wrote in #note-113:

Jacek Lipkowski wrote in #note-111:

Nuno Lobo wrote in #note-110:

Everything has been working brilliantly, but one thing I noticed is that in vfo mode all sorts of crazy frequencies work. The odd thing is when I program, say 27.305 in chirp and upload to radio although chirp accepts it no problem, in the actual radio it gets saved as 50.0000 and I'm not sure if this is chirp or the radio fault.

If you are programming 27.305, then it won't work on normal firmware. You can use modified firmware and then maybe it will work.

VY 73

Jacek / SQ5BPF

Yes i know I've been using the "k5_26_encrypted_18to1300MHz_500k_Step.bin" firmware.
If I punch in 27.305 in the vfo it works and even transmits to about 5km, but if I try to save it thru chirp with name and everything it appears to work but in the actual station it gets saved as 50.0000.
Weirdly if I read from radio again it apears normal (it shows 27.305)

Same issue here with the other tx free firmware versions. 27Mhz CB frequencies programmed/saved by hand at vfo, no problem. Read out with chirp and write back it show 50.0000.

Michael Summer wrote in #note-114:

Nuno Lobo wrote in #note-113:

Jacek Lipkowski wrote in #note-111:

Nuno Lobo wrote in #note-110:

Everything has been working brilliantly, but one thing I noticed is that in vfo mode all sorts of crazy frequencies work. The odd thing is when I program, say 27.305 in chirp and upload to radio although chirp accepts it no problem, in the actual radio it gets saved as 50.0000 and I'm not sure if this is chirp or the radio fault.

If you are programming 27.305, then it won't work on normal firmware. You can use modified firmware and then maybe it will work.

VY 73

Jacek / SQ5BPF

Yes i know I've been using the "k5_26_encrypted_18to1300MHz_500k_Step.bin" firmware.
If I punch in 27.305 in the vfo it works and even transmits to about 5km, but if I try to save it thru chirp with name and everything it appears to work but in the actual station it gets saved as 50.0000.
Weirdly if I read from radio again it apears normal (it shows 27.305)

Same issue here with the other tx free firmware versions. 27Mhz CB frequencies programmed/saved by hand at vfo, no problem. Read out with chirp and write back it show 50.0000.

And now that my new uv_k5(8) (but with old menu) just arived same issue, the firmware works exactly like the regular k5
73
Lobo CR7AXZ

Jacek Lipkowski wrote in #note-117:

I now have two more radios, so can test with both stock, modified firmware and do other tests (which might potentially brick the radio).

I would like to thank the anonymous sponsor (i can reveal the identity if the sponsor agrees).

The posted version solves the memory setting below 50MHz, at least for this firmware from Tunas1337:
https://github.com/Tunas1337/UV-K5-Modded-Firmwares/blob/main/k5_26_encrypted_18to1300MHz.bin

Please test it.

VY 73

Jacek / SQ5BPF

I can confirm that it works on this firmware https://github.com/Tunas1337/UV-K5-Modded-Firmwares/blob/main/k5_26_encrypted_18to1300MHz_500k_Step.bin
I just had to retype the frequencies
thank You very much, You and Your sponsor

73
Nuno Lobo / CR7AXZ

Jim Unroe wrote in #note-115:

I was given an Anysecu UV-K5 radio that was an Amazon customer return. The radio is like new and appears to be nearly factory except that the original owner changed channel 1 to a NOAA WX radio frequency (162.550 MHz). I have attached a CHIRP "image" from this radio that can be used for development. I have, obviously, renamed the file from Quansheng to Anysecu.

Thanks Jim!

What is the firmware version? (settings -> driver information)

VY 73

Jacek / SQ5BPF

Nuno Lobo wrote in #note-118:

Jacek Lipkowski wrote in #note-117:

I now have two more radios, so can test with both stock, modified firmware and do other tests (which might potentially brick the radio).

I would like to thank the anonymous sponsor (i can reveal the identity if the sponsor agrees).

The posted version solves the memory setting below 50MHz, at least for this firmware from Tunas1337:
https://github.com/Tunas1337/UV-K5-Modded-Firmwares/blob/main/k5_26_encrypted_18to1300MHz.bin

Please test it.

VY 73

Jacek / SQ5BPF

I can confirm that it works on this firmware https://github.com/Tunas1337/UV-K5-Modded-Firmwares/blob/main/k5_26_encrypted_18to1300MHz_500k_Step.bin
I just had to retype the frequencies
thank You very much, You and Your sponsor

73
Nuno Lobo / CR7AXZ

Jacek Lipkowski wrote in #note-117:

I now have two more radios, so can test with both stock, modified firmware and do other tests (which might potentially brick the radio).

I would like to thank the anonymous sponsor (i can reveal the identity if the sponsor agrees).

The posted version solves the memory setting below 50MHz, at least for this firmware from Tunas1337:
https://github.com/Tunas1337/UV-K5-Modded-Firmwares/blob/main/k5_26_encrypted_18to1300MHz.bin

Please test it.

VY 73

Jacek / SQ5BPF

Yes, now everything works fine.
Thank you so much for the quick solution.
73 Michael

Jacek Lipkowski wrote in #note-119:

Jim Unroe wrote in #note-115:

I was given an Anysecu UV-K5 radio that was an Amazon customer return. The radio is like new and appears to be nearly factory except that the original owner changed channel 1 to a NOAA WX radio frequency (162.550 MHz). I have attached a CHIRP "image" from this radio that can be used for development. I have, obviously, renamed the file from Quansheng to Anysecu.

Thanks Jim!

What is the firmware version? (settings -> driver information)

VY 73

Jacek / SQ5BPF

Firmware Version: k5_2.01.19

Jim Unroe wrote in #note-121:

Firmware Version: k5_2.01.19

Ok, so not that exciting. This is the version that came with most radios UV-K5 from the factory. Chirp should support all functions without problems.

If you're interested, you can also check the bootloader version by putting the radio into flashing mode and running k5prog -D -Y (yes, k5prog has firmware flash support too :), but it will be most probably 2.00.06 like in all other radios.

VY 73

Jacek / SQ5BPF

Jacek Lipkowski wrote in #note-123:

Released a new version.

This doesn't bring any visible changes, but a lot of code has been rewritten, so i would be very grateful if you all could test it, even the features that worked previously.

VY 73

Jacek / SQ5BPF

i do tests on upload and download from modified firmware radio (FW k5_26_encrypted_18to1300MHz.bin) - OK
Edits on frequencies 2m/70cm and also under 50 Mhz, Scan Lists, CTCSS, Mode Settings, TXP, Tuning Steps - OK

73 Michael

Michael Summer wrote in #note-124:

i do tests on upload and download from modified firmware radio (FW k5_26_encrypted_18to1300MHz.bin) - OK
Edits on frequencies 2m/70cm and also under 50 Mhz, Scan Lists, CTCSS, Mode Settings, TXP, Tuning Steps - OK

Thanks Michael! this was exactly the test i needed, because i did a lot of modifications in the channel settings.

Anyone else?

VY 73

Jacek / SQ5BPF

Jacek Lipkowski wrote in #note-125:

Michael Summer wrote in #note-124:

i do tests on upload and download from modified firmware radio (FW k5_26_encrypted_18to1300MHz.bin) - OK
Edits on frequencies 2m/70cm and also under 50 Mhz, Scan Lists, CTCSS, Mode Settings, TXP, Tuning Steps - OK

Thanks Michael! this was exactly the test i needed, because i did a lot of modifications in the channel settings.

Anyone else?

VY 73

Jacek / SQ5BPF

Not exactly the test you were looking for but on stock firmware, I just installed on a Windows 10 system, cloned with an AIOC cable (https://github.com/skuep/AIOC), edited, and re-uploaded with seemingly no issues. I'll update this later on if there were issues with any of the memory channels. I had some odd stuff in there, for example for all the police and fire frequencies I have in there, I set the offset so that I transmit on 146.520 if I ptt since the uv-k5 automatically temporarily switches to the B channel if something is RXd on it with dual watch.

Seamless, quick, and easy. Absolutely thrilled to not have to install the sketchy OEM software with terrible features.

I am testing with the UV-K5 with modded firmware and the limitless image. The backlight timeout setting defaults to "Off" when I write back to the radio. Is there a possible fix? Also. is there a way to increase the time-out time from 5 sec to something like 20 secs?

for me it does not reset ABR to Off. It reads the current state, then rewrites exactly the same. Just there's no option to change ABR in CHIRP driver. firmware original unmodified .26, driver 20230621

I have just tried to identify, where the ABR setting is visible in Radio Browser, by changing settings directly in the radio menu, then downloading progressive images to CHIRP, and visually comparing readings. Results are unexpected.

1. ABR settings change unexpectedly appears under "tail_tone_elimination" where ABR Off is Hex 00, ABR 1 is Hex 01, ABR 5 is Hex 05 etc.
2. STE (tail elimination) change appears under "vfo_open" where STE On is Hex 01, STE Off is Hex 00
3. there is no option in radio menu corresponding to "vfo_open" so I cannot check it the other way around;
4. as yet nothing seems to change in "unknown" 1 & 2 registers. check for yourselves if You don't believe. The radio was bought in a specialist store in my hometown here in Poland. Slightly overpriced comparing to Chinese offers, but with Polish dealer's warranty. Date of manufacture is May 2023. Radio is identical to another one bought by a friend of mine a month later directly from China, and both are mutually compatible (AIR COPY fully works). So there's rather no bug in the radio.

Wito Krasnal wrote in #note-129:

1. ABR settings change unexpectedly appears under "tail_tone_elimination" where ABR Off is Hex 00, ABR 1 is Hex 01, ABR 5 is Hex 05 etc.
2. STE (tail elimination) change appears under "vfo_open" where STE On is Hex 01, STE Off is Hex 00
3. there is no option in radio menu corresponding to "vfo_open" so I cannot check it the other way around;

Thanks you all for tests.

This was exactly the reason i asked for them. The driver was converted from using masks and and/or/not logic to describing the bits directly in the memory struct, probably offset the data while doing it.
Will fix it.

VY 73

Jacek / SQ5BPF

VOX function (tx activation by voice) On / Off is registered under "unknown2" where On is Hex 01, Off is Hex 00
then under "vox_level" it seems to retain last non-Off value before deactivation to Off, but by rule: Hex = VOX - 1 (VOX 1 is Hex 00, VOX 4 is Hex 03 etc)

BEEP = "beep_control"
RP-STE = "repeater_tail_elimination" - these look good, not shifted elsewhere
but then no idea what is "keypad_tone"

after some quick checks, yes those "shifts" of functions/settings look corrected in Radio Browser and in Settings.
I mean ABR is under "backlight_auto_mode", STE under "tail_note_elimination" etc.
improved clarity and compatibility with the radio:
1.indeed channel name limit is 10 but logo line limit is 11 chars, I haven't noticed that subtle difference before.
and yes the driver does not accept more chars in both cases (in channel name 11th char is ignored, in logo line there is a warning message).
2.channels are now properly numbered 1-200 instead of previous 0-199.
3.SCREN (not SCREEN) in Unlock Settings indeed means Scrambler, I haven't mentioned that before seeing that as a minor issue.
4.and yes, by "keypad tone" they mean the language of voice prompts (VOICE in radio menu) (Hex 02 means English, Hex 01 means Chinese, Hex 00 - Off).
by now everything looks perfect
great respect for Your great work Jacek

Jacek Lipkowski wrote in #note-134:

Another fix, make a 12-character logo strings work. Issue reported by egzumer on github (thanks!)

VY 73

Jacek / SQ5BPF

yes 12 chars are accepted by the radio but this is the definite limit :D

Another issue I found: AM mode gets disabled very time writing to the scanner. So, when trying to browse frequencies down in the 10/11 meter range, only FM is available. Not sure if I'm explaining it correctly, but perhaps you guys can test that as well.

Boris K wrote in #note-137:

Another issue I found: AM mode gets disabled very time writing to the scanner. So, when trying to browse frequencies down in the 10/11 meter range, only FM is available. Not sure if I'm explaining it correctly, but perhaps you guys can test that as well.

It is normal behavior of this radio, and not connected to CHIRP. Every time You turn the radio off and on, AM Rx in menu 48 gets disabled by default. However if a channel is flagged as AM in CHIRP, it remains AM.

This is merged for tomorrow's build, but with one notable change from what everyone here has been testing. Instead of two models in the drop-down box for OEM or modified firmware, there's a toggle in Settings > Driver information. You can use the same model for either firmware, but the toggle will allow you to enter the out-of-band frequencies supported by the modified firmware. Once the modified firmware has some sentinel for us to detect it in the image, we can make that automatic.

Any bugs you find from that or any of the other small cleanups I made on top of Jacek's work can be blamed on me. Please open a new bug report for anything you find going forward.

Dan Smith wrote in #note-143:

This is merged for tomorrow's build

I was able to program my Quansheng UV-K5 using Chirp. Thanks for all the great effort to bring this to life!