Bug #4635

Baofeng UV-3R Plus Repeater Offset Error

Added by Paul Dobosz over 2 years ago. Updated 26 days ago.

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

0%

Category:-
Target version:-
Chirp Version:daily Platform:Windows
Model affected:Baofeng UV-3R+

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.

Baofeng_UV-3R_20170310.img - Downloaded File Illustrating Issue (3.6 kB) Paul Dobosz, 03/16/2017 08:12 pm

baofeng_uv3r.PlusFix.20190306.py - Modified source to fix repeater offset issues with later UV-3R Plus firmware. (21.7 kB) Jesse Byrd, 03/05/2019 11:27 pm

uv3r_drv_err.png (55.9 kB) Yegor Maksimov, 04/10/2019 09:05 am


Related issues

duplicated by Bug #6417: Baofeng UV-3R PLUS Frequency Offset Wrong Rejected 01/26/2019

History

Updated by Paul Dobosz over 2 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.

Updated by Richard Menedetter about 1 year 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!

Updated by Yegor Maksimov about 1 year 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.

Updated by Jesse Byrd 3 months 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

Updated by Yegor Maksimov 2 months 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?

Updated by M T 2 months 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?

Updated by Dan Smith 2 months 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.

Updated by Dan Smith 2 months 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).

Updated by Jesse Byrd about 1 month 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).

Updated by Jesse Byrd about 1 month 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 ?

Updated by Paul Bryan 26 days 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.

Also available in: Atom PDF