Project

General

Profile

Actions

Bug #10698

open

Quansheng UV-K5 Modded firmware AM out of range memory allocation

Added by Ham Oppo 11 months ago. Updated 9 months ago.

Status:
New
Priority:
Normal
Category:
-
Target version:
Start date:
07/03/2023
Due date:
% Done:

0%

Estimated time:
Chirp Version:
next
Model affected:
Quansheng UV-K5
Platform:
Windows
Debug Log:
I read the instructions above:

Description

Version: chirp-next-20230701
OS: Win 10
Modded with: uvmod-kitchen.py
Firmware: k5_v2.01.26_MODDED.bin

Problem: AM specific memory channel saves on ranges outside of 108.000-135.975MHz, not saving and being replaced by 420.00MHz after editing with CHIRP (previous and latest).

As suggested, downloaded content from radio (which contains hand written 200MHz+ working frequencies in AM mode).

Made changes to the first three entries adding name tags "Edited 1", "Edited 2" and "Edited 3" in memory channels 001, 002, and 003.

Saved and uploaded to radio. Memory channels 004 onwards remain as before editing ie in AM mode. However the first 3 channel (001-003) frequencies changed to 420.000MHz FM. The edited tags do show.

Hope this is useful.

Thanks

M7OCM


Files

-3-Quansheng_UV-K5_20230703-contents_written_to_radio_and_read_by_radio.img (8.18 KB) -3-Quansheng_UV-K5_20230703-contents_written_to_radio_and_read_by_radio.img File uploaded to radio then downloaded to PC and saved Ham Oppo, 07/03/2023 02:23 AM
-2-Quansheng_UV-K5_20230703-3tags_added_saved_before_write.img (8.26 KB) -2-Quansheng_UV-K5_20230703-3tags_added_saved_before_write.img Edited in CHIRP Ham Oppo, 07/03/2023 02:23 AM
-1-Quansheng_UV-K5_20230703-read_from_radio.img (8.18 KB) -1-Quansheng_UV-K5_20230703-read_from_radio.img Contents of radio read by CHIRP Ham Oppo, 07/03/2023 02:23 AM
k5_v2.01.26_MODDED.bin (57.3 KB) k5_v2.01.26_MODDED.bin Custom firmware used Ham Oppo, 07/03/2023 02:26 AM
uvk5.py (67.3 KB) uvk5.py UV-K5 driver modded for AM problem 20230703 Jacek Lipkowski SQ5BPF, 07/03/2023 01:07 PM
-0-Quansheng_UV-K5_20230704-contents_written_to_radio_and_read_by_radio.img (8.65 KB) -0-Quansheng_UV-K5_20230704-contents_written_to_radio_and_read_by_radio.img The above issues in img Ham Oppo, 07/04/2023 01:19 AM
CHIRP-TEST-080723.csv (1.76 KB) CHIRP-TEST-080723.csv My Test CSV radio contents Ham Oppo, 07/08/2023 03:39 AM
Quansheng_UV-K5_20230708.img (8.18 KB) Quansheng_UV-K5_20230708.img CHIRP IMG Ham Oppo, 07/08/2023 03:39 AM
mod_custom_freq_ranges.py (2.01 KB) mod_custom_freq_ranges.py UV Mod Kitchen Freq Ranges .py Ham Oppo, 07/08/2023 03:40 AM
k5_v2.01.26_MODDED.bin (58.3 KB) k5_v2.01.26_MODDED.bin UV Mod Kitchen (bin) Ham Oppo, 07/08/2023 03:40 AM
Quansheng_UV-K5_20230710.img (8.18 KB) Quansheng_UV-K5_20230710.img Radio .img Ham Oppo, 07/10/2023 05:41 AM
Quansheng_UV-K5_chirpreadback.img (8.18 KB) Quansheng_UV-K5_chirpreadback.img what CHIRP read back immediately afterwards Xikteny R, 08/23/2023 06:20 AM
Quansheng_UV-K5_chirpwrote.img (8.21 KB) Quansheng_UV-K5_chirpwrote.img what was sent to the radio during the initial attempt to use CHIRP to program the radio Xikteny R, 08/23/2023 06:20 AM
Quansheng_UV-K5_vfowrote.img (8.18 KB) Quansheng_UV-K5_vfowrote.img what CHIRP read back from the radio after using the radio's VFO to save 27.185 to a channel Xikteny R, 08/23/2023 06:20 AM
Actions #1

