[chirp_users] "Most unusual" "Radio did not ack programming mode"
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".
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.)
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.
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.
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.
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.
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.
Anyway, please, please, somebody, tell me all is not lost and that there is an easy fix for this problem.
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.
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."
By the way the computer I'm using is a Dell XPS L502X running Windows 7 Home Premium, SP1.
You pays you money (zero $) and take your chance. There is no free lunch. Be thankful that some developers donate their extra personal time to make CHIRP available. If you want a better product, then I suggest you join the CHIRP development team to assist with better “basic engineering design.”
And just so you know, CHIRP is getting constantly better all the time thanks to hard work of donated software developers. If you do not like what CHIRP is providing for you in the way of an experience, then I suggest that you not use it.
Pete Mackie
On Jun 10, 2014, at 4:45 PM, Richard Haney rfhaney@gmail.com wrote:
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.
Hi Pete,
Please note that the comment of mine that you quote was intended to be in reference to the product(s) (the Baofeng UV-B5 and cable) I bought and not in reference to CHIRP. I'm sorry that my intention in that regard was not clear. It certainly seemed from what I knew at the time that the problem was with the hardware, and I thought that that was clear from my comments.
However, I now think the problem is a problem with CHIRP because I have been able to upload the HT's programming into the OEM software offered by miklor.com http://www.miklor.com/UVB5/UVB5-Software.php .
So Hooray! All is not lost! At least it seems I have not irreparably damaged the radio as I had feared.
But it does seem that a bug fix of CHIRP regarding the problem is in order. However, I have not checked whether this problem is already regarded as a bug that needs fixing.
Anyway, I thought folks would like to know in case anyone else is puzzled by this sort of problem.
Richard Haney
On Tue, Jun 10, 2014 at 5:11 PM, Pete Mackie pete@seaquest.com wrote:
You pays you money (zero $) and take your chance. There is no free lunch. Be thankful that some developers donate their extra personal time to make CHIRP available. If you want a better product, then I suggest you join the CHIRP development team to assist with better “basic engineering design.”
And just so you know, CHIRP is getting constantly better all the time thanks to hard work of donated software developers. If you do not like what CHIRP is providing for you in the way of an experience, then I suggest that you not use it.
Pete Mackie
On Jun 10, 2014, at 4:45 PM, Richard Haney rfhaney@gmail.com wrote:
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.
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
On Tue, Jun 10, 2014 at 9:05 PM, Richard Haney rfhaney@gmail.com wrote:
So Hooray! All is not lost! At least it seems I have not irreparably damaged the radio as I had feared.
That's good news.
But it does seem that a bug fix of CHIRP regarding the problem is in order. However, I have not checked whether this problem is already regarded as a bug that needs fixing.
Which version of CHIRP are you using? v0.4.0 or any recent daily build should be fine.
Now that you have the channels and settings saved using the Baofeng software, I would give the RESET a try. The UV-B5/B6 has a weird habit of changing it's cloning behavior based on the radio's settings (changing ACK values and IDENT strings were a real pain during the early development of the initial support).
Jim KC9HI
Thanks, Jim, for the suggestions.
The version of CHIRP I've been using is "chirp-daily-20140601-installer.exe".
This is on a Dell XPS L502X with Windows 7 Home Premium edition (with Service Pack 1), 64-bit. My USB ports are USB 3.0, but I've never had a problem with their being 3.0 instead of 2.0, except for a puzzling USB 3.0 flash drive I once tried, but as far as I know that problem could have been "anything"; I did not have time then to try to diagnose the problem; so I returned the flash drive back to the store for a refund.
In response to your suggestion, I tried the UV-B5's RESET as described in the manual, namely, turning on the radio while pressing and holding the [FM] button. But the radio did not seem to do any resetting. I surmise from the manual that I was supposed to get an option displayed of "VFO" (for frequency reset) and "ALL" (for resetting everything resettable). But I got nothing like that. And my channels were all still programmed as I had programmed them. (But before I did any of this I transferred the channel-programming data back to the UV-B5 from the OEM channel-programming software just to be sure I could do that without any problem.)
But in case there was some sort of subtle reset when I tried the RESET procedure, which conceivably might have resolved the original problem, I afterwards tried reading the UV-B5's channel info via CHIRP. But I still got the usual error message and no apparent transfer of data.
On Tue, Jun 10, 2014 at 6:25 PM, Jim Unroe rock.unroe@gmail.com wrote:
On Tue, Jun 10, 2014 at 9:05 PM, Richard Haney rfhaney@gmail.com wrote:
So Hooray! All is not lost! At least it seems I have not irreparably damaged the radio as I had feared.
That's good news.
But it does seem that a bug fix of CHIRP regarding the problem is in order. However, I have not checked whether this problem is already regarded as a bug that needs fixing.
Which version of CHIRP are you using? v0.4.0 or any recent daily build should be fine.
Now that you have the channels and settings saved using the Baofeng software, I would give the RESET a try. The UV-B5/B6 has a weird habit of changing it's cloning behavior based on the radio's settings (changing ACK values and IDENT strings were a real pain during the early development of the initial support).
Jim KC9HI
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
On Wed, Jun 11, 2014 at 2:19 PM, Richard Haney rfhaney@gmail.com wrote:
Thanks, Jim, for the suggestions.
The version of CHIRP I've been using is "chirp-daily-20140601-installer.exe".
This is on a Dell XPS L502X with Windows 7 Home Premium edition (with Service Pack 1), 64-bit. My USB ports are USB 3.0, but I've never had a problem with their being 3.0 instead of 2.0, except for a puzzling USB 3.0 flash drive I once tried, but as far as I know that problem could have been "anything"; I did not have time then to try to diagnose the problem; so I returned the flash drive back to the store for a refund.
In response to your suggestion, I tried the UV-B5's RESET as described in the manual, namely, turning on the radio while pressing and holding the [FM] button. But the radio did not seem to do any resetting. I surmise from the manual that I was supposed to get an option displayed of "VFO" (for frequency reset) and "ALL" (for resetting everything resettable). But I got nothing like that. And my channels were all still programmed as I had programmed them. (But before I did any of this I transferred the channel-programming data back to the UV-B5 from the OEM channel-programming software just to be sure I could do that without any problem.)
But in case there was some sort of subtle reset when I tried the RESET procedure, which conceivably might have resolved the original problem, I afterwards tried reading the UV-B5's channel info via CHIRP. But I still got the usual error message and no apparent transfer of data.
You've not done a RESET then. The manual's procedure is incorrect. That's
why I explained how to do it in my first reply (power-on while pressing the [MENU] button, select ALL with the "arrow" keys, then press [ENTER]).
Jim KC9HI
Many thanks, Jim, for clarifying the fact that the RESET directions in the Baofeng manual are incorrect. My usual presumption is that the manufacturer knows best, and so I consulted the manual. But when the procedure did not work with the [FM] button as described in the manual, I had the nagging feeling that I saw some similar directions somewhere involving the [MENU] button. But I was not sure whether that was in reference to some other piece of equipment or for doing some other type of operation, and I recall having the impression that that was something I should be careful about, and, based on experience, I figured it was a good idea to be cautious and to not go pressing buttons in "button-happy" fashion without more-definite knowledge on the matter.
Anyway, I realized that I had a miklor.com-alleged "no-issues" Windows-XP-specific driver http://www.miklor.com/COM/UV_Drivers.php installed on my Dell D800 laptop running Windows XP. So I tried using CHIRP on the D800 and it seemed to work fine, without any error messages.
So I installed the driver that miklor.com suggested http://www.miklor.com/COM/UV_Drivers.php for Win 7 on my Dell XPS. And then CHIRP worked fine on my Dell XPS (with Win 7) as well. So the problem is resolved. Hooray!
But it appears at least few items of info need to be corrected and/or clarified on the miklor.com http://www.miklor.com/COM/UV_Drivers.php web site in this connection.
One is that the lack of a yellow triangle with exclamation mark next the device indication in the device manager does not mean that a good cable driver is installed for the device, contrary to a statement in the miklor.com directions http://www.miklor.com/COM/UV_Drivers.php.
Another is the strong suggestion http://www.miklor.com/COM/UV_ErrorMess.php that the error message "Radio did not ack programming mode" is likely to be a hardware problem (provided the plug is plugged in to the radio and the radio is turned on). A natural presumption seemed to be that, due to miklor.com hardware suggestions and due to the erratic/haphazard then finally permanent nature of the problem, the problem was an intermittent hardware problem and not a driver issue. But it tuns out, surprisingly, especially regarding the intermittency, that that presumption is not a good one.
And a third item in need of correction http://www.miklor.com/UVB5/UVB5-ProgMem.php (or at least clarification) is the (erroneous) suggestion that the SHIFT direction can be modified in channel mode.
I'll plan to contact the miklor.com people about those items.
On Wed, Jun 11, 2014 at 12:01 PM, Jim Unroe rock.unroe@gmail.com wrote:
On Wed, Jun 11, 2014 at 2:19 PM, Richard Haney rfhaney@gmail.com wrote:
Thanks, Jim, for the suggestions.
The version of CHIRP I've been using is "chirp-daily-20140601-installer.exe".
This is on a Dell XPS L502X with Windows 7 Home Premium edition (with Service Pack 1), 64-bit. My USB ports are USB 3.0, but I've never had a problem with their being 3.0 instead of 2.0, except for a puzzling USB 3.0 flash drive I once tried, but as far as I know that problem could have been "anything"; I did not have time then to try to diagnose the problem; so I returned the flash drive back to the store for a refund.
In response to your suggestion, I tried the UV-B5's RESET as described in the manual, namely, turning on the radio while pressing and holding the [FM] button. But the radio did not seem to do any resetting. I surmise from the manual that I was supposed to get an option displayed of "VFO" (for frequency reset) and "ALL" (for resetting everything resettable). But I got nothing like that. And my channels were all still programmed as I had programmed them. (But before I did any of this I transferred the channel-programming data back to the UV-B5 from the OEM channel-programming software just to be sure I could do that without any problem.)
But in case there was some sort of subtle reset when I tried the RESET procedure, which conceivably might have resolved the original problem, I afterwards tried reading the UV-B5's channel info via CHIRP. But I still got the usual error message and no apparent transfer of data.
You've not done a RESET then. The manual's procedure is incorrect. That's
why I explained how to do it in my first reply (power-on while pressing the [MENU] button, select ALL with the "arrow" keys, then press [ENTER]).
Jim KC9HI
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
Richard,
I apologize for flaming on regarding the quality of the CHIRP radio memory management utility. I certainly misunderstood who your complaining about having a lack of good engineering.
That being said, the Chinese do not perform any “basic engineering design.” Instead, what they “sort of” do is copy someone else’s design with little or no true engineering discipline let alone exactly know what they are copying. This is how they can build a radio in China and then pay to ship it all the way to the US for distribution sales, for a price with profit of $35. What you get for this price is what you see and don’t expect any more.
If you pay $200 to $300 for a HT, even if its was designed and manufactured anywhere in Asia, then you would have a right to complain about the design quality, et al. And these level of Asian vendors all provide local to US support via email and direct telephone calls.
Pete
On Jun 10, 2014, at 6:05 PM, Richard Haney rfhaney@gmail.com wrote:
Hi Pete,
Please note that the comment of mine that you quote was intended to be in reference to the product(s) (the Baofeng UV-B5 and cable) I bought and not in reference to CHIRP. I'm sorry that my intention in that regard was not clear. It certainly seemed from what I knew at the time that the problem was with the hardware, and I thought that that was clear from my comments.
However, I now think the problem is a problem with CHIRP because I have been able to upload the HT's programming into the OEM software offered by miklor.com .
So Hooray! All is not lost! At least it seems I have not irreparably damaged the radio as I had feared.
But it does seem that a bug fix of CHIRP regarding the problem is in order. However, I have not checked whether this problem is already regarded as a bug that needs fixing.
Anyway, I thought folks would like to know in case anyone else is puzzled by this sort of problem.
Richard Haney
On Tue, Jun 10, 2014 at 5:11 PM, Pete Mackie pete@seaquest.com wrote: You pays you money (zero $) and take your chance. There is no free lunch. Be thankful that some developers donate their extra personal time to make CHIRP available. If you want a better product, then I suggest you join the CHIRP development team to assist with better “basic engineering design.”
And just so you know, CHIRP is getting constantly better all the time thanks to hard work of donated software developers. If you do not like what CHIRP is providing for you in the way of an experience, then I suggest that you not use it.
Pete Mackie
On Jun 10, 2014, at 4:45 PM, Richard Haney rfhaney@gmail.com wrote:
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.
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
Actually, I am amazed and impressed that Chinese technology seems to be getting better all the time. And although the UV-B5 manual definitely shows a quality-control issue, the radio itself seems to be rather excellent (at least for the price).
Perhaps Baofeng may have one or two rather expert engineers who supervise the technical engineering of the UV-B5, but I get the impression that these chief engineers may be far more capable than the people Baofeng assigns to writing the manuals. Well if Baofeng needs to economize in order to bring the price down to reasonable levels, I'm glad they are doing it in the writing of the manual.
I also get the impression that one reason that the UV-B5 is as good as it is for the low price it has, is that, as I think I read somewhere, the radio is basically a transceiver on a chip -- almost all of its electronics is an integrated circuit. As I understand it, ICs are generally far more reliable and far cheaper than equivalent "discrete-component" circuits. And it only takes one small, highly expert engineering team to come up with a superb, reasonably logical, intuitive design for an IC. Once that it done, it seems that, relatively speaking, producing quality radios for a mass market at a low price should be a piece of cake.
And the "generic", one-design-for-all-uses design of the chip and thus the radio obviously makes it possible to sell cheap radios to a larger market and thereby keep the price very reasonable.
As some reviewers have noted, the big-name producers of ham radios should take note.
On Tue, Jun 10, 2014 at 7:21 PM, Pete Mackie pete@seaquest.com wrote:
Richard,
I apologize for flaming on regarding the quality of the CHIRP radio memory management utility. I certainly misunderstood who your complaining about having a lack of good engineering.
That being said, the Chinese do not perform any “basic engineering design.” Instead, what they “sort of” do is copy someone else’s design with little or no true engineering discipline let alone exactly know what they are copying. This is how they can build a radio in China and then pay to ship it all the way to the US for distribution sales, for a price with profit of $35. What you get for this price is what you see and don’t expect any more.
If you pay $200 to $300 for a HT, even if its was designed and manufactured anywhere in Asia, then you would have a right to complain about the design quality, et al. And these level of Asian vendors all provide local to US support via email and direct telephone calls.
Pete
On Jun 10, 2014, at 6:05 PM, Richard Haney rfhaney@gmail.com wrote:
Hi Pete,
Please note that the comment of mine that you quote was intended to be in reference to the product(s) (the Baofeng UV-B5 and cable) I bought and not in reference to CHIRP. I'm sorry that my intention in that regard was not clear. It certainly seemed from what I knew at the time that the problem was with the hardware, and I thought that that was clear from my comments.
However, I now think the problem is a problem with CHIRP because I have been able to upload the HT's programming into the OEM software offered by miklor.com http://www.miklor.com/UVB5/UVB5-Software.php .
So Hooray! All is not lost! At least it seems I have not irreparably damaged the radio as I had feared.
But it does seem that a bug fix of CHIRP regarding the problem is in order. However, I have not checked whether this problem is already regarded as a bug that needs fixing.
Anyway, I thought folks would like to know in case anyone else is puzzled by this sort of problem.
Richard Haney
On Tue, Jun 10, 2014 at 5:11 PM, Pete Mackie pete@seaquest.com wrote:
You pays you money (zero $) and take your chance. There is no free lunch. Be thankful that some developers donate their extra personal time to make CHIRP available. If you want a better product, then I suggest you join the CHIRP development team to assist with better “basic engineering design.”
And just so you know, CHIRP is getting constantly better all the time thanks to hard work of donated software developers. If you do not like what CHIRP is providing for you in the way of an experience, then I suggest that you not use it.
Pete Mackie
On Jun 10, 2014, at 4:45 PM, Richard Haney rfhaney@gmail.com wrote:
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.
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
On Tue, Jun 10, 2014 at 7:45 PM, Richard Haney rfhaney@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
Hi Jim,
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.
Richard Haney
On Tue, Jun 10, 2014 at 6:14 PM, Jim Unroe rock.unroe@gmail.com wrote:
On Tue, Jun 10, 2014 at 7:45 PM, Richard Haney rfhaney@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
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
participants (3)
-
Jim Unroe -
Pete Mackie -
Richard Haney