Project

General

Profile

Actions

Bug #947

closed

Adding R-Code causes "UNSUPPORTED MODEL"

Added by Greg Dean over 11 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
High
Assignee:
Category:
-
Target version:
Start date:
07/03/2013
Due date:
% Done:

100%

Estimated time:
Chirp Version:
daily
Model affected:
Baofeng UV-B5/B6
Platform:
All
Debug Log:
I read the instructions above:

Description

THis is a forked update from NEW MODEL #901 issue. I thought i would post this as a bug on my own.

I added area repeaters via Repeater book. These repeaters require a PL tone. After i wrote to the device i went into the device and looked at the R-Code. The R-Code said OFF. So i switched it to the correct PL tone. After that i went toe chirp to try to download from the device. That was the point that i gained the UNSUPPORTED MODEL ERROR. I came here and looked at the issue and reset my device VIA Jim Unroe's advice. After resetting i proceeded to open my saved settings and upload them back to the device and once again added the R-Code to the same channel as last time (in this case channel 1) then tried to download again. I again got the unsupported model error. i unplugged the device then went back to the R-Code and switch it to off after which i tried to download from the device again and POOF! NO ERROR.

SO maybe it is a conflict withe the R-Code is what i am thinking. I can include a copy of my file if needed.

Hope this is the actual issue.

I just did a Reset to test this out. After resetting the device I then went to R-Code in the menu and set a PL Tone (88.5). Then I went into chirp and tried to download from the device. ERROR. Then I went back to the device and removed the R-Code. Went back to chirp and try the download again, NO ERROR.

I have just now reset the device again and set an r-code of 67.0. NO ERROR.
Reset again, R-code 69.3. ERROR
No Reset, R-Code 71.9. ERROR
Turn R-Code to off. NO ERROR

So I am going to assume any number above 67.0 in R-Code is going to throw an error.

Build version: CHIRP daily-20130630

Actions #1

Updated by Greg Dean over 11 years ago

I forked this from posts that I MADE

Actions #2

Updated by Jim Unroe over 11 years ago

Hi Greg,
Thanks for taking the time to post this. I could cause a problem with the Radio Work Mode(A)/(B) setting but I couldn't cause the problem always. Your observation gives me a method where I can cause the failure at will.

I think I now understand the two things that are happening that cause this issue.

  1. The 'ident' string changes when a channel has R-CODE set above 67.0 Hz.
    Expected: "HKT511\x00\x04"
    Received: "HKT511\x00\x00"

  2. The value of the acknowledgement that CHIRP is looking for changes.

if ecks != "x":
raise errors.RadioError("Unexpected response")

Number 1 is easy to fix. Number 2 I will have to think about. I've seen at least 3 different values for 'ecks'. Thanks Baofeng. :(

Jim KC9HI

Actions #3

Updated by Jim Unroe over 11 years ago

  • Status changed from New to Resolved
  • Assignee set to Jim Unroe
  • Target version set to 0.4.0
  • Chirp Version changed from 0.3.0 to daily
  • Platform changed from Windows to All

A patch for this has been submitted and applied.
Jim KC9HI

Actions #4

Updated by Jim Unroe over 10 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
Actions

Also available in: Atom PDF