Bug #9982

Retevis RB26 Tone Error

Added by Doug Rehman about 1 month ago. Updated about 1 month ago.

Status:Closed Start date:08/10/2022
Priority:Normal Due date:
Assignee:Jim Unroe % Done:

100%

Category:-
Target version:chirp-daily
Chirp Version:daily Platform:All
Model affected:RB26 and others

Description

CTCSS/DCS cannot be changed/set for channels 8-14 (the 467 MHZ low power/narrow frequencies).

I was able to change them using the browser, but not with the standard settings tab.

debug.log (58.3 kB) Doug Rehman, 08/10/2022 07:42 pm

RB26 Error.JPG (85.3 kB) Doug Rehman, 08/10/2022 07:42 pm

retevis_rb26_temp_fix.py (46.9 kB) Jim Unroe, 08/11/2022 02:32 am

RB26 Error 2.JPG (92.4 kB) Doug Rehman, 08/11/2022 02:46 am

retevis_rb26_fix_b1.0.py (43 kB) Jim Unroe, 08/14/2022 12:55 am

retevis_rb26_fix_b1.2.py (44.2 kB) Jim Unroe, 08/19/2022 01:22 am

Associated revisions

Revision 3733:af1890971f56
Added by Jim Unroe about 1 month ago

[RB26] Unable to Select Tones

Trying to set squelch tones was causing validation errors to pop up thus
preventing the user to edit tone values. This was caused by the way
CHIRP was programmed to keep various FRS, GMRS and PMR values valid.

This patch reworks how the driver validates Frequency, Mode and Power
selections.

Fixes #9982

History

Updated by Jim Unroe about 1 month ago

  • File retevis_rb26_temp_fix.py added
  • Status changed from New to In Progress
  • Assignee set to Jim Unroe
  • Target version set to chirp-daily
  • Model affected changed from (All models) to RB26 and others
  • Platform changed from Windows to All

I will be looking at this to come up with a permanent fix. In the meant time you can use the attached driver module as a temporary fix.

To use it do the following...

  1. save the attached file (retevis_rb26_temp_fix.py) to a convenient location. Note: Do not right-click the link to download. Left-click the link, wait for the next page to load. Then left-click the download link near the top.
  2. open CHIRP
  3. enable Enable Developer Functions in the Help menu
  4. click Load Module in the File menu
  5. locate and load the file that was saved in step 1

CHIRP should now have a red background to indicate that it is running with an externally loaded driver module. This does not permanently change your CHIRP installation. Once you close CHIRP, the next time you open CHIRP you will have to load this test driver module to have access to it again.

Hopefully you will be able to make your changes with this temporary driver module. Let me know if you can't.

Jim KC9HI

Updated by Doug Rehman about 1 month ago

It works for CH9-14. It doesn't work for CH8 (467.5675)

Updated by Jim Unroe about 1 month ago

Doug Rehman wrote:

It works for CH9-14. It doesn't work for CH8 (467.5675)

Interesting. I did my testing with CH8. No matter, I am still looking to create a permanent fix.

Also, a better solution than using the Developer's Browser would be to use the Memory Properties Editor to edit the CTCSS tones/DCS codes. After selecting the memory row(s) that you wish to edit (yes you can edit common parameters of multiple channels at the same time), either click the [Properties] button at the top of the Spreadsheet Style Memory Editor or right-click a highlighted memory row and choose Properties from the list that appears. This method appears to not be affected by the "bug".

Jim KC9HI

Updated by Jim Unroe about 1 month ago

After a lot of research and many hours of trial and error, I believe I have a workable solution for the troublesome "Validation" code. Please test and provide feedback. Thanks in advance.

These changes also affect Retevis, RB17A, RT21, RT29_UHF, RT29_VHF and RT76 radio models. CHIRP images for these radio models are in the CHIRP Repository if you would like to test any of them.

As a part of this I also made changes so that High was the default power level on channels where High power is permitted. I will likely have to split these changes into a minimum of 2 patches for them to be accepted. I left them combined as a convenience for testing.

Jim KC9HI

Updated by Doug Rehman about 1 month ago

CH8-14 are now programming properly.

On the other channels, there's an issue with certain mode/power combinations. In testing using the first four channels (alter settings>upload>download):

Original New Actual
FM/High NFM/Low NFM/High <<<<ERROR
FM/Low NFM/High NFM/Low <<<<ERROR
NFM/Low NFM/High NFM/Low <<<<ERROR
FM/Low FM/High FM/Low <<<<ERROR

Once I change a channel to Low, I can't change it back to High.

Updated by Jim Unroe about 1 month ago

  • File retevis_rb26_fix_b1.1.py added

Good catch. I was just testing images and wasn't uploading to / downloading from the radio. I dug out my RB26 and I think I have resolved the issue. I have attached the update.

Jim KC9HI

Updated by Jim Unroe about 1 month ago

  • File deleted (retevis_rb26_fix_b1.1.py)

Updated by Jim Unroe about 1 month ago

The retevis_rb26_fix_b1.1.py beta file was removed because it still has a bug.

Jim KC9HI

Updated by Jim Unroe about 1 month ago

Hopefully this should do better. I have dug out my RT21, RB17A, RB26, RT76, RT29_UHF and RT29_VHF and tested each one.

Jim KC9HI

Updated by Doug Rehman about 1 month ago

Worked perfectly for me—thanks for your work!

An unrelated question please: I updated "New Model #4851" (TYT TH-8600) 10 days ago to inquire about the status and haven't seen any response. The original request was 5/30/2017 with multiple duplicate requests and offer of radios since. Is there any chance of it being supported?

Thanks,
Doug

Updated by Jim Unroe about 1 month ago

Doug Rehman wrote:

Worked perfectly for me—thanks for your work!

Thank your for the testing and feedback. It has been very valuable to me. I will try to get these changes submitted in the next few days.

An unrelated question please: I updated "New Model #4851" (TYT TH-8600) 10 days ago to inquire about the status and haven't seen any response. The original request was 5/30/2017 with multiple duplicate requests and offer of radios since. Is there any chance of it being supported?

Getting a radio supported requires the following...

  1. a radio
  2. a programming cable
  3. the factory programming software
  4. a volunteer developer that is willing to do the work

It would seem that one or more of the requirements are missing.

Jim KC9HI

Updated by Jim Unroe about 1 month ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

A patch has been submitted. Support will be in the next CHIRP daily build following acceptance.

Jim KC9HI

Updated by Anonymous about 1 month ago

  • Status changed from Resolved to Closed

Applied in changeset af1890971f56.

Also available in: Atom PDF