CHIRP

Sorry for the delays, life gets in the way. Encouraged by a fellow Ham I am back on the trail. If you have one of these radios and would like to help please contact me. Thanks!

Hi, I've got this radio and did some reverse engineering on it.
I've managed to get CHIRP partly work on it.
Now CHIRP can read & write raw_mem and get/set memory.

Here is my working in progrsss repo: https://github.com/FlyGoat/chirp-shx8800/

I'll try to send a patch to upstream after implementing get/set settings.

Please contact me in case you need any help.

Thanks.

Great work I will take a look.

I have just had a quick look as I was keen to get back to you.
My SenHaix 8800 radio
Software: ver 1.7.5
Hardware: ver 0.05
Silabs USB TTL interface. Used with many of my other radios.
CHIRP on Mac patched with your latest driver.

Quick Tests

Download from Radio
Switched off and on.
Clone from radio completes, radio returns to standard display, does not "reboot"

Upload
Edit entries
Upload - sometimes (sorry I know not much help!) CHIRP freezes and the radio keys up.
If the radio is power cycled between down and upload no error occurs. On a successful upload the radio reboots.
The channels 2,3 and 6 never appear to get overwritten. Which is very strange, as they remain at the default/radio reset values.

Reset radio
Uploaded from previous edited image. Radio reboots.
Again the channels 2,3 and 6 never appear to get overwritten.
The others up to 127 appear correct.

I hope this is of some help.
Regarding hq - I understand completely, I almost gave up. it seemed harder than writing the FT70 driver. I just don't have the energy/motivation to suffer its runes.
On a brighter note. Once again great work and I am sure there is someone who can help us submit it to hq!

Oops that's wired!
I'm with firmware v1.7.8（Chinese Version） and hardware v0.5 and it's 100% working fine to me and another tester.
I have a assumption that the original CPS software was using 64byte block to download and 32byte block to upload. In this driver I’m uploading with 64byte block.
Probably the older firmware have some issues with 64byte block. I'll try tomorrow.

Btw, do you have firmware updating package for English version firmware? I'm not sure if there are any difference between those versions.

I changed the block size to 32 and it now seems to download and upload all the entries. It still sometimes fails to upload and keys the TX or fails to get ack. Power cycle the radio and works OK
Excellent.

Another Test.
Tried the radio, but no transmit audio. Checked the mic gain setting which was 1, changed this to 3 uploaded and audio returned.
This was puzzling.
Did a full reset on the radio again no transmit audio. Downloaded using CHIRP, the mic gain setting was 1 changed to 3 and uploaded. Transmit audio returns.
Appears the Radio reset is not resetting the mic gain to a sensible level and this can only be changed from CHIRP/OEM software, not from the radio!

Strange. Now I reset the radio and TX audio is OK. CHIRP reports the level I have set. Odd. Clearly something got overwritten/reset, as earlier multiple radio resets did not bring the TX audio back.

Updated firmware to 1.7.8 - Thanks!
Loaded latest driver.
Reset radio
Uploaded image
No Audio
Change Mic gain from 3 to 2
Upload image
Audio returns
Change Mic gain from 2 to 3
Audio still fine.
Odd I will experiment further. Still some odd ack errors, switching off and on usually clears it fine. Cheers!

Btw I'm with ArchLinux. Could it be a OS specifed issue on serial behavior?

My Setup
MacBook Pro Catalina 10.15.7
Silabs USB chipset interface. I use many of these in other projects and have found them to be the most reliable.

Using your latest GitHub version.
TX Audio OK
Reset radio
TX Audio OK
Downloaded as new image, pasted in frequency entries
Uploaded
Audio still fine.
Perhaps old image or other change? Certainly seems fine now.
Occasional ack error, but always fine if power off first.
Excellent!

Thanks for your test!
I guess it's now ready for submission, what should I do next?

If you don't fancy messing with Mercurial - Which I understand(!) I would suggest you upload a radio image here, as that is needed for the submission and then ask on the CHIRP developer list for one of the experienced maintainers to submit it as a formal patch.
Failing that I would be prepared to submit the patch on your behalf, but this is not my first choice. Just let me know.
Thanks!

Nicolas

Sorry, I'm hospitalised since today due to elbow issue and won't have access to computer and my rig for a while...
If you mind to help could you please help me do that?

Image file had already uploaded.

https://chirp.danplanet.com/attachments/6135/SenHaiX_8800.img

I will ensure it is submitted.
Get well soon. All the best.

First version submitted.

Still waiting for a maintainer to allow me to submit a patch on the behalf of Jiaxun Yang.

Still waiting? Thanks!

Team, any way you guys can add this patch to chirp? :) it would certainly be appreciated! :D thank you!

James Long wrote:

Team, any way you guys can add this patch to chirp? :) it would certainly be appreciated! :D thank you!

I'd like to, can anyone points me what's next?

Thanks.

James Long wrote:

Team, any way you guys can add this patch to chirp? :) it would certainly be appreciated! :D thank you!

I'd like to, can anyone points me what's next?

Thanks.

