Bug #4635
openBaofeng UV-3R Plus Repeater Offset Error
0%
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 | ||
| 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. | ||
| uv3r_drv_err.png (55.9 KB) uv3r_drv_err.png |
Updated by Paul Dobosz over 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.
Updated by Richard Menedetter over 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!
Updated by Yegor Maksimov over 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.
Updated by Jesse Byrd over 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
Updated by Yegor Maksimov over 5 years ago
- File uv3r_drv_err.png uv3r_drv_err.png added
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 over 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?
Updated by Dan Smith over 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.
Updated by Dan Smith over 5 years ago
- Status changed from New to Feedback
The attached modified driver isn't acceptable directly into the code for the following reasons:
- It makes multiple changes, not all related to the offset issue
- It is improperly formatted and won't pass the tests
- It needs to go to the mailing list in patch format per the developer process docs
- 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 over 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).
Updated by Jesse Byrd over 5 years ago
Dan Smith wrote:
The attached modified driver isn't acceptable directly into the code for the following reasons:
- It makes multiple changes, not all related to the offset issue
- It is improperly formatted and won't pass the tests
- It needs to go to the mailing list in patch format per the developer process docs
- 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 over 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.
Updated by Bernhard Hailer about 4 years ago
According to #5205, the problem exists in radios with newer firmware.