CHIRP

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.

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

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.

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 :-(

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

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

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.

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.

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

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

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.