Project

General

Profile

Actions

New Model #1209

closed

New UV-B5 "Radio did not ack programming mode"

Added by Justin Muessig over 10 years ago. Updated about 8 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
10/30/2013
Due date:
% Done:

0%

Estimated time:
Equipment Loan/Gift Offered:
No
I read the instructions above:

Description

When trying to connect to UV-B5 (Radio -> Download from radio), I get the "Radio did not ack programming mode" message. The radio then apparently 'resets' (all characters on the LCD screen turn ON, then it returns to the 'base' screen).

Is there a command I can put directly into a terminal program (such as termite) that could help determine where the issue lies? From what I can tell, it appears that the cable / com port are working correctly.

Much appreciated.

Baofeng UV-B5 (newly purchased via Amazon about 3 weeks ago)
Win7 x64
Daily Build 10-27 and 10-11 tested with same result


Files

debug.log (6.49 KB) debug.log Justin Muessig, 10/30/2013 10:48 AM
IMG_7764.JPG (2.81 MB) IMG_7764.JPG Justin Muessig, 10/30/2013 10:48 AM
Actions #1

Updated by Justin Muessig over 10 years ago

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

Actions #2

Updated by Justin Muessig over 10 years ago

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!

Actions #3

Updated by Justin Muessig over 10 years ago

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.

Actions #4

Updated by Jim Unroe over 10 years ago

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

Actions #5

Updated by Justin Muessig over 10 years ago

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

Actions #6

Updated by Matthew Crawley over 10 years ago

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.

Actions #7

Updated by Justin Muessig over 10 years ago

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!

Actions #8

Updated by Justin Muessig over 10 years ago

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

Actions #9

Updated by Jim Unroe over 10 years ago

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

Actions #10

Updated by Jens Jensen over 10 years ago

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)@

Actions #11

Updated by Jim Unroe over 10 years ago

Jens,
This is definitely worth trying out.
Jim

Actions #12

Updated by Jens Jensen over 10 years ago

  • Status changed from New to Rejected

Want to note here that I have observed this behavior with my UV-B5 and a "Baofeng" (i.e., PL2303 "fake") adapter, on my "hackintosh" (OSX 10.7.5).
I have narrowed this down to certain usb ports on my machine are more reliable with this setup than others.

One my front panel ports, i have about a 50% success rate in downloading without this error. I note that I also see occasional errors from oem software (running under wine), when using these ports.

When I switched to a usb hub connected to rear ports, I have nearly 100% success rate on both chirp and oem software.

So for posterity, if you are seeing inconsistent results, try:

  1. switching to different usb port or group of ports
  2. try different cable
  3. try oem software as a control

Going to close this issue out for now.
You may want to take the discussion further with other UV-B5 owners on yahoo groups uvb5 or on chirp-users mailing list.

Actions #13

Updated by Nick Kemp about 10 years ago

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.

Actions #14

Updated by Justin Muessig about 10 years ago

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.

Actions #15

Updated by Nick Kemp about 10 years ago

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.

Actions #16

Updated by Jim Unroe about 10 years ago

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

Actions #17

Updated by Nick Kemp about 10 years ago

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.

Actions #18

Updated by Carol Longmire almost 9 years ago

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.

Actions #19

Updated by Andrew Martin over 8 years ago

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

Actions #20

Updated by Neill Laney about 8 years ago

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.

Actions

Also available in: Atom PDF