Project

General

Profile

Actions

Bug #11372

closed

Retevis RA87 doesn't retain scan mode changes

Added by David Oswald 5 months ago. Updated 5 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
06/06/2024
Due date:
% Done:

100%

Estimated time:
Chirp Version:
next
Model affected:
Retevis RA87
Platform:
Linux
Debug Log:
I read the instructions above:
Yes

Description

For the Retevis RA87:

Set scan mode in CHIRP for menu option 12 (Scan mode) from TO (the default, timeout scan resume) to CO (Carrier based scan resume). Upload from CHIRP to the RA87. The unit restarts, as usual. But option 12 has remained at the default TO setting.

I verified this with another person also running CHIRP on their Windows laptop, and owning the same radio. We both see the same issue.

What should happen, is that the radio should be set to CO mode for menu 12, scan mode.


Files

Retevis_RA87_20240603_custom.img (8.24 KB) Retevis_RA87_20240603_custom.img Retevis RA87 image to play with David Oswald, 06/06/2024 01:48 PM
retevis_ra87.py (41.5 KB) retevis_ra87.py Jim Unroe, 06/07/2024 10:06 AM
bug_11372.patch (608 Bytes) bug_11372.patch RA87 bug 11732 git patch David Oswald, 06/13/2024 07:14 AM
Actions #1

Updated by David Oswald 5 months ago

This segment of code could be the issue:

# menu 12 - SCAN
        options = ["Carrier Operated (CO)", "Time Operated (TO)",
                   "SEarch (SE)"]
        rs = RadioSettingValueList(options, options[_settings.scan])
        rset = RadioSetting("scan", "Scan Resume Method", rs)
        rset.set_doc("Menu 12")
        basic.append(rset)

I think the "options" array should look like this:

options = ["Time Operated (TO)", "Carrier Operated (CO)", "Search (SE)"]
Actions #2

Updated by David Oswald 5 months ago

I see now that I miscategorized this as CHIRP Legacy, when it should have been NEXT. This is a bug in NEXT.

Actions #3

Updated by Jim Unroe 5 months ago

  • File retevis_ra87.py retevis_ra87.py added
  • Status changed from New to In Progress
  • Assignee set to Jim Unroe
  • Target version set to chirp-py3
  • Chirp Version changed from legacy to next

Yep. Looks like I had a dyslexic moment when building the options list. Try this test driver module and provide feedback. Here's how: LoadingTestModules

Actions #4

Updated by David Oswald 5 months ago

I tested out the fix. It works correctly; if I set CO as the scan method in CHIRP, it gets uploaded correctly to the radio now. Looks like it was the order of elements in that options array, like I suspected. Thanks for getting to this.

What happens of _ham = True is set? Just curious but there's probably a better place to further discuss the module.

Actions #5

Updated by David Oswald 5 months ago

Here's a git patch that contains the proposed change.

Actions #6

Updated by Jim Unroe 5 months ago

David Oswald wrote in #note-5:

Here's a git patch that contains the proposed change.

Yeah. I meant to get this submitted but it fell through the cracks. I will try to get to get it done.

Actions #7

Updated by Jim Unroe 5 months ago

Jim Unroe wrote in #note-6:

David Oswald wrote in #note-5:

Here's a git patch that contains the proposed change.

Yeah. I meant to get this submitted but it fell through the cracks. I will try to get to get it done.

Actually I had already submitted this to be included. We are just waiting on it to be approved and merged into CHIRP.

Actions #8

Updated by Anonymous 5 months ago

  • Status changed from In Progress to Closed
  • % Done changed from 0 to 100
Actions

Also available in: Atom PDF