Project

General

Profile

Actions

New Model #10880

open

Wouxun KG-Q336/332

Added by Kevin S over 1 year ago. Updated 17 days ago.

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

50%

Estimated time:
Equipment Loan/Gift Offered:
No
I read the instructions above:
Yes

Description

Hello.

On the request of Mel I've made this request for the Q336 and Q332, as i suspect the 332 has the same memory mapping as the stock software is for the 332.

Mel's beta for the Q10H allows me to download, read, edit, and upload frequencies to the radio. However I can't access the settings because of a NoneType object error (see attached debug log)

I can't lend out my radio but I'm more than happy to be active in the development, uploading logs and whatever else I could provide to be of help.


Files

chirp_debug-vg2ax0gl.txt (592 KB) chirp_debug-vg2ax0gl.txt Kevin S, 10/03/2023 08:02 AM
Wouxun_KG-Q10H_20231011.img (32.2 KB) Wouxun_KG-Q10H_20231011.img Kevin S, 10/11/2023 01:47 PM
Wouxun_KG-Q332_Q336 channels only_20250223.img (32.2 KB) Wouxun_KG-Q332_Q336 channels only_20250223.img Nikos SY1EBE, 02/22/2025 10:31 PM
Wouxun_KG-Q332_Q336 channels only_20250316.img (32.2 KB) Wouxun_KG-Q332_Q336 channels only_20250316.img Mathieu De Groote, 03/16/2025 03:58 PM
Screenshot 2025-03-16 235707.png (64.5 KB) Screenshot 2025-03-16 235707.png Mathieu De Groote, 03/16/2025 03:58 PM
kgq10h with S65 and Q33x 2025mar16.py (222 KB) kgq10h with S65 and Q33x 2025mar16.py Fixes NFM/FM decoding for Q332/336 Mel Terechenok, 03/16/2025 05:17 PM

Related issues 1 (0 open1 closed)

Has duplicate New Model #11547: Wouxun KGQ-332Rejected09/17/2024

Actions
Actions #1

Updated by Kevin S over 1 year ago

Specifically "SCANMODE_LIST[_settings. IndexError: list index out of range*"

Kevin S wrote:

Mel's beta for the Q10H allows me to download, read, edit, and upload frequencies to the radio. However I can't access the settings because of a NoneType object error (see attached debug log)

Actions #2

Updated by Tony Fuller over 1 year ago

Hi Kevin,

If you attach the img file that CHIRP downloaded, others can take a look without the radio.

Thanks,
Tony

Actions #3

Updated by Kevin S over 1 year ago

Tony Fuller wrote in #note-2:

Hi Kevin,

If you attach the img file that CHIRP downloaded, others can take a look without the radio.

Thanks,
Tony

Noted, and attached

Actions #4

Updated by Mel Terechenok over 1 year ago · Edited

The image posted clearly shows many issues with using the Q10H driver on the 336/332 radio.

First - the Scan Group name has an invalid character in a scan name Åkeri- the Å is not a valid character in Chirp base ASCII character set being used by the driver. Change it to Akeri and it will be ok. I tried using Åkeri in the Top Message and Area Message on the Q10H and the radio does not display it correctly - either using Chinese Characters or displaying a default value instead.

But beyond that - I don't believe the 332 has the same memory map for settings as the Q10H.
I found 3 settings (stopped looking after that) that have values outside the expected ranges of the Q10H settings expected at the location (meaning they are likely values for different settings). Scanmode, PowerOnMessage and DTMF Sidetone (likely many more).

As I mentioned before - the driver will need to be updated with a memory map for the specific 336/332 radio for Chirp to ever work with it.

Unless/until someone determines / provides a map the 336/332 will not be usable with Chirp.

Because of this, I have disabled the Q10H/Q10G driver from allowing access to the Q336/Q332 radio memories to protect the users from potentially corrupting their radio memory.

Actions #5

Updated by Mikko Nahkola about 2 months ago

Got another of these here, a Q336. Can't send it very far but would be nice to get it supported, so if there's anything (non-destructive) I could do locally here, I'd be willing to try to help.

Also kind of funny how even the "native" Wouxun software doesn't differentiate between the -2 and -6 versions much...

Actions #6

Updated by Mel Terechenok about 1 month ago · Edited

  • File kgq10h with S65 and Q33x 2025feb22.py added
  • % Done changed from 0 to 50
  • I read the instructions above set to Yes

Here is a test driver for the Q332/Q336 that provides access to the channels only - No settings other than oem info

How to load test drivers

Actions #7

Updated by Mel Terechenok about 1 month ago

  • File kgq10h with S65 and Q33x 2025feb23.py added

Updated to resolve Beta1 error on upload

Actions #8

Updated by Mel Terechenok about 1 month ago

  • File deleted (kgq10h with S65 and Q33x 2025feb22.py)
