CHIRP

Can you tell me what is in memory 12 according to the radio? Looks like something with a weird tone mode or value?

Hi Dan,

the module you provided seems to solve all problems with this radio. The
data is now loading consistently. The global settings are all correct,
and writing to and loading again from the radio also works properly.
Thanks a lot and a Happy New Year!

Best regards,
Thomasfrom Germany

Am 31.12.2024 um 19:21 schrieb Dan Smith:

Cool, thanks I'll get that queued for the next build.

Actually, it looks more complicated when I run the tests for all the other related radios.

Thomas, can you try this attached module again please? Also, can you please confirm that all the DCS codes CHIRP identifies match what the OEM software and the radio see? Also, if you could please try programming new DCS codes with chirp and make sure the radio and OEM software agree on their values, that would be appreciated.

@Jim Unroe I don't have any of these radios, so can you test with some? It looks to me from the original image that these radios can store the DCS code in either hex or octal (I see both in the same image), and they use the 0x0800 bit to indicate which one it is. Perhaps whether it was stored on the radio itself vs in the software? Either way, I'm wondering if the self._mask stuff in this driver came from thinking that some of the models used that flag always, but in reality, it was just misinterpreting that some of the memories were stored in hex vs. octal.

Some of the images in the tree are inconsistent, but that could have come from using chirp with this flag confusion on the image before we stored them.

Anyway, if you could confirm that this driver works for both "types" of rt21-based radio I'd appreciate it. Thanks!

If I may chime in..

I've observed something similar in Chirp when loading Baofeng BF-9700 settings after frequencies have been edited in Chinese OEM WP970 software. Factory fresh, untouched settings of the same radio model displayed in Chirp correctly, without red and exclamation marks.
The consensus somewhere else was that it has something to do with overall system settings and how punctuation marks "." and "," are used. They do differ country to country.

Hope this helps somehow. Cheers!

Thanks Thomas. To be clear that was with the latest version of the module, correct?

I also spoke to Jim separately to make sure he saw the request here so we'll wait to hear from him to make sure we're not messing up any of the other/related radios.

So far I haven't been able to find the RT86 that was used to create this driver. It looks like this driver supports 17 different radio models. Tomorrow I will try to round up a half dozen or so and test them against the test driver module that Dan provided to see if they are affected by the changes or not.

Thanks Jim. The RT86 is tested, so that's fine. I was actually looking for confirmation about the other models, so if you could locate a few that would be great. Specifically, one of the other models that used a different _mask value (in the original version of the code). I suspect the way the dtcs mask was being handled was wrong from the beginning, but that's just a guess.

Here's the PR so you can see what I'm changing more easily: https://github.com/kk7ds/chirp/pull/1214

Thomas B wrote in #note-15:

Hi Dan,

also with the updated module things work as they should. However I
noticed another thing which is maybe expected to be a in a new issue.
Let me just mention it here:
The radio actually supports SPEC code, hence the corresponding fields in
the OEM software:

However I cannot find these options in CHIRP at all.

Cheers,
Thomas

Am 08.01.2025 um 15:30 schrieb Dan Smith:

Either the CPS that was available when the original development was done (about 2 years) didn't have this feature or I decided to ignore it because it is not a setting that is typical related to 'ham' radio and I have no way to test it to know if it actually works or not.

OK. I found about 10 or 11 radios supported by this driver. Let me know if I am going about the the right way. What I did for the Retevis RT21 was the following...

1. Load the test driver module into CHIRP
2. Load the RT86 image that is attached to the issue
3. Download from the radio
4. Copy-and-Paste memory row 12 and/or memory row 16 from the RT86 tab to the tab created by downloading
5. Upload the tab back into the radio that it came from
6. Download from the radio a second time
7. If none of the memory rows have error, then success... repeat on next radio.

Does this make sense? Does/Will this qualify as 'comprehensive' testing? If not, then what else should I be doing?

Jim, that should suffice I think, with the caveat that we want to make sure the radio sees the right DTCS code and polarity as set by chirp with the module loaded. It would also be good to make sure a channel that is created on the radio with a DTCS code is properly decoded by chirp. You don't really need to do all of this with all the radios though. There are two varieties in the driver, ones that use a "mask" of 0x2000 and ones that use a mask of 0x2800. The RT86 is the latter, so what I really want to know is if the other variety of radios still work with this change. Radios of the type in question appear to be: RT21, RB17, RT21V, RT29, RT19, RB89. If you could test one of those with DTCS codes as set by chirp and as set by the radio, that would be the thing we're looking for.

Thanks!

I have checked 5 radios: ABREE AR-63 and Retevis RT21, RT40B, RB28B and RB628B. Three radios I did using the copy-and-paste method. Two models I had to manually edit the DTCS codes because they were FRS and PMR radios with immutable frequencies. All CHIRP tabs accepted the updated DTCSS settings. All DTCSS codes and polarity showed up correctly after upload to radio and download back to CHIRP. Now errors were encountered other than the expected error when I tried to past into a memory with an immutable frequency.

Unless you want something else tested or something tested differently, I would say that you have solve the RT86 issue without affecting the other models.

Very good thanks very much for your "radio librarian" duties Jim. I'll push this on.