CHIRP

I'll second this. I have a UV-B5 and it sees the same error. The same computer and cable connect to the radio perfectly using what I assume is the factory programming software. So it's a Chirp problem. This version was downloaded in late December.

Windows 7 Pro 64, Prolific driver and cable.

How about a debug.log file from both of you?

Jim KC9HI

Here's mine, after the long list of registered radios:

Registered Wouxun_KG-818 = KG818Radio
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'¶

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'

Thanks for the debug.log. Unfortunately it doesn't help other than to show where in the process the failure. Unfortunately the UV-B5 ACKs almost any character and the CHIRP software expects a response of 0x06.

This used to drive me crazy with my UV-B5 because the character that the radio ACKed would change depending on the settings of the radio. Once it switched to an unexpected character, I had to RESET my radio to get it working with CHIRP again. JENS helped me change it so that during the cloning process, the first ACK character was accepted and used for the remainder of the cloning.

But this is during the initial "ident" of the radio and CHIRP expects a reply of 0x06 and your radio is apparently replying with something else.

Jim KC9HI

Sorry ... it seems I opened a duplicate of this:
New Model #2293

Any progress?
Can we support you somehow?

I would love to see the "new" UV-B5/6 fully supported.

As a workaround you can use the BoaFeng SW to get the image, modify it in Chirp, and reupload with the BoaFeng SW again.
But it would be great to directly support the "new" model in Chirp!

Yes +1 on fixing the issue for us please. I see more than few people with the issue on our UV-b5 yahoo group.

Not opposed to loaning the unit out. (if not too long, a week, two ? or do you need it longer ?)

Have a older UV-B5 that works fine, a new unit I tried has the ack programming mode error, on my windows 8.

And then tried the Linux version on a different computer, does not get the ack error, when doing a radio download, pulled channels from radio fine, did not test any farther.

Was using the same chirp-daily-20150513 of latest daily version.

Also I did notice a big difference in the time it takes the error box comes up, when forcing a error, by not connecting the radio, almost instant on Windows, Linux about 3 seconds.

I had the same problem also using a (probably fake) Prolific cable, even with the older Prolific drivers, although Chirp would not work under linux for me either, also giving the Ack error.

I eventually fixed it by cutting the cable off and connecting it to a different usb serial adapter. I posted how I fixed it at http://chirp.danplanet.com/issues/1209#note-19

So I believe it's a Chirp bug when using Prolific cables.

This bug seems to be a duplicate of http://chirp.danplanet.com/issues/1209