Project

General

Profile

Actions

Bug #6417

closed

Baofeng UV-3R PLUS Frequency Offset Wrong

Added by Maurizio Marcovati about 5 years ago. Updated almost 5 years ago.

Status:
Rejected
Priority:
High
Assignee:
-
Category:
-
Target version:
-
Start date:
01/26/2019
Due date:
% Done:

0%

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

Description

If I put the proper number in Chirp editor (eg. 1.6 MHz) the radio wrongly set it to 160 MHz and off course doesn't transmit.
To obtain the proper value I have to write a "wrong", scaled number in the editor: 0.016.
See attached screenshot, with the wrong number in the editor the radio is set-up with the proper one.

Version: daily 20190120

I don't remember such a bug with Baofeng UV-3R (not PLUS) and I don't have such model anymore to test.


Files

Screenshot.png (243 KB) Screenshot.png Maurizio Marcovati, 01/26/2019 01:17 PM
UV-3R vs. Plus.png (268 KB) UV-3R vs. Plus.png Maurizio Marcovati, 01/27/2019 09:50 AM

Related issues

Is duplicate of Bug #4635: Baofeng UV-3R Plus Repeater Offset ErrorFeedback03/16/2017

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

Actions
Actions #1

Updated by Maurizio Marcovati about 5 years ago

I found the same bug already posted in #5627 and #4635 in March 2017 !

Please solve the issue.
Thanks

Actions #2

Updated by Maurizio Marcovati about 5 years ago

Comparing the .img files from an old UV-3R and a new UV-3R PLUS it's clear (green areas in the picture) what appens.
For an unknown reason, Baofeng shifted the offset data by one byte in the memory map.
There is also an odd number in the same row for each channel; it seems to be the "tx freq", but it's only the sum of "rx freq" and the "offset" taken in the old stile. The number is, of course, totally wrong and the radio seems to ignore it (hopefully) and transmit on the proper offset frequency.

I'm not an expert in pyton, but I hope it's easy to adapt the driver to this "different" variant of UV-3R.
Thanks a lot.

Actions #3

Updated by M T almost 5 years ago

Is that captured in https://chirp.danplanet.com/issues/4635#note-4 ? If so, should this be closed as a duplicate of #4635?

Actions #4

Updated by Maurizio Marcovati almost 5 years ago

The bug 6417 IS the same of 4635, but note-4 is not yet inserted in CHIRP-daily up to now.
The file uploaded by Jesse Byrd one month ago has been inserted in the daily stream?

CHIRP daily-20190412 still has the bug.

Actions #5

Updated by Yegor Maksimov almost 5 years ago

Really, why chirp developers ignore this problem? All latest versions of uv-3r have this bug. It must be fixed in official chirp release!!!

Actions #6

Updated by Dan Smith almost 5 years ago

  • Status changed from New to Rejected

Yegor Maksimov wrote:

Really, why chirp developers ignore this problem? All latest versions of uv-3r have this bug. It must be fixed in official chirp release!!!

Because we are volunteers. I don't have access to a newer UV-3R, nor do I know anyone that does. Just FYI, demanding a fix from volunteers is not an effective way to get something like this resolved.

Closing this as a duplicate of #4635

Actions

Also available in: Atom PDF