CHIRP

Try adding frequencies (or single) from e.g. https://www.red-radio.co.uk/CB-Frequencies

27.60125
27.61125
27.62125
...

Get response:

Invalid Entry
Invalid edit: Unable to find a supported tuning step for 27.601250

Changing radio step to 1.25kHz allows me to step through to next frequency in list but step is not available in CHIRP Tuning Step list.

Digging a little further was able to import some of the frequencies.

Please can you have a look at the following details in order to permit import of all entries?

CSV source:

Name Frequency
CB 1 (UK) 27.60125
CB 2 (UK) 27.61125
CB 3 (UK) 27.62125
CB 4 (UK) 27.63125
CB 5 (UK) 27.64125
CB 6 (UK) 27.65125
CB 7 (UK) 27.66125
CB 8 (UK) 27.67125
CB 9 (UK) 27.68125
CB 10 (UK) 27.69125
CB 11 (UK) 27.70125
CB 12 (UK) 27.71125
CB 13 (UK) 27.72125
CB 14 (UK) 27.73125
CB 15 (UK) 27.74125
CB 16 (UK) 27.75125
CB 17 (UK) 27.76125
CB 18 (UK) 27.77125
CB 19 (UK) 27.78125
CB 20 (UK) 27.79125
CB 21 (UK) 27.80125
CB 22 (UK) 27.81125
CB 23 (UK) 27.82125
CB 24 (UK) 27.83125
CB 25 (UK) 27.84125
CB 26 (UK) 27.85125
CB 27 (UK) 27.86125
CB 28 (UK) 27.87125
CB 29 (UK) 27.88125
CB 30 (UK) 27.89125
CB 31 (UK) 27.90125
CB 32 (UK) 27.91125
CB 33 (UK) 27.92125
CB 34 (UK) 27.93125
CB 35 (UK) 27.94125
CB 36 (UK) 27.95125
CB 37 (UK) 27.96125
CB 38 (UK) 27.97125
CB 39 (UK) 27.98125
CB 40 (UK) 27.99125

Copy/Paste to Quansheng_UV-K5.img file - result:

Some memories are incompatible with this radio:

[150]: Unable to find a supported tuning step for 27.601250
[151]: Unable to find a supported tuning step for 27.611250
[152]: Unable to find a supported tuning step for 27.621250
[154]: Unable to find a supported tuning step for 27.641250
[155]: Unable to find a supported tuning step for 27.651250
[156]: Unable to find a supported tuning step for 27.661250
[157]: Unable to find a supported tuning step for 27.671250
[159]: Unable to find a supported tuning step for 27.691250
[160]: Unable to find a supported tuning step for 27.701250
[161]: Unable to find a supported tuning step for 27.711250
[162]: Unable to find a supported tuning step for 27.721250
[164]: Unable to find a supported tuning step for 27.741250
[165]: Unable to find a supported tuning step for 27.751250
[166]: Unable to find a supported tuning step for 27.761250
[167]: Unable to find a supported tuning step for 27.771250
[169]: Unable to find a supported tuning step for 27.791250
[170]: Unable to find a supported tuning step for 27.801250
[171]: Unable to find a supported tuning step for 27.811250
[172]: Unable to find a supported tuning step for 27.821250
...and 13 more

Allowed entries (imported):

CB 4 (UK) 27.63125
CB 9 (UK) 27.68125
CB 14 (UK) 27.73125
CB 19 (UK) 27.78125
CB 24 (UK) 27.83125
CB 29 (UK) 27.88125
CB 34 (UK) 27.93125
CB 39 (UK) 27.98125

But this is for a radio with modified firmware.

A stock radio will only support the official tuning steps.

The chirp driver does not currently support modified firmware, partly because there is so many of them, and they are a moving target.
Maybe in a year or so one most popular version will emerge (like Egzumer firmware for example), and then i can add support for this.
Before that it's not a good idea. I've added some support, and people started complaining that it doesn't work with their firmware (and at that time there were maybe hacked 3-4 versions, now everyone makes their own).

VY 73

Jacek / SQ5BPF

Using a step frequency of 6250 Hz only permits channels {4,9,14,19,24,29,34,39} to be imported due to integer Frequency/Step.