Jiaxun Yang I am very happy to try and submit this again, please can you give me formal permission to do this?
Then I will ask the maintainers to review the submission again.
Thanks

Jiaxun Yang wrote:

James Long wrote:

Team, any way you guys can add this patch to chirp? :) it would certainly be appreciated! :D thank you!

I'd like to, can anyone points me what's next?

Thanks.

Nicolas Pike wrote:

Jiaxun Yang I am very happy to try and submit this again, please can you give me formal permission to do this?
Then I will ask the maintainers to review the submission again.
Thanks

Jiaxun Yang wrote:

James Long wrote:

Team, any way you guys can add this patch to chirp? :) it would certainly be appreciated! :D thank you!

I'd like to, can anyone points me what's next?

Thanks.

Should I write here?

Me, Jiaxun Yang, authorize Nicolas Pike on behalf of me to upstream my works on Radioddity gs-5b. That pieces of code was shared under GPLv3 which is exactly the same as CHIRP.

I lost access to my RIG as I moved abroad so I won't be able to follow the development but I'm very happy to see others continuing this work.

Jiaxun Yang Thank you. Now please can one of the CHIRP maintainers confirm to me that..

1. They are happy for me to submit this work on the behalf of Jiaxun Yang
2. Somebody will review the submission. Once I have confirmation of these points I will work on the submission Thanks! Will be great to see this as part of CHIRP.

Nicolas Pike wrote:

Jiaxun Yang Thank you. Now please can one of the CHIRP maintainers confirm to me that..

1. They are happy for me to submit this work on the behalf of Jiaxun Yang
2. Somebody will review the submission. Once I have confirmation of these points I will work on the submission Thanks! Will be great to see this as part of CHIRP.

Probably we should start a thread regarding this on mailing list?

Jiaxun Yang wrote:

James Long wrote:

Team, any way you guys can add this patch to chirp? :) it would certainly be appreciated! :D thank you!

I'd like to, can anyone points me what's next?

Thanks.

There was a conversation between Nicholas and Dan where Dan explained what he wanted changed to be accepted. It didn't seem to me like there was that much holding it up. Supply the requested changes and I'm sure that he would approve it.

Jim KC9HI

My principle concern was to address the issue Dan raised over copyright. Hopefully that has now been resolved.

Nicolas Pike wrote:

My principle concern was to address the issue Dan raised over copyright. Hopefully that has now been resolved.

Probably all you would have needed to do was to resubmit with both name sharing the copyright. I know I have submitted at least 2 drivers since this one where I shared the authorship with at least some parts of the driver's code. I just put both names with the copyright and also mentioned it in the commit message. I didn't have any issue getting them approved.

Jim KC9HI

Any news when this radio will be supported in Chirp?

Do you guys know where to download the latest SHX8800 Program Software? Mine is v1.5.1 and looks like it's out of date.

Greetings all,
just wondered how things were doing with this model, I has just ordered one from moonraker uk.

i now have radio.
1st thing i did was back it up via oem app.
then reset it.
did backup again.
time for chirp. loaded module, and read radio ok and saved.
copied freqs from another chirp file(gt3tp) table ok.
wrote to radio...configured the settings page of radio, re-wroted to radio ok.

radio responding ok at mo it seems, is there anything i need to check for you?

the bt apk app is odd. works fine on my older google pixel 4 andoid 11. but on my pixel 6, droid 12, its not scanning bluetooth to be able to connect. Senhiex Eng are now aware and going to look into it tomowrrow for me.

problem occured now, but till i get back to work, i cant confirm.
at home, different usb cable, unable to read radio in either chirp or cps. stops at a cirtain percent of download.
due to something in memory section i found, as emptying memory cells in chirp uploading and redownloading is ok.
I found that simplex chanels read in ok, but put 1 duplex channel in, it failed on reading the next line.
but im sure i had no probs at work yester like this unless i broke it.

cable wise, im not too sure but both are different. here at home it is known as a ch340. not sure of the work one. but one of em windows 10 dont like being a prlific of course fake. but im sure that occured here at home with the ch340...need to be at work to see what it is and to retest downloading uploading.

updating again, now at work, my cable here is proliffic, 3.2.0.0 win7x86. read and write radio ok no issues, with oem cps or chirrp.
so issue reading radio lies with the other cable known as ch340.

neil neil wrote:

updating again, now at work, my cable here is proliffic, 3.2.0.0 win7x86. read and write radio ok no issues, with oem cps or chirrp.
so issue reading radio lies with the other cable known as ch340.

I've seen cases where Windows installs the wrong driver when a WCH CH340/CH341 chip is present. So I no longer trust Windows to do the right thing when it comes to installing drivers for programming cables. I always manually download and install the latest driver from the FTDI, Silicon Labs and WCH websites followed by downloading, installing and selecting the old Prolific v3.2.0.0 driver (links to all 4 are on the "Miklor Drivers":https://www.miklor.com/COM/UV_Drivers.php page).

Jim KC9HI

going back to earlyer post, is it now time to include this model 8800 in the main chirp supported list?

neil neil wrote:

