New Model #2293

UV-B5 with new firmware (27 menu entries) currently not supported

Added by Richard Menedetter over 5 years ago. Updated over 3 years ago.

Status:Closed Start date:02/07/2015
Priority:Normal Due date:
Assignee:- % Done:

0%

Category:-
Target version:-
Chirp Version:daily Equipment Loan Offered:No

Description

The newer Firmware UV-B5 (propably B6 as well) are not compatible with Chirp 0.4.1 or the latest dailys.

I get the output "radio did not ack programming mode".
The problem seems to be different ACK sent by the UV-B5.
Additionally there seems to be a cosmetic problem, that some UV-B5 do not support the test data, and they do net ACK that data.
So it would be good if it would ignore a NACK on the first byte of that data.

I am willing to contribute data if needed, and to test possible fixes.

History

Updated by Doug McComber over 5 years ago

I have the same issue with mine.

CHIRP 0.4.1 on WinVista/7 (Python 2.7.2)
Registered Baofeng_UV-3R = UV3RRadio
Registered Baofeng_UV-5R = BaofengUV5R
Registered Baofeng_F-11 = BaofengF11Radio
Registered Baofeng_UV-82 = BaofengUV82Radio
Registered Baofeng_UV-6 = BaofengUV6Radio
Skipping existing stock config
Skipping existing stock config
Skipping existing stock config
Skipping existing stock config
Skipping existing stock config
Skipping existing stock config
Skipping existing stock config
Skipping existing stock config
User selected Baofeng UV-B5 on port COM4
Clone thread started
-- Exception: --
Traceback (most recent call last):
File "chirpui\clone.pyo", line 227, in run
File "chirp\uvb5.pyo", line 305, in sync_in
File "chirp\uvb5.pyo", line 196, in do_download
File "chirp\uvb5.pyo", line 177, in do_ident
RadioError: Radio did not ack programming mode
------
Clone failed: Radio did not ack programming mode
Clone thread ended
--- Exception Dialog: Radio did not ack programming mode ---
Traceback (most recent call last):
File "chirpw", line 74, in <module>
AttributeError: 'NoneType' object has no attribute 'split'
----------------------------

Updated by Bryce Bolton about 5 years ago

Same issue as others.
OEM software does work
What is strange is you can select UV-3R and it will download from the radio.

Updated by Grant Kwok about 5 years ago

Additional info, as others have stated - choosing UVB5 results in "radio did not ack programming mode"

Confirmed choosing UV-3R does successfully connect to the radio and goes through the download process from the radio however the results are not correct. In my case it only shows a value for memory location 2, and everything else is blank. The settings tab is also blank.

OEM software works fine for me.

Updated by Edward Lisle almost 5 years ago

Hi Guys

I recently acquired a Baofeng UV-B5 and on attempting to use it with Chirp, encountered the same problem that other users found i.e the error "Radio did not ack programming mode" came up if I tried to download or upload. I use a homebrew serial port adapter connected to the hardware serial port on a PC, one which I have used successfully with several different Baofeng radios, so it cannot be a USB cable/driver issue. Like other users, I found that the factory software works fine, and that I could download from the radio in Chirp if I selected 'UV-3R' as the radio type, though of course the channel data displays as garbage because the data layout is different. This same problem is also described in Bug #2131. I tried Chirp on Linux on the same PC and got precisely the same result.

I compared the driver code for the UV-B5 and the UV-3R and noted two key differences. Firstly, the 'PROGRAM' string is preceded by a hex 05 in the latter case. Secondly, several attempts are made to get a successful 'ack' in the case of the UV-3R - the "UV3R identification dance". I also noted Jim Unroe's remark that the "UV-B5 ACKs almost any character". So I thought maybe we need to throw away bytes in the serial input buffer until either we get our '\x06' or the serial input times out. I came up with this patch to uvb5.py, and everything now works except that when uploading I get the already-documented "Radio NAK'd block at address 0xF010" which we know is innocuous. If I deliberately force an error by not connecting a radio then after 3 seconds I get "Radio did not ack programming mode" as expected.

I have only tested this on Linux: perhaps someone could build and test a Windows version as I can't work out how to do it. I also do not know if it works with an 'old firmware' UVB5 - if not maybe we need two drivers for this model.

Here's the diff:

178,181c178,185
< radio.pipe.write("PROGRAM")
< ack = radio.pipe.read(1)
< if ack != '\x06':
< raise errors.RadioError("Radio did not ack programming mode")
---

ack = '\x00'
radio.pipe.write("\x05PROGRAM")
while ack != '\x06':
ack = radio.pipe.read(1)
if len(ack) == 0:
  1. We timed out without seeing the expected byte
    raise errors.RadioError("Radio did not ack programming mode")
    return

Hope this is useful

Updated by Richard Menedetter almost 5 years ago

Edwards Patch works here.
Windows chirp (file -> load module -> new uvb5.py)
UV-B5 with 27 menu entries.

Thanx Edward - now we need to push this Patch into the chirp daily builds.

Somebody should check if the patch works with the "old" uv-b5 model.

Updated by Edward Lisle almost 5 years ago

I have attached the patched uvb5.py to Bug #2751. Let's hope it makes it into the
daily builds :)

Updated by Chris H over 3 years ago

Richard Menedetter wrote:

The newer Firmware UV-B5 (propably B6 as well) are not compatible with Chirp 0.4.1 or the latest dailys.

I get the output "radio did not ack programming mode".
The problem seems to be different ACK sent by the UV-B5.
Additionally there seems to be a cosmetic problem, that some UV-B5 do not support the test data, and they do net ACK that data.
So it would be good if it would ignore a NACK on the first byte of that data.

I am willing to contribute data if needed, and to test possible fixes.

I have the uv-b5 with 27 menu.
I didn't know about this and loaded my channels into it. Radio NAK'd block at address 0x0f10
And it works but the fm function does not.
any fixes?

Updated by Jim Unroe over 3 years ago

  • Status changed from New to Feedback

Ignore the error. If the upload makes it to this error, all of the settings that the radio will accept were successfully sent to the radio.

You most likely have the "FM Function" (in the Basic Settings tab) disabled.

Jim KC9HI

Updated by Jim Unroe over 3 years ago

  • Status changed from Feedback to Closed

CHIRP daily-20170212 should resolve this issue. See #2109

Jim KC9HI

Also available in: Atom PDF

prevent spam