CHIRP

To kick things off here, I attempted to download from radio using all Wouxun models, and the only one that successfully downloaded was for the KG-UV9D Plus. CHIRP appears to have downloaded all of the memories correctly, however the Settings tab is blank, and therefore Groups cannot be accessed either. It appears that Settings for the KG-UV9D MATE radio is able to be accessed and programmed by CHIRP, but not the UV9PX.

What would be helpful information in beginning to sort this new radio out? Thanks.

Jim Unroe wrote:

Usually when the Settings tabs don't display any settings, there is one or more setting with a value that is out-of-range. If you would save the tab that was created to a native CHIRP Radio Images (*.img) file and attach it to this issue, someone could take a look at it to see which setting(s) it might be.

Jim KC9HI

Thank for jumping in here Jim and thanks Rory for starting this process.

Jim, I'm not sure if you are an active developer here, but I've been in contact with Mel T. (from several Facebook forums), who is a developer, and whom has agreed to work on new CHIRP modules for the Wouxun UV9G PRO, UV9GX and UV9PX. I'm working on sending Mel a list of requested tweaks, fixes and new features for these new models (based on the existing UV9D Plus version) now and will be sending him some radios to test with also. So as to not have any duplicated work, I'd love to have you two coordinate any development work. Hopefully Mel will jump in here soon (after I send the new data over). If there's any way I can help facilitate that coordination, don't hesitate to ask. :)

I think the GMRS and HAM communities would love to finally have working modules for all of these new radios. :)

Cheers and thanks!

-Mark from BetterSafeRadio

attach it to this issue, someone could take a look at it to see which setting(s) it might be.

There are several out-of-bounds settings in this image.

I'll list them here:

• Time Out Alarm value is set to "10" which would correspond to 10s but the driver only defines valid values up to 9s

  • see TOA_LIST = ["Off"] + ["%ds" % t for t in range(1, 10)]

• Brightness level is set to "6" which is invalid as the driver only defines valid values up to 5

  • see LIST_1_5 = ["%s" % x for x in range(1, 6)]

• PF3 Key function value is set to "6" but valid index values are 0=OFF,1=Call ID,2=R-ALARM,3=SOS,4=SF-TX

  • see PF3KEY_LIST = ["OFF", "Call ID", "R-ALARM", "SOS", "SF-TX"]

Hope that helps,
Tony

I have started looking at the 9d plus driver and have fixes for the TOA and ABR_LVL.

I will need to look at the PF3 setting to what is wrong.
I plan to post a beta version of a 9Gx driver and then make updates as needed as I learn more about the 9Gx new features.

Stay tuned.

I plan a 9Px Driver release - which should also work for the 9Gx.

Mel Terechenok wrote:

I plan a 9Px Driver release - which should also work for the 9Gx.

Thanks for your work on this Mel. I'm just an enthusiastic user (not a programmer), but I'm happy to do any testing if needed.

Work has begun on the 9PX driver. It is coming along nicely. Still working a few things out, but it is looking good.

Rory Banks wrote in #note-13:

After some more tinkering, it seems like when I select Upload To Radio in CHRIP, somehow what's being uploaded is the most recent memory group from the actual KG=UV9PX R1.00 (211207) app (attached). I'm stumped.

I was able to add and modify channels. I also changed one of the scan group start and ends. Everything worked great for me.

Rory -

I can't duplicate what you are describing. I was able to import your csv and successfully write to the radio.
I can confirm the image you posted was the factory reset image. I have seen this happen when a value you have written to the radio is out of the acceptable limits. I can force that to happen if I try and set the Tx/Rx limits out of range the radio will support, but I put in limits in Chirp UI so that should not occur. If you can duplicate the problem and post the .img file that you tried to upload when the reset occurs I can try and debug further to narrow down what is causing the radio to reset after a write to it.

Rory Banks wrote in #note-13:

After some more tinkering, it seems like when I select Upload To Radio in CHRIP, somehow what's being uploaded is the most recent memory group from the actual KG=UV9PX R1.00 (211207) app (attached). I'm stumped.

Happy to help with the KG-UV9PX progress. I just tried module version " kguv9px b1.1.py ", and I get a blank Settings tab when downloading from the radio

Steps to reproduce:

1. Create a new image using CPS R1.00(21120)
2. Write to radio. Power cycle radio.
3. Chirp Download From Radio, Model KG-UV9PX developer module.

Let me know what you need.

Correction: CPS R1.00(211207)

I used your procedure, I did not get a blank Settings Tab - it showed up just fine.
However, the Memories tab showed no programmed channels which I will have to look into.
If you can post the .kg file you wrote to the radio as well as the .img file that you get after reading from the radio, as well as your debug.log file from %APPDATA%\CHIRP I can start debugging.
The CPS does some strange things so reports like this help me understand the silly things it is doing. Thanks!!!

Looks like in the function _admin_tab there is a call to RadioSettingValueString (is that from a chirp library?) that is tripping over the presence of the ¦ character. That is the broken vertical bar char, not pipe . Kinda weird.

I think I know what is causing this. On my radio, my Custom Sub-Receiver Message is actually blank! When I push the TDR button, I don't have a value there. Now, how did this happen? Well, before I knew about this module you were working on, I was using the quasi-workable but buggy KG-UV9D Plus module. I'll bet you it wrote a blank in that struct on the radio. I don't know, but sounds good!

Fix confirmed. By setting a value for Browser oemmodel , I can get the Settings tab to load. So, if for some reason, that value is blank on the radio, Chirp errors.

I just loaded the module and programmed my radio and don't seem to have any issues yet.

Tony Politi wrote in #note-24:

I just loaded the module and programmed my radio and don't seem to have any issues yet.

I Just found one bug. If Receiver A Settings>Channel is set to a channel with no memory after the programming is complete a ghost channel remains on the radio on that channel. When I scroll thru the channels afterwards there is an unprogrammed channel that I have to scroll thru even though no info is in the memory setting for that channel.
This also applies to Receiver B Settings>Channel

Not a big deal I just set them to my favorite channels so when the radio boots up at those favorite channels.

Tony Politi wrote in #note-25:

I Just found one bug. If Receiver A Settings>Channel is set to a channel with no memory after the programming is complete a ghost channel remains on the radio on that channel.

Thanks Tony! I also found that issue. I am working to figure out a way fix that.

Mel Terechenok wrote in #note-26:

Thanks Tony! I also found that issue. I am working to figure out a way fix that.

The channel number lights up when receiving a transmission I don't remember it doing this before but I like that it does.

For the start up option it has battery or bitmap(disabled). I would sure love to be able to upload my own bitmap(graphic) instead of the battery.

The transmit limits are set outside what the actual limits are. I set transmit down to 108 and still get FreqOver when transmitting on 108.000. This could lead to confusion and future bug reports.

It appears the bug that drops the 8 character has been fixed I thought it was not but I just had to go back in and add the character that the older version had previously removed.

I have to say Thank You, Thank You, Thank You. Having only a Mac at home I can now do full programming without having to drive to my office. Additionally the god awful Wouxon software was going to give me an aneurysm. Your efforts are much appreciated. I donated to CHIRP last night. Does this benefit you as well? If not I would like to reward your efforts.

It looks like we might be able to close this ticket?