Project

General

Profile

Actions

Bug #9035

closed

Can't program Retevis RB26

Added by Joel Elkins almost 3 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
05/01/2021
Due date:
% Done:

100%

Estimated time:
Chirp Version:
daily
Model affected:
Retevis RB26
Platform:
Windows
Debug Log:
I read the instructions above:

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
Actions #1

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

Actions #2

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.

Actions #3

Updated by Jim Unroe over 2 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

Actions #4

Updated by Jim Unroe over 2 years ago

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

Actions #5

Updated by Anonymous over 2 years ago

  • Status changed from Feedback to Closed
  • % Done changed from 0 to 100

Applied in changeset commit:3f1750f3b24d.

Actions #6

Updated by Joel Elkins over 2 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.

Actions #7

Updated by Joel Elkins over 2 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.

Actions #8

Updated by Bernhard Hailer over 2 years ago

  • Status changed from Closed to Feedback

Re-opened so that Joel's question can be answered.

Actions #9

Updated by Jim Unroe over 2 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

Actions #10

Updated by Bernhard Hailer over 2 years ago

  • Status changed from Feedback to Closed
Actions

Also available in: Atom PDF