CHIRP

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)

Hi Kevin,

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

Thanks,
Tony

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.

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...

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?

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.

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..

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?

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.

NFM is correct now.

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