Updated by Dan Smith 11 months ago

  • Assignee set to Jacek Lipkowski SQ5BPF
  • Target version set to chirp-py3
Actions #2

Updated by Jacek Lipkowski SQ5BPF 11 months ago

Check if this driver version will solve your problem.

Select Help -> Load modules from issue , enter this issue (10698), select the uvk5.py driver.

In Settings -> Driver Information enable the options:
Limits disabled for modified firmware
Force Band1 for all AM in modded firmware

Try if AM works when set on frequencies from these bands:
below 50.0 MHz
50.0 - 76.0,
108.0, 135.9999,
136.0 - 199.9990,
200.0 - 299.9999,
350.0 - 399.9999,
400.0 - 469.9999,
470.0 - 600.0
above 850MHz

And report back what works and what doesn't. In the same way as you've done. While you're at it, check if FM works ok.

VY 73

Jacek / SQ5BPF

Actions #3

Updated by Dan Smith 11 months ago

Jacek, is this something that will vary based on the version or configuration of the modified firmware? If so, we really should push for a version or feature flag array so we can do the right thing.

However, in the meantime - if you mark the main "limits disabled" as volatile (rs.set_volatile(True)) then changing its value will reload settings in the UI. You can then control the mutability of the new option based on whether that is enabled or not and avoid the warning for that one if you want. If it make sense to make those warn independently then that's fine, but just FYI if it is smoother for the user to get one warning about being modified and then have that enable other features without further warnings.

Actions #4

Updated by Jacek Lipkowski SQ5BPF 11 months ago

Dan Smith wrote in #note-3:

Jacek, is this something that will vary based on the version or configuration of the modified firmware?

Yes. These firmware mods are not only a simple modification of some constants, but also adding custom patches to the arm binary. So it's a moving target.

For example the radio has a concept of bands, which have to be set correctly for each memory location. Currently the "enable AM receive everywhere" patches set the range of 18-1300MHz for band 1, which was previously the 108-137 MHz air band. The reason for this is that AM works only on band 1, but if this limitation is lifted, then the band limits can be set differently.

If so, we really should push for a version or feature flag array so we can do the right thing.

Yes. We'll see what happens with the modded firmware development, and how many such flags would be needed.

However, in the meantime - if you mark the main "limits disabled" as volatile (rs.set_volatile(True)) then changing its value will reload settings in the UI.

Thanks, i was looking for something like that. Currently what i published is just a simple proof of concept, but if it works, then i will do it properly.

VY 73

Jacek / SQ5BPF

Actions #5

Updated by Dan Smith 11 months ago

Thanks, i was looking for something like that. Currently what i published is just a simple proof of concept, but if it works, then i will do it properly.

Cool, thanks for jumping on this. This afternoon I'll fix that reload so it doesn't reset the view in the UI as well (i.e. jump you back to the root of the settings tree) so that the user doesn't perceive much change.

Actions #6

Updated by Ham Oppo 11 months ago

Dan Smith wrote in #note-3:

Jacek, is this something that will vary based on the version or configuration of the modified firmware? If so, we really should push for a version or feature flag array so we can do the right thing.

However, in the meantime - if you mark the main "limits disabled" as volatile (rs.set_volatile(True)) then changing its value will reload settings in the UI. You can then control the mutability of the new option based on whether that is enabled or not and avoid the warning for that one if you want. If it make sense to make those warn independently then that's fine, but just FYI if it is smoother for the user to get one warning about being modified and then have that enable other features without further warnings.

Thanks Jacek unfortunately after loading the module, I cannot adjust settings due to an error occurring 'set_warning'. I've reloaded the driver numerous times but no joy :-(

Actions #7

Updated by Jacek Lipkowski SQ5BPF 11 months ago

Ham Oppo wrote in #note-6:

Thanks Jacek unfortunately after loading the module, I cannot adjust settings due to an error occurring 'set_warning'. I've reloaded the driver numerous times but no joy :-(

You need to have the newest CHIRP next-20230703

VY 73

Jacek / SQ5BPF

Actions #8

Updated by Ham Oppo 11 months ago

Jacek Lipkowski SQ5BPF wrote in #note-7:

Ham Oppo wrote in #note-6:

Thanks Jacek unfortunately after loading the module, I cannot adjust settings due to an error occurring 'set_warning'. I've reloaded the driver numerous times but no joy :-(

You need to have the newest CHIRP next-20230703

VY 73

Jacek / SQ5BPF

Thanks for the reminder! Latest version plus module loaded.

