CHIRP

Can you attach your debug log please? Help->Show Debug Log.

Hi Lynda,

Thanks for the logs.

These actually don't share code (although they probably should) so it will be three separate efforts. I can take a crack at them in the blind, but I just want to make sure: you can test all three of these right?

This can be reproduced if you enable developer mode, load one of the Wouxun images in the repo, and then attempt to upload to a custom serial port named loop:///dev/null.

Only the first bit of it. After it gets past the first attempt to identify the radio, there's a bunch of code that you'll never get to that needs conversion as well. I've been writing unit tests effectively simulating these radios to exercise all the code without an actual radio:

https://github.com/kk7ds/chirp/blob/master/tests/unit/test_kguv8d.py

I was just about to post that the KGUV8DPlus is current loaned out to a friend, and I dont have immediate access to the radio.
however, I do have a few KGUV8E's around I can test the new codes with. I'll post again with my results soon.

Bear with me here. But Im not sure where I am putting the kguv8e,py, as Im not familiar with the structure of this new program.
Is it hidden somewhere or stored in an archive file somewhere ?

$ pwd
/Applications/CHIRP-next.app
$ find . -name "kguv8e.py"
$

You don't need to put it anywhere specific. Enable Developer mode in chirp via the Help menu. Then restart chirp and you will have a new File->Load Module menu entry. From there, you can just select the .py file, wherever you saved it. It will be loaded into chirp for just that session to test.

Dan Smith wrote in #note-15:

You don't need to put it anywhere specific. Enable Developer mode in chirp via the Help menu. Then restart chirp and you will have a new File->Load Module menu entry. From there, you can just select the .py file, wherever you saved it. It will be loaded into chirp for just that session to test.

Got it, kinda sorta figured it out too. Thanks for confirming this is the right way of doing this. Thats actually a really nice feature not having the fiddle with the file structure while debugging!

Another thing I, going to try in the future is to enter to actually input unicode, specificity in chinese for channel names.

Since the default radio config has a few chinese characters in it, which suggest it might be able to render unicode characters outside of the standard ascii set. Original CHiRP naturally didnt like those entries.

Anyways of course you can put me down on as a tester for this radio, my callsign is W5EGL. As for the 8DPLus. Probably sometimes next week? I might be able to get my friend run the test file over the phone. So it might still be a good idea to post it for testing here ahead of time. Especially assuming the resolution is the same for that radio too.

AS for the UV8T, I no longer have this radio, and the last one was sold. From what I know Uv8E is almost identical, just without umm certain restrictions? For those in the know of course.

Oh yea, you should be able to put me down as a tester for the 8DPlus , KG-968, and KG-UVN1 (if it ever would come to past). I have access to a number of these radios as I am a small fry direct dealer of Wouxun radios.

Sorry for the post spam. the KG-958's and KG-UVN1 , I have two of each of these available for loans out if someone want to develop drivers for them.

Honestly the drivers for all these radios should share a ton of code, but they don't. I didn't write them, and maintaining them with all this copied (but tweaked) code is a bit failure-prone (as you noticed).

I'll put you down as the tester for the 8E and the other two will remain as "prospective" until someone can confirm, just to be on the safe side.

As far as unicode, the character set in the radio is definitely not capable of full unicode, as the memory reserved for the characters is only 8-bits wide. Most of the radios that support "foreign" glyphs do so by way of multiple character sets that fit 8-bits wide with a switch between them. In order to make that work, a developer that can understand the alternate glyphs has to write code to support it, which hasn't happened (for any of these).

Thanks for your help!