Actions #9

Updated by Nikos SY1EBE about 1 month ago

Mel Terechenok wrote in #note-6:

Here is a test driver for the Q332/Q336 that provides access to the channels only - No settings other than oem info

How to load test drivers

img read with kgq10h with S65 and Q33x 2025feb23.py 20250223

Actions #10

Updated by Mikko Nahkola about 1 month ago

Tested with my Q336.

  • Frequencies are correct.
  • Channel names are correct.
  • Offsets seem to be correct. One channel's "duplex: off" seems to be missing though, compared to what I thought was my current printout from Wouxun's own software.
  • TSQL settings are correct.
  • Power settings per channel are correct (L/M/H)
  • Modulations are NOT correct, NFM channels on the radio show as regular FM.

I think I may need to construct a more suitable test dataset of the channels, for better coverage. Any suggestions?

Actions #11

Updated by Mathieu De Groote about 1 month ago

I have a Wouxun KG-Q332 and while the radio itself is fine, the original wouxun programming software for this model is a load of cr*p.

So far I encountered these problems:

  • Not possible to insert a comma. Trying with a dot is causing the value to change to '999,99750'.
  • Not possible to write frequencies within the airband (108-136Mhz) range, even though you can add them in the radio itself and read them.
  • CTC/DCS values from the dropdown list get multiplied by 10 when you select them. '67.0' becomes '670' and so on.

I contacted wouxun support already and for now they seem to fail to understand the problems.

If Chirp could fully support this model it would be a godsend for me, so if I can help/test in any way, please let me know.

Actions #12

Updated by Nikos SY1EBE about 1 month ago

Mathieu De Groote wrote in #note-11:

I have a Wouxun KG-Q332 and while the radio itself is fine, the original wouxun programming software for this model is a load of cr*p.

So far I encountered these problems:

  • Not possible to insert a comma. Trying with a dot is causing the value to change to '999,99750'.
  • Not possible to write frequencies within the airband (108-136Mhz) range, even though you can add them in the radio itself and read them.
  • CTC/DCS values from the dropdown list get multiplied by 10 when you select them. '67.0' becomes '670' and so on.

I contacted wouxun support already and for now they seem to fail to understand the problems.

If Chirp could fully support this model it would be a godsend for me, so if I can help/test in any way, please let me know.

Watch my video here to solve this problem..
https://www.youtube.com/watch?v=OaEDSL8vUu8

I have reported this to Wouxun from 19 January but..

Actions #13

Updated by Nikos SY1EBE 22 days ago

Mikko Nahkola wrote in #note-10:

Tested with my Q336.

  • Frequencies are correct.
  • Channel names are correct.
  • Offsets seem to be correct. One channel's "duplex: off" seems to be missing though, compared to what I thought was my current printout from Wouxun's own software.
  • TSQL settings are correct.
  • Power settings per channel are correct (L/M/H)
  • Modulations are NOT correct, NFM channels on the radio show as regular FM.

Run a quick test in Q332. I agree with the above findings. Modulation is FM in all.
Duplex values were OK for me

What else can we do?

Actions #14

Updated by Mel Terechenok 17 days ago

attach an image read with the test driver from your radio where there are all the different modulations programmed.

with the image, please specify which channel has which modulation. The modulations are determined based on what the Q10H/Q10G use, so apparently the 332/336 use different encoding.

Actions #15

Updated by Mel Terechenok 17 days ago

  • Assignee set to Mel Terechenok

Updated by Mathieu De Groote 17 days ago

Mel Terechenok wrote in #note-14:

attach an image read with the test driver from your radio where there are all the different modulations programmed.

with the image, please specify which channel has which modulation. The modulations are determined based on what the Q10H/Q10G use, so apparently the 332/336 use different encoding.

I hope this helps.

Ch1: FM wide
Ch2: FM narrow
Ch3: AM wide
Ch4: AM narrow

Full settings in screenshot.

Actions #17

Updated by Mel Terechenok 17 days ago · Edited

This should fix the NFM vs FM issue. Please give it a try.
It doesn't change anything for NAM vs AM.

Does the radio actually display a difference between NAM and AM?
The Q10H does not ever show NAM. Also the firmware does not allow you to select Narrow directly from the radio menu when in AM mode.
The Q10H Wouxun CPS allows selection of the Narrow vs Wide for AM, but the radio does not seem to do anything with it. Selection of Narrow/Wide for AM may just be a CPS quirk that doesn't change radio behavior.

Actions #18

Updated by Mel Terechenok 17 days ago

  • File deleted (kgq10h with S65 and Q33x 2025feb23.py)
Actions #19

Updated by Mathieu De Groote 17 days ago

NFM is correct now.

Regarding NAM: you are right, you can't select narrow on the radio for an AM channel.

Actions

Also available in: Atom PDF