[chirp_users] "Most unusual" "Radio did not ack programming mode"

Tue Jun 10 18:14:56 PDT 2014

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 3.2.0.0. 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 v3.2.0.0. See this guide

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

>
> 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
radio.

>
> 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
incorrect.

>
> 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
installed
- 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
> mode."
>

This page is incorrect. You should do the steps in this order all in VFO
mode...

- 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_users/attachments/20140610/d068c1ed/attachment.html 