Bug #9035

Can't program Retevis RB26

Added by Joel Elkins 6 months ago. Updated 3 months ago.

Status:Closed Start date:05/01/2021
Priority:Normal Due date:
Assignee:Jim Unroe % Done:

100%

Category:-
Target version:chirp-daily
Chirp Version:daily Platform:Windows
Model affected:Retevis RB26

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.

debug.log (28.3 kB) Joel Elkins, 05/01/2021 08:04 am

retevis_rb26_draft_fix#1.py (39.7 kB) Jim Unroe, 07/02/2021 10:38 am

Associated revisions

Revision 3527:3f1750f3b24d
Added by Jim Unroe 4 months ago

[RB26] Fix for varying ACK

The RB26 sometimes ACKs the "magic" string with a "\x00\x06" and sometimes
it
ACKs with only a "\x06". CHIRP currently expects to see the "\x00\x06" as
the
response so the process fails if the "\x00" is missing.

This patch "chews up" the "\x00 if present and then only the individual
"\x06" is expected as the ACK.

The Retevis RT76 seems to have the same issue and is fixed as a result of
this
patch.

Fixes #9035

History

Updated by Jim Unroe 5 months 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 5 months 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 4 months 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 4 months 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

Updated by Anonymous 4 months ago

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

Applied in changeset 3f1750f3b24d.

Updated by Joel Elkins 4 months 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 4 months 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 3 months ago

  • Status changed from Closed to Feedback

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

Updated by Jim Unroe 3 months 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 3 months ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF