CHIRP

I have the same issue with mine.

//rob Hill 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

AttributeError: 'NoneType' object has no attribute 'split'¶

@

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

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.

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:
    # We timed out without seeing the expected byte
      raise errors.RadioError("Radio did not ack programming mode")
      return

Hope this is useful

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.

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

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?