Okay interesting... added the following in memory. First frequency is actual entered in CHIRP, the next frequency is what is being uploaded to radio and shown. All barring Memories 18, 19 were set to AM.

  • denotes issues

01 18.000000 showing as 25.00000 AM *
02 25.000000 showing as 25.00000 AM
03 50.000000 showing as 18.00000 FM *
04 75.000000 showing as 18.00000 FM *
05 110.00000 showing as 110.00000 AM
06 142.00000 showing as 400.00000 FM *
07 145.00000 showing as 400.00000 FM *
08 250.00000 showing as 420.00000 FM *
09 299.97500 showing as 420.00000 FM *
10 400.00000 showing as 440.00000 FM *
11 450.00000 showing as 450.00000 FM
12 470.00000 showing as 470.00000 FM
13 500.00000 showing as 500.00000 FM
14 600.00000 showing as 600.00000 FM
15 850.00000 showing as 850.00000 FM
16 1200.00000 showing as (1)200.00000 FM

18 433.00000 showing as 433.00000 FM
19 351.00000 nothing shown *

73 Mark M7OCM

Actions #9

Updated by Jacek Lipkowski SQ5BPF 11 months ago

Please try these frequencies + 50kHz (so for example 18.050MHz etc...):
below 50.0 MHz
50.0 - 76.0,
108.0, 135.9999,
136.0 - 199.9990,
200.0 - 299.9999,
350.0 - 399.9999,
400.0 - 469.9999,
470.0 - 600.0
above 850MHz

both FM and AM

Save, and see if they work on your firmware version. And download the img file and post it in this bug.
I have a radio with a modified firmware, and actually i can't figure out when it uses which band and it doesn't always work (it has a problem when the AM and FM chanells).

Unfortunately chirp can't fix problems with the firmware itself, so i will only accept an image that was downloaded from radio, and we know that it works, and i can put it on my radio (also with modified firmware) and it also works.

VY 73

Jacek / SQ5BPF

Actions #10

Updated by Ham Oppo 11 months ago

Jacek Lipkowski SQ5BPF wrote in #note-9:

Please try these frequencies + 50kHz (so for example 18.050MHz etc...):
below 50.0 MHz
50.0 - 76.0,
108.0, 135.9999,
136.0 - 199.9990,
200.0 - 299.9999,
350.0 - 399.9999,
400.0 - 469.9999,
470.0 - 600.0
above 850MHz

both FM and AM

Save, and see if they work on your firmware version. And download the img file and post it in this bug.
I have a radio with a modified firmware, and actually i can't figure out when it uses which band and it doesn't always work (it has a problem when the AM and FM chanells).

Unfortunately chirp can't fix problems with the firmware itself, so i will only accept an image that was downloaded from radio, and we know that it works, and i can put it on my radio (also with modified firmware) and it also works.

VY 73

Jacek / SQ5BPF

Excellent work Jacek! Thank you.

For the test I prepared 20 memory channels first 10 in AM mode next 10 in FM - 2 groups same 10 freqs. Hoping this would flush out obvious issues.

ATT csv

ATT CHIRP .img from radio - read/write/read/save

M1, M7, M8, M9 and M10 changed from programmed ranges to 25.000 however remained AM :-)

M11, M13, M15, M16, M17 remained in FM but changed to 25.000, 18.000, 400.000, 420.000, 440.000 respectively.

As you mentioned custom firmware is impacting on all this so I've attached my .py custom frequency ranges for your perusal.

This is super progress and for me works well enough to use - my original intent 108.000-142.975 AM/225.000-400.00 AM.

Need to play radio a bit more just to check though ;)

Thank you very much - this can't have been easy! 73 Mark M7OCM

Actions #11

Updated by Ham Oppo 11 months ago

Ham Oppo wrote in #note-10:

Jacek Lipkowski SQ5BPF wrote in #note-9:

Please try these frequencies + 50kHz (so for example 18.050MHz etc...):
below 50.0 MHz
50.0 - 76.0,
108.0, 135.9999,
136.0 - 199.9990,
200.0 - 299.9999,
350.0 - 399.9999,
400.0 - 469.9999,
470.0 - 600.0
above 850MHz

both FM and AM

Save, and see if they work on your firmware version. And download the img file and post it in this bug.
I have a radio with a modified firmware, and actually i can't figure out when it uses which band and it doesn't always work (it has a problem when the AM and FM chanells).

Unfortunately chirp can't fix problems with the firmware itself, so i will only accept an image that was downloaded from radio, and we know that it works, and i can put it on my radio (also with modified firmware) and it also works.

