Bug #9035
closedCan't program Retevis RB26
Added by Joel Elkins almost 3 years ago. Updated over 2 years ago.
100%
Description
I saw that the RB26 was supported but whenever I try to download from the radio I get the message, "The radio did not accept program mode after five tries.
Check you interface cable and power cycle your radio." It wont upload to radio either. Its on the right COM port. I can use the software from Retevis but somehow Chirp isn't able to access it.
Files
| debug.log (28.3 KB) debug.log | Joel Elkins, 05/01/2021 08:04 AM | ||
| retevis_rb26_draft_fix#1.py (39.7 KB) retevis_rb26_draft_fix#1.py | Jim Unroe, 07/02/2021 10:38 AM |
Updated by Jim Unroe almost 3 years ago
- Status changed from New to Feedback
Hi Joel,
Once the radio successfully worked with the OEM software, did you immediately try CHIRP? Also make sure you close the OeM software before you try to use CHIRP. Some OEM software won't allow any other software access the programming cable while it is open.
According to the debug.log file the radio is not returning anything back to CHIRP. This would seem to be a programming cable connection issue. Trying CHIRP after should would rule that out.
I dug my RB26 out just to make sure something didn't get messed up during the original submission to add the RB26 to CHIRP. My CHIRP read from my RB26 radio without any problems.
Jim KC9HI
Updated by Joel Elkins almost 3 years ago
I bought a new cable to try just in case, but the issue is the same. Both cables work with the OEM software, but for some reason not with Chirp even right after using the OEM software and it closed out. It makes me wonder if its something with programing the radio with the OEM software first that has somehow made the radio incompatible.
Updated by Jim Unroe almost 3 years ago
Perhaps it is a timing issue. I dug out my RT26 and tried to download from it. It failed. I then power cycled the radio with the programming cable still connected and downloaded again. It was successful. The I unplugged everything and started over and after several tries have not been able to download again. This is not my CHIRP development computer and I don't recall having this issue while developing support for the RB26.
I will switch over to my CHIRP development computer later this morning and try again. If it behaves the same way, I should hopefully be able to figure out what is going on and hopefully find a reliable solution.
Jim KC9HI
Updated by Jim Unroe almost 3 years ago
- File retevis_rb26_draft_fix#1.py retevis_rb26_draft_fix#1.py added
- Assignee set to Jim Unroe
Apparently on my regular PC and yours, the response to a clone request is nearly always "\x06". On my development PC the response is always "\x00\x06" (and this is what CHIRP is programmed to expect). The RT76 works the same way. I have made a modification that I believe allow CHIRP to support either response.
This is working for me for both radio models (RB26 and RT76) on both computers. Let me know how it works for you. I will submit a formal patch once I see that the test driver module is working for you.
The following explains you to load the test driver module for testing.
1 save the attached "retevis_rb26_draft_fix#1.py" test driver module to a convenient location
Important: left click the file name and then click the "download" link on the page that loads.
2 open CHIRP
3 click "Help" in the menu bar and enable "Enable Developer Functions"
4 click "File" in the menu bar and select "Load Module" in the list of selections
5 locate and load the file that was saved in step 1
The CHIRP background should now be red. Attempt to download from your radio. If it works (it should), attached the downloaded CHIRP Radio Images (*.img) file to this issue.
Note: This test driver module does not permanently change your CHIRP installation. If you close CHIRP and later on need to access your radio, you will have to load this test driver first.
Jim KC9HI
Updated by Anonymous almost 3 years ago
- Status changed from Feedback to Closed
- % Done changed from 0 to 100
Applied in changeset commit:3f1750f3b24d.
Updated by Joel Elkins almost 3 years ago
Thank You! Its working. The only thing is are the frequencies supposed to be locked in place? The only things that can be changed are the ctcss and dcs codes.
Updated by Joel Elkins almost 3 years ago
Thank You! Its working. The only thing is are the frequencies supposed to be locked in place? The only things that can be changed are the ctcss and dcs codes.
Updated by Bernhard Hailer almost 3 years ago
- Status changed from Closed to Feedback
Re-opened so that Joel's question can be answered.
Updated by Jim Unroe almost 3 years ago
Joel Elkins wrote:
Thank You! Its working. The only thing is are the frequencies supposed to be locked in place? The only things that can be changed are the ctcss and dcs codes.
Yes. This is by design. Otherwise it would not be FCC Part 95 Subpart E certified for GMRS use.
You can also change the bandwidth and transmit power of all channels except 8-14 (which by the rules must be NFM and 0.5 watts).
Jim KC9HI
Updated by Bernhard Hailer over 2 years ago
- Status changed from Feedback to Closed