Bug #11584
closedRetevis RT98v 1.03 Unsupported by CHIRP
100%
Description
When I tried to read a RT98 by chirp I got hit with an error that the hardware version I have is unsupported, is there anything I can do to help make this newer variant of the RT98 work?
I know there are special plugins to read the software off of chirp and all that, but I don't have any of that handy, but I have a programming cable, the radio, and chirp, so I am happy to help get the newer variant (called 1.03) supported if I can!
Files
Updated by Dan Smith about 2 months ago
Per the IssueInstructions you indicated you read, we need a debug log. Please read How_To_Report_Issues and update this bug using Help->Report or update a bug after attempting the download.
Updated by Bryant L about 2 months ago
- File chirp_debug-sbqpejph.txt chirp_debug-sbqpejph.txt added
Apologies, please see attached, I lost the original file.
Updated by Dan Smith about 2 months ago
- File retevis_rt98.py retevis_rt98.py added
Please try the attached module with LoadingTestModules and attach the image and debug log you get to this bug using Radio->Report or update a bug. Please do not use this to upload until we have a chance to look at those files.
Updated by Bryant L about 2 months ago
- File Retevis_RT98_20241003.img Retevis_RT98_20241003.img added
- File chirp_debug-f2ds5ve5.txt chirp_debug-f2ds5ve5.txt added
Here you go, I will avoid the temptation of bricking my radio :)
Updated by Dan Smith about 2 months ago
Thanks, I'll have a look after work. Hopefully @Jim Unroe can have a look as well.
We won't be able to tell you it's safe, but we will be able to say "meh looks just like v1.0 so probably low risk". If you can look through CHIRP's rendering of your radio's contents and compare it to the actual radio, that'd be helpful as well.
Updated by Dan Smith about 2 months ago
Looks to me like everything is in order. No out-of-range settings or complaints from the driver. @Jim Unroe might have thoughts, but if it were my radio I'd go for it. If you do, please report your success and if it seems okay I'll add this to the next build.
Updated by Jim Unroe about 2 months ago
Dan Smith wrote in #note-6:
Looks to me like everything is in order. No out-of-range settings or complaints from the driver. @Jim Unroe might have thoughts, but if it were my radio I'd go for it. If you do, please report your success and if it seems okay I'll add this to the next build.
I was going to take a look at it but forgot. What I have been having people do lately is to run through the physical radio's menus still match CHIRP's selection. In other words, check to see if any selections have been removed, changed or added. This is usually what I see with Radtel, Talk Pod and similar radios when the firmware has been upgraded. Only someone with the physical radio can check this. Dan and I won't know from looking at the 'image'.
Updated by Dan Smith about 2 months ago
Updated by Bryant L about 2 months ago
- File chirp_debug-3j9_pv8k.zip chirp_debug-3j9_pv8k.zip added
I have tested the following without issues:
- deleting all my channels and pasting in new ones
- pasting in new channels
- changing power on msg - small bug (see below)
- changing STE type
- changing STE frequency (which one is the right one... who knows!)
- adjusting timeout timer
- adjusting squelch
- busy channel lockout per channel works
- CTCSS works in TSQL mode
*Bugs found: *
- power on msg must be all caps or it becomes blank on the radio.
- (most likely hardware related... and not chirp) but enabling CTCSS causes squelch tail elimination to be turned off on transmissions from rt98v -> others. I'm able to repro in the retevis software too, but still saying it out loud in case someone smarter at this radio science stuff wants to correct me :)
One note: if you sort by frequency in chirp it gives weird channel numberings on the unit, e.g. the 3rd channel ends up showing as 07 on the rt98v... interesting lol. 1,2,7 - that's just an example, but I would think you want the channel numbering to not rearrange!
Zipped log attached, apologies, I was opening a lot of configs and files to make sure I couldnt do anything that would make the software choke. 3.2MB of clicking around...!
Updated by Dan Smith about 2 months ago
Okay, I think that all of that is probably unrelated to the subject of this bug, which is the version difference. I'll let Jim comment, but if we should be forcing the message to uppercase, let's open another bug for that. I'll go ahead and merge the fix for this one.
Updated by Dan Smith about 2 months ago
- Status changed from New to Closed
- % Done changed from 0 to 100
Applied in changeset github|387d8f63535140779864e8973fbde0bad17f8512.
Updated by Jim Unroe about 2 months ago
Dan Smith wrote in #note-10:
Okay, I think that all of that is probably unrelated to the subject of this bug, which is the version difference. I'll let Jim comment, but if we should be forcing the message to uppercase, let's open another bug for that. I'll go ahead and merge the fix for this one.
Agreed. The stated "bugs" are unrelated and should be reported in separated tickets.
Updated by Bernardo de La Tour about 1 month ago
- File config.txt config.txt added
- File debug_log.txt debug_log.txt added
[Uploaded from CHIRP next-20241020]
I am unable to download from the radio, I got an error that says "Radio version not in allowed list Retevis RT98 (...)". I tried with and without loading the module from issue 11584 and got the same error. Thank you.
Updated by Dan Smith about 1 month ago
- File retevis_rt98.py retevis_rt98.py added
Bernardo, you have a different radio (UHF vs VHF). Here's a different module for you to try which should enable the UHF V101 version as well. Please test and report like Bryant did above. If successful, I can include this in the next build.