CHIRP

Offer still stands, I will order a brand new one and have it delivered to the developer!

I will gladly send my radio in or buy a brand new one and have it shipped with programming cable software and all if we can get this radio added to chirp. I can be reached at gmckain1s@gmail.com or 573-421-5550.

Any chance this might get added? Due to it's IP67 rating (TH-8600WP version), this is a very popular radio in the side by side/atv/utv community.

I just got one of these radios, so I'll try to work on getting it added to CHIRP. It looks like the .icf files used by the factory programming software are a form of an ASCII HEX file that I should be able to use to help sort our the memory map. It appears to be have some similarities with the TH-9800. So between the existing TH-9800 code and doing a bunch of changes/saves of .icf files with the factory software, I think I should be able to sort it out when I get some time to play with it. I'll just need to do a few reads/writes to see if there's any offset and/or additional info going across the wire.

May be a few weeks before I can dedicate the time to sit down and get it all reversed. I'll post updates as I make progress.

Andy Knitt wrote in #note-6:

I just got one of these radios, so I'll try to work on getting it added to CHIRP. It looks like the .icf files used by the factory programming software are a form of an ASCII HEX file that I should be able to use to help sort our the memory map. It appears to be have some similarities with the TH-9800. So between the existing TH-9800 code and doing a bunch of changes/saves of .icf files with the factory software, I think I should be able to sort it out when I get some time to play with it. I'll just need to do a few reads/writes to see if there's any offset and/or additional info going across the wire.

May be a few weeks before I can dedicate the time to sit down and get it all reversed. I'll post updates as I make progress.

Andy, thank you. I have the TYT TH-8600 and the Radioddy and Retevis variants (all still factory) if you need help with testing.

Jim KC9HI

There is now a driver for this radio available for beta testing here:

https://github.com/aaknitt/chirp/tree/th8600

specifically:

https://github.com/aaknitt/chirp/blob/th8600/chirp/drivers/th8600.py

Once it's been more thoroughly tested I'll submit a pull request to get it into the main CHIRP codebase.

Andy can you attach the file here? If so, people can use LoadingTestModules to test it and give you feedback. Once you do, you might want to send a mail to the mailing list asking for testers as that's a much wider net than this bug with 6 watchers. Just attach the module here and point people at this ticket.

Users. Lots of people there compared to dev, and the dev people already know you're looking for testers :)

That's strange. I don't think 0x114A is in a range that should be touched or even looked at.

The first issue is that when using the "Load module from issue..." feature of CHIRP-next, that is a popup Security Risk notification (Screen capture attached). The workaround for now is to simply click the [OK] button to Proceed anyway?

Jim, this is just CHIRP warning the user that the file it's about to load was uploaded to the issue tracker from an unknown author. That's just because Andy isn't in the developer group here. It does that to help warn people against being tricked into loading and running code from someone just because they attach it here.

Andy Knitt wrote in #note-13:

That's strange. I don't think 0x114A is in a range that should be touched or even looked at.

I'm not saying that it is a problem. Just pointing out the unexpected change. Most radios don't do this, but I've seen the Radtel RT-470 type radios have substantial changes in memory as its settings are updated. I wish I had my serial monitor on to capture what was actually sent to the radio. I'll see if I can test that out later today.

Thanks again for your work on this driver.

Jim

I could be totally wrong, but I wonder if it may be related to the baud rate. The TYT .icf files seem to indicate a baud rate of 34800 and I've gotten that rate to work once or twice with the factory software but usually it only works at 9600. I haven't yet sorted out what's going on there so I've left the CHIRP driver at 9600 for now. I'm away from the radio for another day before I can play with it more.

Well I was wrong about the baud rate guess, but in any case I've been able to reproduce this same 0x114A behavior using the factory programming software so I'm going to assume for now that it's not a problem.

Thanks Jim. I discovered an "off by one" bug earlier tonight and posted an updated .py file to this issue and to my github just an hour or so ago that I think may resolve some or much of what you found. I'll digest all of this further to try to sort out what may still be remaining bugs, but if you can retry with the latest I'd appreciate it.

Andy Knitt wrote in #note-20:

Thanks Jim. I discovered an "off by one" bug earlier tonight and posted an updated .py file to this issue and to my github just an hour or so ago that I think may resolve some or much of what you found. I'll digest all of this further to try to sort out what may still be remaining bugs, but if you can retry with the latest I'd appreciate it.

Yeah. I saw that that a post that was made during the time I was composing mine had attached a new version. It was too late for me to tryout. Hopefully I can get a chance to take it for a spin later today. Thanks.

Andy Knitt wrote in #note-20:

Thanks Jim. I discovered an "off by one" bug earlier tonight and posted an updated .py file to this issue and to my github just an hour or so ago that I think may resolve some or much of what you found. I'll digest all of this further to try to sort out what may still be remaining bugs, but if you can retry with the latest I'd appreciate it.

The 2023-08-07 test driver does indeed take care of most of the issues that I mentioned yesterday.

Andy, here is what I have been able to test today.

When editing my 'factory' image, memories 3, 4 & 5 are still picking up 5TONE, 2TONE, 5TONE respectively for the Optional Signaling setting. It would seem that when an empty channel is programmed, CHIRP isn't setting the memory to defaults first. Any stray data in the memory is being picked up.

I made a mistake yesterday thinking that VHF frequencies were set to displaying names and UHF channels were frequency. I now know it is actually new channels programmed with CHIRP or existing channels edited by CHIRP with no names always display channel numbers. It is channels that were programmed at the factory of by the TYT CPS that will show the frequency.

