Bug #2131
closedNew Baofeng UV-B5 - Radio did Not Ack ... - OEM soft-Ok
0%
Description
Tested two new UV B5 radios (sn 10B5043182)
OS: Win7 64 and Win8 64 (comp & notebook)
USB driver: Prolific_3.2.0.0
Chirp
Mode: baofeng UV B5
Message: Radio did Not Ack Programming Mode
Mode:Baofeng UV 3R
Connecting and read wrong data (incompatable format for Uv-B5 )
OEM Soft: OK
UV B5 ver 1.09 ( OS Win 7 64) - can Read & Write to radios
Updated by Fred Goldstein almost 10 years ago
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.
Updated by Jim Unroe almost 10 years ago
How about a debug.log file from both of you?
Jim KC9HI
Updated by Fred Goldstein almost 10 years ago
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'
Updated by Jim Unroe almost 10 years ago
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
Updated by Richard Menedetter over 9 years ago
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!
Updated by ken sato over 9 years ago
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 ?)
Updated by Ron Patten over 9 years ago
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.
Updated by Andrew Martin about 9 years ago
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
Updated by Bernhard Hailer over 4 years ago
- Status changed from New to Closed
- Target version set to chirp-legacy
- Platform changed from Windows to All
This was fixed in 2017.