Channel Frequency (MHz) Frequency (Hz) Step (Hz) Frequency/Step Step Delta
1 27.60125 27601250 6250 4416.2 0
2 27.61125 27611250 6250 4417.8 1.6
3 27.62125 27621250 6250 4419.4 1.6
4 27.63125 27631250 6250 4421 1.6
5 27.64125 27641250 6250 4422.6 1.6
6 27.65125 27651250 6250 4424.2 1.6
7 27.66125 27661250 6250 4425.8 1.6
8 27.67125 27671250 6250 4427.4 1.6
9 27.68125 27681250 6250 4429 1.6
10 27.69125 27691250 6250 4430.6 1.6
11 27.70125 27701250 6250 4432.2 1.6
12 27.71125 27711250 6250 4433.8 1.6
13 27.72125 27721250 6250 4435.4 1.6
14 27.73125 27731250 6250 4437 1.6
15 27.74125 27741250 6250 4438.6 1.6
16 27.75125 27751250 6250 4440.2 1.6
17 27.76125 27761250 6250 4441.8 1.6
18 27.77125 27771250 6250 4443.4 1.6
19 27.78125 27781250 6250 4445 1.6
20 27.79125 27791250 6250 4446.6 1.6
21 27.80125 27801250 6250 4448.2 1.6
22 27.81125 27811250 6250 4449.8 1.6
23 27.82125 27821250 6250 4451.4 1.6
24 27.83125 27831250 6250 4453 1.6
25 27.84125 27841250 6250 4454.6 1.6
26 27.85125 27851250 6250 4456.2 1.6
27 27.86125 27861250 6250 4457.8 1.6
28 27.87125 27871250 6250 4459.4 1.6
29 27.88125 27881250 6250 4461 1.6
30 27.89125 27891250 6250 4462.6 1.6
31 27.90125 27901250 6250 4464.2 1.6
32 27.91125 27911250 6250 4465.8 1.6
33 27.92125 27921250 6250 4467.4 1.6
34 27.93125 27931250 6250 4469 1.6
35 27.94125 27941250 6250 4470.6 1.6
36 27.95125 27951250 6250 4472.2 1.6
37 27.96125 27961250 6250 4473.8 1.6
38 27.97125 27971250 6250 4475.4 1.6
39 27.98125 27981250 6250 4477 1.6
40 27.99125 27991250 6250 4478.6 1.6

Using a step frequency of 1250 Hz should allow all channels to be imported.

This step frequency is supported with EGZUMER v0.19 firmware.

Channel Frequency (MHz) Frequency (Hz) Step (Hz) Frequency/Step Step Delta
1 27.60125 27601250 1250 22081 0
2 27.61125 27611250 1250 22089 8
3 27.62125 27621250 1250 22097 8
4 27.63125 27631250 1250 22105 8
5 27.64125 27641250 1250 22113 8
6 27.65125 27651250 1250 22121 8
7 27.66125 27661250 1250 22129 8
8 27.67125 27671250 1250 22137 8
9 27.68125 27681250 1250 22145 8
10 27.69125 27691250 1250 22153 8
11 27.70125 27701250 1250 22161 8
12 27.71125 27711250 1250 22169 8
13 27.72125 27721250 1250 22177 8
14 27.73125 27731250 1250 22185 8
15 27.74125 27741250 1250 22193 8
16 27.75125 27751250 1250 22201 8
17 27.76125 27761250 1250 22209 8
18 27.77125 27771250 1250 22217 8
19 27.78125 27781250 1250 22225 8
20 27.79125 27791250 1250 22233 8
21 27.80125 27801250 1250 22241 8
22 27.81125 27811250 1250 22249 8
23 27.82125 27821250 1250 22257 8
24 27.83125 27831250 1250 22265 8
25 27.84125 27841250 1250 22273 8
26 27.85125 27851250 1250 22281 8
27 27.86125 27861250 1250 22289 8
28 27.87125 27871250 1250 22297 8
29 27.88125 27881250 1250 22305 8
30 27.89125 27891250 1250 22313 8
31 27.90125 27901250 1250 22321 8
32 27.91125 27911250 1250 22329 8
33 27.92125 27921250 1250 22337 8
34 27.93125 27931250 1250 22345 8
35 27.94125 27941250 1250 22353 8
36 27.95125 27951250 1250 22361 8
37 27.96125 27961250 1250 22369 8
38 27.97125 27971250 1250 22377 8
39 27.98125 27981250 1250 22385 8
40 27.99125 27991250 1250 22393 8