This is because whenever a memory is edited with CHIRP, "display" is always set to "True" which tells the radio to display names. When there is no name programmed in the memory, the radio defaults to displaying the channel number instead.

I was trying to determine what was causing this to happen but ran out of time for today. I may try to look at it again tomorrow.

Jim Unroe wrote in #note-23:

Andy, here is what I have been able to test today.

When editing my 'factory' image, memories 3, 4 & 5 are still picking up 5TONE, 2TONE, 5TONE respectively for the Optional Signaling setting. It would seem that when an empty channel is programmed, CHIRP isn't setting the memory to defaults first. Any stray data in the memory is being picked up.

I made a mistake yesterday thinking that VHF frequencies were set to displaying names and UHF channels were frequency. I now know it is actually new channels programmed with CHIRP or existing channels edited by CHIRP with no names always display channel numbers. It is channels that were programmed at the factory of by the TYT CPS that will show the frequency.

This is because whenever a memory is edited with CHIRP, "display" is always set to "True" which tells the radio to display names. When there is no name programmed in the memory, the radio defaults to displaying the channel number instead.

I was trying to determine what was causing this to happen but ran out of time for today. I may try to look at it again tomorrow.

Jim,

I found and fixed a bug related to Name vs. Frequency display.

I'm not sure I understand the issue you're seeing with Optional Signaling though. I'm not seeing anything except "OFF" in CHIRP after doing a factory reset and downloading. Even after editing, uploading, and re-downloading I'm still seeing "OFF" for all channels that I've added.

Can you describe the exact sequence (from a factory reset) that reproduces the bad behavior?

Andy Knitt wrote in #note-24:

bug fixes for RX checksum, memory name/frequency auto-select

Andy, thank you for the update. I can confirm that the memory name/frequency auto-select has been fixed.

I did get a chance to run through the Basic Settings. Programmed each at their highest and lowest values and they all matched up with the TYT CPS.

Andy Knitt wrote in #note-24:

bug fixes for RX checksum, memory name/frequency auto-select

Just downloaded driver. What bugs remain? Need any help troubleshooting, testing or debugging? Will try to load my 200 channel CHIRP file, see how it goes...

Andy Knitt wrote in #note-29:

Jim please try this. I think this may address the issue you identified. If not, please let me know.

Sorry for the delay on working on this. I had the radio in my boat the last half of the summer but have it out for the winter now so can hopefully get this finished up.

Issues (see note-19 above)

1. Resolved
2. Not an issue. I had apparently copied ch 0 to ch 1 at the radio (didn't know I could do that)
3. Still an issue
4. Resolved
5. Resolved
6. Resolved
7. Resolved
8. Resolved

Jim Unroe wrote in #note-32:

I tried to give the module a try but immediately after the download completed, a message popped up proclaiming that there was a syntax error. I download the file, addressed the syntax errors and then loaded the file locally. I agree that you have taken care of bullet point number 3. Thanks.

Jim, can you provide any more detail about the syntax error and the fix that you applied to address it? I haven't run into that here.

Ok thanks Jim. Strange that I wasn't seeing that syntax error, and that it was present in all of the prior versions in this issue. Were you using a different OS or environment this time? In any case, I made those corrections and submitted a PR (824) to get this driver added.

What I did this time was to use the new "Load module from issue..." feature of CHIRP-next. I most likely downloaded the file and loaded it locally for the earlier testing. What I could have done was to add it to my build system to see what the test suite says, but I figured that you would be doing that. ;)

Andy, the syntax error came from a fix in CHIRP's parser that wasn't catching that error before. I found it while doing some maintenance on the parser and I fixed all the code in the tree. So you're probably just running older code that is running the buggy parser.

I did a test with this today and it worked without any issues. I was able to download from the radio, add and delete some channels and then upload to the radio. Thank you for working on this.

Finally tested this driver today. Working mostly okay on my unlocked 8600. A few issues.

1. Need to change max channel length from 6 to 16. The display can show 8 characters at once, but you can program up to 16 characters in the factory software. If over 8, the display will scroll the label. I verified all US keyboard characters were programmable and displayable from factory SW. (The full 16-char long channels show up in Chirp if I read from the radio. If immediately re-write to radio, only 8 get loaded into radio.)

2. When copy/pasting channels from another radio plan, power settings do not transfer into 8600 page (they all go Low). Same for pasting from 8600 to another radio file, power is ignored.

3. When reading/writing, the radio "cloning" display increments only up to channel 104, but all 200 channels DO get read and written. Maybe put a note on driver intro screen warning about this.

4. Factory SW allows two 16-char lines for startup message as well. (Although that setting and others in factory SW's Basic tab don't work for me!) Any plans to add this?

5. CHIRP driver reads memories much slower than factory software, so room to speed up. But, fast enough to leave as-is, it's not excruciatingly slow.

(Just an FYI, driver throws an error when (accidentally) loaded into old chirp. No big deal or any need to fix it.)

-g

I got this radio a couple weeks ago and have been using the beta module to pull and push data from/to the radio quite a bit. Thanks, Andy, for your work up to this point. Even as a beta module this makes my life a lot easier.

I can't find any problems beyond what Gary P noted; in fact, even the changes to max channel length and power settings when copy/pasting individual memories is a nice-to-have in my book.

Is there any chance this can be graduated to mainline support instead of the beta? This is a fairly popular radio, and full CHIRP support would be pretty neat.