CHIRP

Further info:

1) The issue is 100% reproducible (i.e. this is always the error that shows; I can't get past this point)
2) I was expecting it to download the radio template

Tested with Baofeng's software, and a very similar phenomenon is experienced. So, it's looking like the radio or cable might be at issue.

I am using the 3.2.0.0 cable driver software, so my guess is the radio is defective, sadly. Any generous advice would be most appreciated (as in, has anyone ever seen this issue before, or am I just lucky?)

Thanks for all your work on software that I hope to try one day - I hear its great!

Measured 5V RS232 data on 3.5mm sleeve from PC with scope - works.
Reset Baofeng to factory default.
Verified plug into Baofeng mounts flush.

Still can't get the Baofeng to do anything but reset when trying to communicate with Chirp or the Baofeng software.

Justin,
This has typically been a common problem for the Baofeng UV-5R but seems to be showing up more often for the UV-B5 lately.

This is an issue of the plug not being fully plugged into the socket of the radio. Leave the programming cable unplugged from the radio and then try to download. You will get the same error message without a radio.

Look at the socket in the radio. The 2 holes in the rectangular recess are not centered front to back in the recess. They are positioned more to the rear of the radio. This can cause the shell of the plug to rub the back wall of the recess and this can keep the plug from being fully inserted into the radio. Sometimes the plug can be wiggled while firmly pushing to get it to go the rest of the way. Some have had to shave some of the plastic shell off of the plug to get it to fully seat in the radio. See the Miklor.com website.

http://www.miklor.com/UVB5/UVB5-ErrorMess.php#error1

Jim KC9HI

Jim,

Thanks for taking the time to respond, especially when it is clearly not your software at issue here!

I am 99% sure the radio is at fault now. The plug is fully seated in the jacks (there isn't a clearance issue on this particular radio). Also, when I send random characters (via a terminal emulator) to the radio, it doesn't do anything (as expected). But when I use either Chirp or the Baofeng software, whatever command is sent resets the radio every time. So, the radio seems to be getting the 'message', but has some kind of issue with it.

I am going to hold on to the radio a couple more days to see if Baofeng responds and then send it back to Amazon. I will hold on to the existing cable I have so that when I order another one, I will be able to test whether it was indeed the radio or the cable. I will let you know what it ends up being for your reference (though it may be several weeks before I get a new one). I will respond to this issue if it is still open, or if not I'll send you an email.

Thanks again for your assistance, sir!
-Justin

Jim, Justin, et al.

I have seen the same issue and error message with the build 1031daily build.

However, it does not occur with the 0505daily build. It will download and operate correctly.

Can someone send me a link or tell me how I can download the 0505 daily build to test? The oldest I can find on the repository is 1010. Thanks!

0505 daily build exhibited the same issue as all other builds tested; I will be returning the radio.

I compared the code between the 20130505 and 20131031 daily builds and there is no difference in the code that would provide this error.

There are only three reasons that I can think of that would cause this error:

1. The radio did not respond. This could be a problem with the programming cable, a problem with the radio or a problem with the connection between the two.

2. The radio responded, but responded with an unexpected "ack" value. Both releases expect the same "ack" value so both releases would report the same error.

3. The radio responded, but responded too slowly.

There isn't anything that can be done to CHIRP to remedy #1. Since the radio also does not work with the Baofeng software, it isn't very likely that #2 or #3 are the cause of the error.

Jim KC9HI

FWIW,
I was having a tough time getting a new radio (BJ-UV55, uv5r clone) to respond to the initial sequence of bytes (ident interrogation?), but the oem software worked. I eventually solved by putting some tiny delay in writing each byte of sequence instead of just sending it at once.

I do realize this is different from the above described case where the oem software isnt working, but there is a chance this might increase stability/success in reading across different radios.

I.e., if nothing else, you could try this on for an experiment:

replace:
@ radio.pipe.write("PROGRAM")@
with:
@ for c in "PROGRAM":
radio.pipe.write(c)
time.sleep(0.01)@

Jens,
This is definitely worth trying out.
Jim

I have noticed this with the B5 as well. In some cases I would try again and it would work. Some times it takes two or three times to get to work.

I cannot say that the connector or wire moved or not. Once it connects it seems to keep working fine. In one case I tried with CHIRP and it did not work. I then tried with the B5 software and it did work. When I went back to CHIRP it worked.

I'm not sure what this tells you but I do hop it helps.

Thanks, Nick. I bought another B5 from another vendor and have the same issue. I was thinking about buying the 'official' Baofeng cable (as this is the only thing left to test). Any particular cable recommendations would be welcome.

I "think" I have the "official" cable. I bought mine from http://www.amazon.com/gp/product/B008RZJHJU/ref=oh_details_o02_s00_i00?ie=UTF8&psc=1

But note that even though it says "By Baofeng" it is sold via other sellers (the one I bought from is not listed). SO in retrospect I'm not sure if it is official or not.

Having an "official" programming cable means nothing. It will still have an unauthorized copy of the Prolific chip in it. No matter what USB programming cable you get, it will require a compatible driver or NO SOFTWARE WILL WORK.

When you have a programming cable with an unauthorized copy of the Prolific chip in it (most USB programming cables) and you are running Windows, you MUST INSTALL AN OLDER DRIVER. Vista and above in most cases will upgrade the driver to the latest none-the-less. Because of this, you will have to go into Device Manager to select the older one. These are the required driver versions:

XP: v2.0.2.1
Vista/7/8: V3.2.0.0

The miklor.com website has links to these drivers and instruction on how to install them.

http://www.miklor.com/COM/UV_Drivers.php

There are sources for programming cables with genuine Prolific chips in them. These will run fine with the automatically installed latest Prolific driver. Another solution is to get a programming cable with an FTDI chip in it. Both will cost more but it may be worth the extra money for some.

Jim KC9HI

I updated the B5 today and it took on the first try. I don't believe that it is random... I just can't see the pattern yet.

I have the same problem with my new RST567. It works perfectly with the TDX-B5 download, however, so it's not a hardware issue. Annoying, because the CHIRP software was included with the cable.

BTW, all installation protocols were followed. I have a TYT and know to be rigid about the software installation process with the Oriental products.

I had the exact same problem with my new 27 menu item UV-B5. The crappy stock software worked fine but Chirp would have the Ack error every time. The cable that I had was a Prolific PL2303 and nothing would work even using the older v3.2.0.0 Prolific driver, even following the directions at http://www.miklor.com/COM/UV_Drivers.php#install exactly.

So it is a problem with Chirp, not the Prolific driver, as the stock software works fine.

I ended up using a cheap ebay CP2102 USB Serial adapter that I had lying around, using the Silicon Labs CP210x driver v 6.7.0.0 that was installed automatically by Win7 64bit. I used the info at http://www.miklor.com/COM/UV_ProgrCable.php to wire the cable. The wires were the wrong way around, I had to connect Red to RX, White to TX and Black to GND.

Anyway, after all that, Chirp works fine, although it does still come up with the "Radio NAK'd block at address 0xF010" error, which I ignored as it says to at http://www.miklor.com/COM/UV_ErrorMess.php#error9

Had the same problem. UV-B5 with 29 menu items worked, two new Pofung UV-B5 radios with 27 menus gave the error "Radio did not ack programming mode" using daily-20150814 build. Downloaded latest daily-20160301 build and was able to download and upload after a couple of tries.

Using Linux Ubuntu 14.04 and generic 2 prong programming cable.