Using https://github.com/egzumer/uvk5-chirp-driver permits addition of all frequencies/channels/steps.

HI --
I am still seeing issues with this and not only for this radio (Quansheng UV-K's with latest Egzumer firmware as well as TIDRadio H3's stock firmware).
Perhaps one solution would be better rounding or perhaps an option to disable that check. Or even simpler just the error message having more details of how to round the numbers in Excel perhaps --

I have a number of frequencies programmed in from the radio directly and wanted to simply add a name via Chirp. but unable to do this as the frequency is apparently unsupported from the radio (according to Chirp) but it was downloaded from the radio.
I managed to work around this by changing to a random supported Frequency and updating the name then from the radio saving the correct frequency on top of that memory slot. But this is not an ideal way to work especially as I have a large number to enter in, and it is causing other mess, and confusing other settings.

I'm still not sure what the concern here is. Both the native and egzumer drivers in chirp now support 1kHz minimum steps and I've yet to see any actual channelized frequencies noted that are not allowed by the driver. Again, 146.000001 and 27.781250 both go in without any complaints. I'm open to increasing the egzumer driver to resolve down to 10Hz, but not so much the OEM driver as described above. What is the use-case for 10Hz steps for radios like these? Has anyone done any stability testing to show that they're that accurate?

There is no possibility to simply "disable that check" as it is driver-agnostic and it is not a problem of "better rounding". It's an important part of the process that makes sure the UI sends a frequency to the driver that is actually resolvable, and is critical when importing/pasting memories to indicate when the destination radio cannot resolve a frequency copied from another. Some drivers are literally only able to store frequencies as a multiple of the tuning step and thus cannot store frequencies that are not such a multiple.

Understood and accepted.
Apologies if my suggestions are too simplistic, I know nothing about what is under the hood. I appreciate your explanations on this.

What I am reporting is a problematic and "dead end" user interface issue.
Where the user is presented with an error message that states "Computer says NO!" (to paraphrase).

Allow me to elaborate on what I am seeing and my current personal (and perhaps peculiar) use case (in hope that it helps others) apologies if this is long winded.
I have (among many radios) a Retevis RT622 which is set up with a specific group of peculier frequencies for example "446.10312" and I am trying to set up some other radios to use this same existing set of frequencies. When I type them in or copy them over directly in CHIRP I get the above mentioned error.

Both the Quansheng- UV-K* and TIDRadio-H3 (and many others I believe) have the ability to "Air Copy" (unsure of the best term for this) where they scan nearby strong signals to find what is currently transmitting and allow you to save this to a memory. I can "Air Copy" the required frequencies to other radios and they seem to do some rounding (or perhaps just have errors) in most cases, and saving that for me, but that process is slow (although is a partial work around). It would seem that once I have done that I can not copy it to another Quansheng- UV-K* or TIDRadio-H3 or edit anything on the memory or even update the name assigned to the memory chanel slot. As they are still outside of the accepted parameters that CHIRP is expecting. So I am hitting the same brick wall trying to use CHIRP for this.

In the case of the Quansheng (egzumer Firmware 0.22) "446.10312" is definitely able to be typed into the device directly and to be saved (I am using the lowest step available in the egzumer Firmware 0.22 which is 0.01 kHz (10Hz)). However any time I take this back to CHIRP to do anything, every time I do anything on that memory slot I get the same harsh NO error message from CHIRP and no way to actually do what I can do in other (annoying and slow) ways.

• I understand your reluctance to add that ability to the egzumer driver but if the radio can do it surely the driver should match that. Is that not the point?

I know the Quansheng and custom Firmware may be a special case with all the modifications and being a moving target, so fully understand. I also expect that modified firmware will become significantly more popular going forward, also seeing the work on TIDRadio from nicsure.

Also to mention, the RT622 was only set up that way in CHIRP (I wonder if that was simply under a much older CHIRP version that failed to stop the user doing this in the past, or perhaps the RT622 is just too simplistic to care).

While I agree that the radio may not actually have such granularity of reception, if the radio can enter a specific granularity of frequency it still should be able to be entered and edited in CHIRP. Especially when CHIRP gets a specific frequency downloaded from a radio, and is clearly able to write that same frequency back.

I hope my ramblings make sense and happy to provide more details directly if that helps.