VY 73

Jacek / SQ5BPF

Excellent work Jacek! Thank you.

For the test I prepared 20 memory channels first 10 in AM mode next 10 in FM - 2 groups same 10 freqs. Hoping this would flush out obvious issues.

ATT csv

ATT CHIRP .img from radio - read/write/read/save

M1, M7, M8, M9 and M10 changed from programmed ranges to 25.000 however remained AM :-)

M11, M13, M15, M16, M17 remained in FM but changed to 25.000, 18.000, 400.000, 420.000, 440.000 respectively.

As you mentioned custom firmware is impacting on all this so I've attached my .py custom frequency ranges for your perusal.

This is super progress and for me works well enough to use - my original intent 108.000-142.975 AM/225.000-400.00 AM.

Need to play radio a bit more just to check though ;)

Thank you very much - this can't have been easy! 73 Mark M7OCM

Maybe jumped the gun. The above data was using the module 03/07/2023 when I loaded it the other one didn't show ie 08/07/23 that has produced different results which I'll have to examine.

Actions #12

Updated by Ham Oppo 11 months ago

Ham Oppo wrote in #note-11:

Ham Oppo wrote in #note-10:

Jacek Lipkowski SQ5BPF wrote in #note-9:

Please try these frequencies + 50kHz (so for example 18.050MHz etc...):
below 50.0 MHz
50.0 - 76.0,
108.0, 135.9999,
136.0 - 199.9990,
200.0 - 299.9999,
350.0 - 399.9999,
400.0 - 469.9999,
470.0 - 600.0
above 850MHz

both FM and AM

Save, and see if they work on your firmware version. And download the img file and post it in this bug.
I have a radio with a modified firmware, and actually i can't figure out when it uses which band and it doesn't always work (it has a problem when the AM and FM chanells).

Unfortunately chirp can't fix problems with the firmware itself, so i will only accept an image that was downloaded from radio, and we know that it works, and i can put it on my radio (also with modified firmware) and it also works.

VY 73

Jacek / SQ5BPF

Excellent work Jacek! Thank you.

For the test I prepared 20 memory channels first 10 in AM mode next 10 in FM - 2 groups same 10 freqs. Hoping this would flush out obvious issues.

ATT csv

ATT CHIRP .img from radio - read/write/read/save

M1, M7, M8, M9 and M10 changed from programmed ranges to 25.000 however remained AM :-)

M11, M13, M15, M16, M17 remained in FM but changed to 25.000, 18.000, 400.000, 420.000, 440.000 respectively.

As you mentioned custom firmware is impacting on all this so I've attached my .py custom frequency ranges for your perusal.

This is super progress and for me works well enough to use - my original intent 108.000-142.975 AM/225.000-400.00 AM.

Need to play radio a bit more just to check though ;)

Thank you very much - this can't have been easy! 73 Mark M7OCM

Maybe jumped the gun. The above data was using the module 03/07/2023 when I loaded it the other one didn't show ie 08/07/23 that has produced different results which I'll have to examine.

Unfortunately the latest update has similar results to previous versions in as much as 200MHz AM range shows as 420MHz FM etc the previous patch was very good. I'll await your feedback before trying anything else.

Actions #13

Updated by Jacek Lipkowski SQ5BPF 11 months ago

Thanks for your img file. I've loaded it into my radio with modded firmware from here: https://github.com/Tunas1337/UV-K5-Modded-Firmwares (the 18-1300 MHz tx firmware, which i think most people use).

I can't get it to work on 142.050MHz AM, doesn't matter if it's via the keyboard, or by hexediting the eeprom image. I can get it to display AM in the setup menu, bu after that it doesn't show the AM icon, and receives FM (not AM).

It's not clear to me if this image is from your radio, where the am channel on 142.050 really displays the "AM" under the frequency, and this really receives AM. Or is this image from something that you've programmed in chirp only.

You're probably aware of this, but i will write it for the benefit of others reading this issue: chirp will not fix bugs in the radio firmware (both stock and modded firmware).

So questions:

  • what is the origin of your modded firmware?
  • is the Quansheng_UV-K5_20230708.img file from your radio?
  • if yes, does it work correctly? (shows 142.050 AM on channel 5)

VY 73

Jacek / SQ5BPF

Actions #14

Updated by Ham Oppo 11 months ago

Jacek Lipkowski SQ5BPF wrote in #note-13:

Thanks for your img file. I've loaded it into my radio with modded firmware from here: https://github.com/Tunas1337/UV-K5-Modded-Firmwares (the 18-1300 MHz tx firmware, which i think most people use).

I can't get it to work on 142.050MHz AM, doesn't matter if it's via the keyboard, or by hexediting the eeprom image. I can get it to display AM in the setup menu, bu after that it doesn't show the AM icon, and receives FM (not AM).

It's not clear to me if this image is from your radio, where the am channel on 142.050 really displays the "AM" under the frequency, and this really receives AM. Or is this image from something that you've programmed in chirp only.

You're probably aware of this, but i will write it for the benefit of others reading this issue: chirp will not fix bugs in the radio firmware (both stock and modded firmware).

So questions:

  • what is the origin of your modded firmware?
  • is the Quansheng_UV-K5_20230708.img file from your radio?
  • if yes, does it work correctly? (shows 142.050 AM on channel 5)

VY 73

Jacek / SQ5BPF

Thanks understood.

#1. UV Mod Kitchen - k5_v2.01.26_MODDED.bin (see previous file uploads including mod_custom_freq_ranges.py above)
#2. Technically Chirp, imported via CSV and uploaded to radio.
#3. Yes if referenced #2 :-)

To test purely radio image...

Try this Jacek, its a new img DIRECT from radio (NOT programmed with Chirp), 10 freqs - first 8 in AM last 2 FM. See how that works. Please free to use the exact same firmware I'm using.

Cheers Mark M7OCM

Actions #15

Updated by Jacek Lipkowski SQ5BPF 11 months ago

Ham Oppo wrote in #note-14:

To test purely radio image...

Try this Jacek, its a new img DIRECT from radio (NOT programmed with Chirp), 10 freqs - first 8 in AM last 2 FM. See how that works. Please free to use the exact same firmware I'm using.

Tried it on my radio. Channels 1-4 work, 5-9 don't work. 10 works. So it seems there is some incompatibility between firmwares, mostly due to band ranges.

I will try a few different firmware versions and see what works.

BTW if you want to experiment, then enable developer mode, and in the memory browser select channel_attributes, channel number (which is the radio memory number-1), and you can set the band manually.

VY 73

Jacek / SQ5BPF

Actions #16

Updated by Ham Oppo 10 months ago

Jacek Lipkowski SQ5BPF wrote in #note-15:

Ham Oppo wrote in #note-14:

To test purely radio image...

Try this Jacek, its a new img DIRECT from radio (NOT programmed with Chirp), 10 freqs - first 8 in AM last 2 FM. See how that works. Please free to use the exact same firmware I'm using.

Tried it on my radio. Channels 1-4 work, 5-9 don't work. 10 works. So it seems there is some incompatibility between firmwares, mostly due to band ranges.

I will try a few different firmware versions and see what works.

BTW if you want to experiment, then enable developer mode, and in the memory browser select channel_attributes, channel number (which is the radio memory number-1), and you can set the band manually.

VY 73

Jacek / SQ5BPF

Thanks Jacek for your time on this. Fortunately with the UV Mod Kitchen 'AM everywhere' python mod, programming AM channels now work perfectly using chirp.

Actions #17

Updated by Xikteny R 9 months ago

Ham Oppo wrote in #note-16:

Thanks Jacek for your time on this. Fortunately with the UV Mod Kitchen 'AM everywhere' python mod, programming AM channels now work perfectly using chirp.

Something that I think is similar to what has been described in this bug report is still happening to me.

I have a new UV-K5, I used https://whosmatt.github.io/uvmod/ to flash it with firmware that was modded with "Larger Frequency Range," and "AM RX on all Bands." I then reset the radio's memory.

I then tried to use CHIRP next-20230823 to program 27.185 to a memory channel. The radio then displayed this channel as 108.000. I then read back the radio to CHIRP, where it was still displayed as 27.185.

I then used the radio's VFO to save 27.185 to a channel, and this seemed to work. Both the radio and CHIRP display this channel as being 27.185. Attempting to edit this channel in CHIRP and write it back to the radio again results in the radio displaying it as 108.000.

I have attached several files, in case anyone can tell what the difference is between them:
Quansheng_UV-K5_chirpwrote.img is what was sent to the radio during the initial attempt to use CHIRP to program the radio.
Quansheng_UV-K5_chirpreadback.img is what CHIRP read back immediately afterwards.
Quansheng_UV-K5_vfowrote.img is what CHIRP read back from the radio after using the radio's VFO to save 27.185 to a channel.

Actions

Also available in: Atom PDF