going back to earlyer post, is it now time to include this model 8800 in the main chirp supported list?

Just pending someone to submit a patch. I can’t do myself cuz I lost access to my RIG so I can’t address any review comment.
But I authorize anyone to use this code under GPLv2.

Wonder if our Dev Jim Unroe is able to do anything here with a patching process :-)

fyi. it does seem that the ch340/1 cable does not work with this radio.
i have now tested drivers and different pc's and os's and it fails to read radio correctly, erroring out. it does write to radio ok tho.

the pl ftdi type cable often faked, like mine, is working ok.

Hi Dave,

The copyright in that file should be mine, yep, and I can fix that.

It looks like your file is substantially similar to the ga510.py itself (unsurprisingly). Instead of duplicating all of that, we'd ideally get that to just be another subclass in the ga510 module itself (or in its own file, importing ga510 but that's probably not necessary). If you're able to do that work, that would be great. I could try to do it for you, but without the ability to test locally it would probably be frustrating for both of us. But, let me know.

Also, if you are willing, you could submit as a PR to the main repo where we take contributions:

https://github.com/kk7ds/chirp

I don't normally look for random files attached here and our process is to take submissions via github, but I just happened to look here.

Looks like this would be a welcome addition for a lot of folks, so thanks for doing the work!

Hi Dan, and thanks for your reply.

I'm admittedly unfamiliar with Github, so I'll use this as an excuse to get familiar.

Also, I can definitely work towards adding this to ga510.py. One issue that needs to be forward to the user in this is that Bluetooth on the GS-5B needs to be Off, or clonging will not start. I need to work on a message to that effect for the user if/when that error occurs.

Finally, my son also has a GS-5B and a number of Windows machines. We're hoping to test this new code with Chirp on both MacOS and Win 10 and 11.

This morning I have a working Python module for the Radioddity GS-5B, running in current ver. CHIRP next-20230128. This module combines the current version of ga510.py by Dan Smith for the Radioddity GA-5-10, with the memory map and other code snippets from senhaix_8800py ver. 3 by Jiaxun Yang, uploaded above on 11/07/2020.

Glad to hear it!

Because of the sheer number of changes made to the GA-510 module, the new module is stand-alone, named radioddity_gs5b.py, and is intended to also support similar radios Senhaix 8800, Signus XTR-5, and Anysecu AC-580.

Okay the earlier one I looked at still shared a very large amount of stuff with the ga510 driver. I'll keep an open mind until I see the latest one, but if it's still similar enough (like 50% or more) I'm going to want to merge them (which I might be able to help with). We have a big problem with people basically copying drivers to a new name, making a thousand tiny tweaks (some of which are just "gardening") and then the files look substantially different, even though they're not. When it comes to fixing a bug or doing maintenance, it's quite a burden to have this sort of duplication everywhere, and that usually falls on me personally which makes me ... twitchy :)

Of course I need to run a large number of tests before any release of the module. But, at least it's finally working.

There are a large number of tests in the tree, which will help, and have to be passing before it can be included anyway. As I mentioned above, putting a properly-named image file in tests/images will cause those tests to run against the driver.

Okay the earlier one I looked at still shared a very large amount of stuff with the ga510 driver. I'll keep an open mind until I see the latest one, but if it's still similar enough (like 50% or more) I'm going to want to merge them (which I might be able to help with)... When it comes to fixing a bug or doing maintenance, it's quite a burden to have this sort of duplication everywhere, and that usually falls on me personally which makes me ... twitchy :)

I can understand that. But, I do have a history of doing my best to stick around and deal with those messes. Glad to be into this, actually!

There are a large number of tests in the tree, which will help, and have to be passing before it can be included anyway. As I mentioned above, putting a properly-named image file in tests/images will cause those tests to run against the driver.

I sent an email to Radioddity Support yesterday for an updated memory map. A few items seem to be missing, particularly encryption, which is available from the Menu on the GS-5B. They've passed my request to the tech team for a response. Once I have that answer, I'll tidy things up and get the files uploaded.

Dan, I'm at a good stopping point in development while waiting to possibly get an updated memory map for the GS-5B from Radioddity. I joined Github as lunapiercook and attempted to upload the driver module and IMG file, but that requires push access for the Chirp repository. Can you arrange that? Please let me know if there's any action I need to take.

Dan, I'm ready to upload those files on Github, but I need push access to do so. Who do I contact to arrange this?

Dave Liske wrote in #note-60:

Dan, I'm ready to upload those files on Github, but I need push access to do so. Who do I contact to arrange this?

Sorry for chime in but think you should fork the github repository, push it in your own fork and send a pull request.

See: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/about-collaborative-development-models

Jiaxun Yang wrote in #note-61:

Sorry for chime in but think you should fork the github repository, push it in your own fork and send a pull request.

Being largely unfamiliar with Github until now, this is greatly appreciated. I've now done exactly that. Thanks!!

Does it support senhax 8600?

ryan tu wrote in #note-67:

Does it support senhax 8600?

I'll be finding that out. Please follow #10555 for updates.