[chirp_users] "Most unusual" "Radio did not ack programming mode"
rfhaney at gmail.com
Tue Jun 10 18:43:45 PDT 2014
Thanks for your comments. I'll plan to review them soon. But please also
note my recent comment regarding my most recent success in using OEM
software to upload/download the channel programming to my computer.
As for upload/download terminology, I think typical usage varies by
context. I think it's a lot like the Big-Endian/Little-Endian issues of
Gulliver's Travels. It's my impression that the only reason that the north
pole is generally regarded as the "top" of the world is that Europeans live
in the northern hemisphere and have had the most influence regarding
orientated views of the earth. Otherwise maps might commonly have the
south pole near the top of every map.
On Tue, Jun 10, 2014 at 6:14 PM, Jim Unroe <rock.unroe at gmail.com> wrote:
> On Tue, Jun 10, 2014 at 7:45 PM, Richard Haney <rfhaney at gmail.com> wrote:
>> In uploading and downloading radio images I got a few of the following
>> error messages:
>> An error has occurred
>> Radio did not ack programming mode
>> I supposedly solved those problems and now it seems the the problem may
>> be permanent. Or is it? I found the comments about such error messages,
>> including that the error is a "very common problem".
> Yes very common problem. It is usually caused by a poor connection between
> the radio and programming cable or by a device driver installed in the OS
> that is incompatible with the USB-to-Serial chip in the programming cable.
> A good way to demonstrate this issue is to leave the programming cable
> unplugged from the radio and then try to download from it using CHIRP. You
> will get the "Radio did not ack programming mode" error. This is not a
> problem with CHIRP. It is just reporting that it isn't receiving a signal
> back from the radio.
>> Well, I then took heed and special care to apply pressure to the plug
>> when I undertook these operations. I then achieved both an upload to the
>> computer and a subsequent download to the radio with a new programming of
>> memory channels. But a few times I also occasionally forgot to turn off
>> the radio before unplugging (and possibly plugging in) the plug for the
>> radio. So I suspect that some very delicate parts may have been damaged.
>> I hope not. But if so, I hope it's damage to some electronics in the
>> cable assembly and not in the radio itself. (The cable is cheaper to
>> replace and may even be easier to repair.)
> You obviously have the connection issue. Now that it doesn't work at all,
> you may also have a driver issue. If you have a programming cable with an
> unauthorized copy of a Prolific chip (most programming cables sold to be
> used with Chinese radios do) and using Windows Vista, 7 or 8, you must use
> the Prolific driver version 22.214.171.124. These versions of Windows can
> automatically update to the latest Prolific driver (especially if you plug
> it into a different USB port) which will disable the programming cable. You
> will need to downgrade the driver back to v126.96.36.199. See this guide
>> But I am also dismayed that the system seems to be so temperamental. I
>> would think that basic engineering design principles would be employed to
>> guard against very common errors.
> Have you forgotten that this is a $35 radio?
>> Anyway, I was able both to upload the radio's image to the computer and
>> to download a revised channel-memory to the radio, a Baofeng UV-B5.
> Just to be clear... CHIRP "downloads" to the computer and "uploads" to the
>> Then I noticed that I could not change the SHIFT direction in channel
>> mode. (I got the impression from something I read in a miklor.com web
>> page that I should be able to modify the SHIFT direction in channel mode.)
>> I suspected that the failure of the radio to perform such a SHIFT update
>> was a sign of corrupted memory in the radio. So I downloaded the
>> factory-settings image "UV-B5(factory).img" to the radio as recommended
>> to resolve memory corruption problems.
> You radio is working properly. You cannot change the SHIFT direction in MR
> mode. You have to setup the parameters in VFO mode and then write it to the
> channel that you wish to update. The page in the miklor.com web page is
>> I think I also either unplugged or plugged in the cable to the radio
>> while the radio was still on. Anyway, ever since then I have not been able
>> to either upload an image from the radio or download an image to the radio.
>> But I did use the CHIRP display of channel assignments to manually program
>> the radio's channels, and the radio does not seem to have any problems that
>> I've noticed other than the inability to upload and download radio images.
> I insert and remove the plug of programming cables into my radios with
> them powered up all the time. Sure, it is probably a good idea to have them
> shut off, but I more often than not don't. I'm not saying that you can't
> damage a radio by leaving it on, I'm just saying that I haven't managed to
> damage one yet.
>> As for the supposed corruption of the radio's memory, I see in menu item
>> 21 that the manual says the radio should be in "VFO mode" (i.e.,
>> "frequency" mode) in order to change the SHIFT direction. So it appears
>> that the only way to manually change a channel's SHIFT direction is to
>> reprogram the channel from scratch (essentially in frequency mode) and then
>> load the combined collection of preset parameters into a channel.
> This is correct. Generally once your SHIFT direction is set, you wouldn't
> want/need to change it.
>> Anyway, please, please, somebody, tell me all is not lost and that there
>> is an easy fix for this problem.
> I would recommend that you ...
> - check to make sure that you still have a compatible device driver
> - borrow or purchase another programming. If you can afford it, go with
> one having a FTDI USB-to-Serial chip. I even build one for $5 using a
> CP2102 module http://www.miklor.com/COM/UV_Technical.php#progcable
> - perform a RESET (power on the radio while pressing the MENU key, choose
> ALL and then ENTER)
>> Incidentally, I would like to know what is the exact nature of the more
>> usual problem that causes the "Radio did not ack programming mode"
>> error. Is it a failure of physical contact of conductors in the
>> connection? Or is there some some sort of electronic memory effect, such
>> as wayward capacitance associated with the connection. Or is there erratic
>> resistance of some sort in that circuit. An answer to that question may
>> perhaps help with resolving what seems to have become the more persistent
>> version of that problem that I have now run into. I did inspect the
>> connection area and noticed a very slight raised bit of radio-case material
>> where the recommended cutaway of the plug would avoid a protruding "rub"
>> with the radio body near the connector, but the effect seemed to be
>> extremely minor. So I suspect there is some other problem related to the
>> connector perhaps via "unusual" erratic effect on sensitive semiconductors
>> connected to the sockets.
> There is not exact nature. It can (and probably is) a combination of
> things that together result in failure
> - device driver issues
> - variations of the sockets in the case
> - interference of the plug's shell with the case
> - variations of the pins of the plug
> - device driver issues
>> As for my (I now think erroneous) impression that it is possible (by
>> intent of design at least) to modify the SHIFT direction in channel mode, see
>> this page <http://www.miklor.com/UVB5/UVB5-ProgMem.php> and note that
>> "Enter 'SHIFT' " immediately follows "- Press [VM/SCAN] to enter channel
> This page is incorrect. You should do the steps in this order all in VFO
> - Enter "SHIFT"
> - Enter "OFFSET"
> - Enter "TCODE"
> - Enter Frequency
>> By the way the computer I'm using is a Dell XPS L502X running Windows 7
>> Home Premium, SP1.
> Windows 7 Home Premium 64-bit here.
> Jim KC9HI
> chirp_users mailing list
> chirp_users at intrepid.danplanet.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the chirp_users