Please know that I am reporting my experiences here in order to be of help, I am not in any way complaining. I found this bug report while trying to solve my own problems of this nature, and thought it would be helpful to report my similar experiences. I will happily find and use a workaround to this and keep myself content (currently rounding the frequencies manually to the correct step and testing manually with some maths in Excel to help me, slow but it works). However I expect that I am not the only one seeing this and hope that the details I provide would in some way assist others and perhaps help work towards a solution or a better understanding.
I wish I knew enough about this to dive into the drivers myself and contribute helpful updates to the community.

Either way thank you for your time responding and your work on this. Much appreciated.

Allow me to elaborate on what I am seeing and my current personal (and perhaps peculiar) use case (in hope that it helps others) apologies if this is long winded.
I have (among many radios) a Retevis RT622 which is set up with a specific group of peculier frequencies for example "446.10312" and I am trying to set up some other radios to use this same existing set of frequencies. When I type them in or copy them over directly in CHIRP I get the above mentioned error.

Both the Quansheng- UV-K* and TIDRadio-H3 (and many others I believe) have the ability to "Air Copy" (unsure of the best term for this) where they scan nearby strong signals to find what is currently transmitting and allow you to save this to a memory. I can "Air Copy" the required frequencies to other radios and they seem to do some rounding (or perhaps just have errors) in most cases, and saving that for me, but that process is slow (although is a partial work around). It would seem that once I have done that I can not copy it to another Quansheng- UV-K* or TIDRadio-H3 or edit anything on the memory or even update the name assigned to the memory chanel slot. As they are still outside of the accepted parameters that CHIRP is expecting. So I am hitting the same brick wall trying to use CHIRP for this.

But to be clear, it is almost definitely the case that these scans are just giving you these odd-step frequencies because the radio is not accurate enough to actually land on the real frequency. As they're scanning by, it takes a second to lock onto a signal and it captures at a weird step and says "this is the frequency" even though it's way off. A higher-quality radio will scan at a reasonable step value (especially in UHF land) and report the frequency aligned to a reasonable step, which is the correct behavior. Point being, yes the radio can technically store frequencies with 10Hz resolution, but that's not really likely necessary as the things you're looking for are almost surely not really aligned there. I played with a UV-K5 yesterday afternoon on the service monitor with some artificially generated memories at 10Hz resolution and I'm almost positive that the radio can't tell the difference between two signals 100-200Hz apart. On transmit they're pretty unstable and wander all over the place as they warm up.

I get that you want to be able to type in things at arbitrary resolutions because the radio technically supports it, but chirp has step validation for a reason, and that's because most higher-quality radios are locked to reasonable steps such that you can't just consider any frequency string to be sane.

In the case of the Quansheng (egzumer Firmware 0.22) "446.10312" is definitely able to be typed into the device directly and to be saved (I am using the lowest step available in the egzumer Firmware 0.22 which is 0.01 kHz (10Hz)). However any time I take this back to CHIRP to do anything, every time I do anything on that memory slot I get the same harsh NO error message from CHIRP and no way to actually do what I can do in other (annoying and slow) ways.

Yes, if you try today's build I think you will find that to be different. The driver specified a finer resolution than the UI was willing to honor, which prevented the egzumer driver from actually being able to specify 10Hz-resolution frequencies. That should be fixed now. I still assert it's probably not what you really want to do, but alas.

• I understand your reluctance to add that ability to the egzumer driver but if the radio can do it surely the driver should match that. Is that not the point?

Whether or not the radio can actually do it is different from what the radio allows you to store in memory. There are some higher-quality radios that technically have resolution for 1Hz frequencies in memory, but if you put (i.e. if chirp allowed it) a 1-Hz-aligned frequency they would either round to the nearest step frequency or refuse to accept the memory. Just because the radio allows you to dial to it, doesn't mean it's stable enough to tune that differently from something 100Hz away (see above) or that it makes sense to do so :)

While I agree that the radio may not actually have such granularity of reception, if the radio can enter a specific granularity of frequency it still should be able to be entered and edited in CHIRP. Especially when CHIRP gets a specific frequency downloaded from a radio, and is clearly able to write that same frequency back.

Again, just because it can be stored this way in memory, doesn't mean all firmwares (i.e OEM) would tolerate a non-sensical misaligned frequency at runtime. But, as noted above, egzumer does, so I've fixed the UI limitation that prevented it. Please have a look at today's build and see how that works for you.