Bug #10383
closedRetevis RT85: Can't modify channels 192-194
100%
Description
CHIRP details: CHIRP next-20230219 on Python 3.8.2 wxPython 4.2.0 osx-cocoa (phoenix) wxWidgets 3.2.0
I'm encountering a repeatable problem attempting to create/modify/delete records in channel locations 192, 193, 194. All channneles from 1-191 and 195-199 seem to be unaffected.
Any attempts to modify channels 192-194 result in the channel number turning red, being prefixed with a "!" and the error message "Unable to edit memory before radio is loaded".
Files
| debug.log (224 KB) debug.log | |||
| Retevis RT85 Bug.png (42.9 KB) Retevis RT85 Bug.png | |||
| th_uv88_192-194_fixed.py (37.6 KB) th_uv88_192-194_fixed.py | |||
| MENU17.png (338 KB) MENU17.png |
Updated by Dan Smith almost 2 years ago
- Status changed from New to Feedback
Need a debug log per How_To_Report_Issues
Updated by Andrew Dickinson almost 2 years ago
debug.log attached.
- start CHIRP
- Read from Radio
- Attempt to modify channel 192, hit error
Updated by Jim Unroe almost 2 years ago
Andrew Dickinson wrote in #note-2:
debug.log attached.
- start CHIRP
- Read from Radio
- Attempt to modify channel 192, hit error
I can confirm this. Editing channel 191 works fine. Editing 192 or higher causes the "list index out of range" error.
Editing channels 192 and up using CHIRP legacy works as it should.
Jim KC9HI
Updated by Frank Rizzo almost 2 years ago
- File Retevis RT85 Bug.png Retevis RT85 Bug.png added
I can confirm the bug that affects writing to channels 192-194, I've attached a screenshot.
Updated by Frank Rizzo almost 2 years ago
I'm running Chirp on an x86 Mac running macOS Monterey 12.6.3
[2023-02-28 17:27:11,690] chirp.logger - DEBUG: CHIRP next-20230224 on Darwin xxx.local 21.6.0 Darwin Kernel Version 21.6.0: Mon Dec 19 20:44:01 PST 2022; root:xnu-8020.240.18~2/RELEASE_X86_64 x86_64 (Python 3.8.2)
[2023-02-28 17:27:12,172] main - INFO: Python/3.8.2 // Darwin/macOS-12.6.3-x86_64-i386-64bit // CHIRP/next-20230224 // wx/4.2.0 osx-cocoa (phoenix) wxWidgets 3.2.0
Updated by Frank Rizzo almost 2 years ago
@Jim Unroe Are you able to assist with this one? It looks like you helped with the original development for this radio.
Updated by Jim Unroe almost 2 years ago
Frank Rizzo wrote in #note-6:
@Jim Unroe Are you able to assist with this one? It looks like you helped with the original development for this radio.
I don't think so. I didn't see anything that was changed in the driver when it was converted from Py2 to Py3 that would cause this. It works in classic CHIRP so it wasn't an existing bug. So I was thinking it is something caused by CHIRP-next. In that case, Dan would have to look at it.
But I think I am at a place where I could take some time to look at it again. I will try to do that this evening.
Jim KC9HI
Updated by Dan Smith almost 2 years ago
...and also please describe what is in those channels according to the radio.
Updated by Jim Unroe almost 2 years ago
- Assignee set to Jim Unroe
- Target version set to chirp-py3
Frank Rizzo wrote in #note-6:
@Jim Unroe Are you able to assist with this one? It looks like you helped with the original development for this radio.
After looking at this again, I think I see where this problem is happening. I am not sure why, yet. Hopefully I can have something available to test later today.
Jim KC9HI
Updated by Jim Unroe almost 2 years ago
- File th_uv88_192-194_fixed.py th_uv88_192-194_fixed.py added
I believe that I have located the issues and implemented fixes. Those 3 channels had values in them that, because of the way CHIRP-next works, were considered as being out of range.
I have attached a modified driver module (th_uv88_192-194_fixed.py) for you to test. Here is how you do it.
- Launch CHIRP. Make sure you are running today's CHIRP-next (20230303) or newer. If not, upgrade and start over.
- Click Help in the menu bar and select Load module from issue
- Key in the Issue number for this ticket (10383) and click the [OK] button
- Select the driver module listed and click the [OK] button.
Your CHIRP is now running with the test driver module loaded. Test and report back your results.
Note: An externally loaded driver module like this does not permanently change your CHIRP installation in any way. Once you close CHIRP you will have to re-load the driver module in order to have the added fixes or features again.
Once I receive favorable feedback, I will create and submit a formal patch.
Jim KC9HI
Updated by Andrew Dickinson almost 2 years ago
I can confirm that loading the new module (using the instructions above) allows me to open the .img file that I've previously saved. Later today, I'll confirm that I can write it to the radio and read it back, but I'm optimistic.
Updated by Frank Rizzo almost 2 years ago
Thank you @Jim Unroe! I was able to successfully load the modified driver module and confirm that it resolved the issue. I can now write to channels 192,193, and 194.
Updated by Frank Rizzo almost 2 years ago
- File MENU17.png MENU17.png added
@Jim Unroe There seems to be an issue with the Scan Type (Menu 17) not saving the correct search setting when you select one of the options - CO, TO, SE in Basic Settings > Scan Type in Chirp. I believe they're out of order and should be listed as TO, CO, SE.
Updated by Jim Unroe almost 2 years ago
- Status changed from Feedback to In Progress
Frank Rizzo wrote in #note-14:
@Jim Unroe There seems to be an issue with the Scan Type (Menu 17) not saving the correct search setting when you select one of the options - CO, TO, SE in Basic Settings > Scan Type in Chirp. I believe they're out of order and should be listed as TO, CO, SE.
This is unrelated to this issue. If you open a ticket for it, I will take a look at it.
Jim KC9HI
Updated by Frank Rizzo almost 2 years ago
@Jim Unroe Understand, the new ticket can be found here: https://chirp.danplanet.com/issues/10419
Updated by Jim Unroe almost 2 years 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-next following acceptance.
Jim