Project

General

Profile

Actions

Bug #4635

open

Baofeng UV-3R Plus Repeater Offset Error

Added by Paul Dobosz about 7 years ago. Updated over 3 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
03/16/2017
Due date:
% Done:

0%

Estimated time:
Chirp Version:
daily
Model affected:
Baofeng UV-3R+
Platform:
Windows
Debug Log:
I read the instructions above:

Description

When programming the UV-3R+ with CHIRP the repeater offset frequency is off by a factor of 1000. In order to get a 600KHz offset I had to enter .0006 in the offset column. For 5MHz offset I had to enter .05 in the offset column. If I entered the actual offset in the column it would be off by 1000 times the entered value. I discovered this when reading the radio after it was programmed using the front panel controls.

Radio File that successfully programs the radio is attached for your review.


Files

Baofeng_UV-3R_20170310.img (3.56 KB) Baofeng_UV-3R_20170310.img Downloaded File Illustrating Issue Paul Dobosz, 03/16/2017 08:12 PM
baofeng_uv3r.PlusFix.20190306.py (21.7 KB) baofeng_uv3r.PlusFix.20190306.py Modified source to fix repeater offset issues with later UV-3R Plus firmware. Jesse Byrd, 03/05/2019 11:27 PM
uv3r_drv_err.png (55.9 KB) uv3r_drv_err.png Yegor Maksimov, 04/10/2019 09:05 AM

Related issues

Has duplicate Bug #6417: Baofeng UV-3R PLUS Frequency Offset WrongRejected01/26/2019

Actions
Has duplicate Bug #5627: CHIRP and Baofeng UV-3+Closed03/06/2018

Actions
Has duplicate Bug #5073: UV-3R Offset and Step incorrectClosed08/15/2017

Actions
Has duplicate Bug #4815: UV3R+ Error in Repeater offsetsClosed05/12/2017

Actions
Has duplicate Bug #5205: Baofeng UV-3R+ decimal in wrong placeClosed09/29/2017

Actions
Has duplicate Bug #7081: Baofeng UV-3R+ repeater shift bugClosed09/16/2019

Actions
Actions #1

Updated by Paul Dobosz about 7 years ago

Typo in the bug description ... offset entered for 600KHz was .006

I got an extra zero when I typed it into the original bug report.

Actions #2

Updated by Richard Menedetter almost 6 years ago

Offset error is still there on CHIRP daily-20180510 with Baofeng Uv-3r+.
Offset is off by a factor of 1000. (you need to set 0.076 to get an offset of 7.6)

Please correct this.
Many thanx in advance!

Actions #3

Updated by Yegor Maksimov almost 6 years ago

I have a Baofeng UV-3R:
I can confirm this bug.
When Im setting up a offset 0.05 it becomes 5.000 MHz on the radio.

Also official programming software UV-3R v1.11 have this bug too.
Probably some newer radios have firmware changes.

Actions #4

Updated by Jesse Byrd about 5 years ago

  • I've uploaded a modified version of the UV-3R driver that works for my UV-3R Plus. I fixed the problem with the repeater offset, a bug that corrupted the value for tuning_step (which is saved for every memory), and an error in recording the tx_freq (though the radio does not seem to depend on this value).

baofeng_uv3r.PlusFix.20190306.py

Actions #5

Updated by Yegor Maksimov almost 5 years ago

This modified driver does not work with latesr Chirp (CHIRP daily-20190410).
I have an error message: "Unable to load module: No module named wouxun_common"
Which version is supported by this fixed driver?

Actions #6

Updated by M T almost 5 years ago

I have a UV-5R and a UV-5RX3. If I set the VFO A or VFO B offset to @999.999000@ in CHIRP and upload the image to either radio, the radio interprets the values as @099.990@ (observable in each radio under menu item 26). If I save the image from CHIRP, close it, and then reopen it in CHIRP, I see @99.990000@ as the value in CHIRP.

I can set the value manually in either radio to @999.999@ (which is useful if you want to configure the radio to prohibit transmission in VFO mode). I'm pretty sure that if I set it manually in the radio and then read the configuration from the radio using CHIRP it will also show up as @99.990000@ in CHIRP.

I'm wondering if this is due to the same root cause?

Actions #7

Updated by Dan Smith almost 5 years ago

  • Chirp Version changed from 0.4.0 to daily

M T wrote:

I have a UV-5R and a UV-5RX3. If I set the VFO A or VFO B offset to @999.999000@ in CHIRP and upload the image to either radio, the radio interprets the values as @099.990@ (observable in each radio under menu item 26). If I save the image from CHIRP, close it, and then reopen it in CHIRP, I see @99.990000@ as the value in CHIRP.

I can set the value manually in either radio to @999.999@ (which is useful if you want to configure the radio to prohibit transmission in VFO mode). I'm pretty sure that if I set it manually in the radio and then read the configuration from the radio using CHIRP it will also show up as @99.990000@ in CHIRP.

I'm wondering if this is due to the same root cause?

Doubtful as those radios share no common code with this one. Could be the same error, but not directly related. If you haven't opened (or found) a bug for your issue, please open one.

Actions #8

Updated by Dan Smith almost 5 years ago

  • Status changed from New to Feedback

The attached modified driver isn't acceptable directly into the code for the following reasons:

  1. It makes multiple changes, not all related to the offset issue
  2. It is improperly formatted and won't pass the tests
  3. It needs to go to the mailing list in patch format per the developer process docs
  4. I'm not sure that it will fix all radios and not regress earlier models

It sounds like the OEM software has the same issue? Do all radios behave the same, or do some interpret the offset field differently? The code as provided does not distinguish between behaviors of multiple radios, which means if we just import the code as it is, it may fix the issue for some versions and break it for others (which would make it pointless to include in chirp, IMHO).

Actions #9

Updated by Jesse Byrd almost 5 years ago

Yegor Maksimov wrote:

This modified driver does not work with latesr Chirp (CHIRP daily-20190410).
I have an error message: "Unable to load module: No module named wouxun_common"
Which version is supported by this fixed driver?

I based this on chirp-daily-20180906 (the python source version on Linux).

Actions #10

Updated by Jesse Byrd almost 5 years ago

Dan Smith wrote:

The attached modified driver isn't acceptable directly into the code for the following reasons:

  1. It makes multiple changes, not all related to the offset issue
  2. It is improperly formatted and won't pass the tests
  3. It needs to go to the mailing list in patch format per the developer process docs
  4. I'm not sure that it will fix all radios and not regress earlier models

It sounds like the OEM software has the same issue? Do all radios behave the same, or do some interpret the offset field differently? The code as provided does not distinguish between behaviors of multiple radios, which means if we just import the code as it is, it may fix the issue for some versions and break it for others (which would make it pointless to include in chirp, IMHO).

The UV-3R Plus radios that I have were all sourced from the same vendor at the same time and all suffered from this issue. If I had the raw reads from from several radios that worked with the original driver, I'm willing to see if I can differentiate between the two radio software versions and formally submit this as a single issue patch. Is there formal documentation for CHIRP's formatting standards or just the test suite mentioned at https://chirp.danplanet.com/projects/chirp/wiki/DevelopersProcess ?

Actions #11

Updated by Paul Bryan almost 5 years ago

I have the Baofeng UV-3R+, and do not experience this issue. When using Chirp, I allow the default offset of 0.600, and it works correctly with the repeater. If there's anything I can to to help reproduce any behavior, let me know.

Actions #12

Updated by Bernhard Hailer over 3 years ago

According to #5205, the problem exists in radios with newer firmware.

Actions

Also available in: Atom PDF