Project

General

Profile

Actions

Bug #11365

open

Quansheng Band Tuning Step incorrect (Stock firmware)

Added by Al Simons 26 days ago. Updated 26 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
05/30/2024
Due date:
% Done:

0%

Estimated time:
Chirp Version:
next
Model affected:
Quansheng K5(8)
Platform:
Windows
I read the instructions above:
Yes

Description

Using stock firmware and CHIRP 20240524.

When I try to set a Tuning Step for band F3(135M-174M)A, the next higher step value is loaded into the radio (except for 8.33).

For instance, if I try to load a 1kHz step, a 2.5kHz tuning step is loaded. It feels like an off-by-1 bug indexing into the list of
possible steps, but I can't explain the 8.33, which should have taken an IndexError. Perhaps the try/except substituted the highest
value, 25.0?

I have not tried other bands, but I assume they all use common code.

Here is a table of steps, all numbers are kHz.

Asked -> Loaded
1 -> 2.5
2.5 -> 5.0
5.0 -> 6.25
6.25 -> 10.0
10.0 -> 12.5
12.5 -> 25.0
25.0 -> 8.33
8.33 -> 25.0

Actions #1

Updated by Al Simons 26 days ago

Drat. Sorry for misspelling Quansheng in the title.

Actions #2

Updated by Alexandre J. Raymond 26 days ago

  • Subject changed from Quensheng Band Tuning Step incorrect (Stock firmware) to Quansheng Band Tuning Step incorrect (Stock firmware)

Hi Al,

I looked at the driver (uvk5.py), and the reverse engineering documentation (https://github.com/sq5bpf/uvk5-reverse-engineering/blob/main/UVK5_memory_map.ods).

I suspect the issue comes from the steps defined by the driver:

_steps = [1.0, 2.5, 5.0, 6.25, 10.0, 12.5, 25.0, 8.33]

versus what the reverse engineering documentation states:

000: 2.5kHz
001: 5kHz
010: 6.25kHz
011: 10kHz
100: 12.5kHz
101: 25kHz
110: 8.33kHz

This suggests that the 1kHz step is not supported by the radio, and CHIRP should not propose it. This would explain the off-by-one behavior you are seeing.

Jacek Lipkowski SQ5BPF would you agree?

Actions #3

Updated by Al Simons 26 days ago

Thanks, Alexandre.  I agree that the mismatch appears to account for
what I'm seeing.
73,
-Al WA1TYB

On 5/31/2024 07:37, Alexandre J. Raymond wrote:

Actions

Also available in: Atom PDF