[chirp_users] BAOFENG UV-5Rs acting strange when programming with Chirp
I have been maintaining several UV5R's with Chirp for a couple of years without any issues. I am currently running Chirp Daily Build 20151126 on W10 to program several UV5R's. I have recently experienced two strange programming operation issues, with all the UV5R's, that I have not previously encountered. First problem: After downloading the current configuration of the UV5R's, I then proceeded to add some new memory channels that use Digital Coded Squelch settings. When programming the DCS settings, I first set "DTCS", then I set the individual T-DCS and R-DCS codes and then I set Cross to "Tone -> Tone" (as this is what the existing DCS memory channels reflect), but as soon as I set the offset direction, Chirp changes "DTCS" to "Cross" and changes "Tone -> Tone" to "DTCS->". As these settings are not what is required (or at least what is currently reflected in the older DCS memory channels), I then have to go back and reset "DTCS->" to "Tone -> Tone" and "Cross" to "DTCS". Is there any reason why my initial inputs are being over-ridden? Second problem: After successfully uploading a new configuration to the UV5-R's, the UV5R's automatically go into transmit mode about 5 seconds after they restart if the programming cable is left connected to the radio. This seems to be a new issue that I had not previously experienced. Any suggestions on either problem will be greatly appreciated. -- John 73's de K9RSQ
For what it is worth, I think I have isolated the second problem to a "defective" USB cable. While the "defective"cable requires the older driver (as do my other two "non-defective" cables) and does a download and upload without issues, this is the only cable that then causes the radio to go into transmit after uploading a configuration file ... followed by the normal power off/power on of the radio. Disconnecting the cable immediately after the power off seems to preclude the erroneous transmit indication. The first problem is still a puzzler. While the workaround of resetting the fields is acceptable, I am still curious as to why/how this was suddenly manifested as my UV5Rs are several years old. -- John 73's de K9RSQ
On 3/14/2016 11:50 PM, John Randle wrote:
I have been maintaining several UV5R's with Chirp for a couple of years without any issues. I am currently running Chirp Daily Build 20151126 on W10 to program several UV5R's. I have recently experienced two strange programming operation issues, with all the UV5R's, that I have not previously encountered. First problem: After downloading the current configuration of the UV5R's, I then proceeded to add some new memory channels that use Digital Coded Squelch settings. When programming the DCS settings, I first set "DTCS", then I set the individual T-DCS and R-DCS codes and then I set Cross to "Tone -> Tone" (as this is what the existing DCS memory channels reflect), but as soon as I set the offset direction, Chirp changes "DTCS" to "Cross" and changes "Tone -> Tone" to "DTCS->". As these settings are not what is required (or at least what is currently reflected in the older DCS memory channels), I then have to go back and reset "DTCS->" to "Tone -> Tone" and "Cross" to "DTCS". Is there any reason why my initial inputs are being over-ridden? Second problem: After successfully uploading a new configuration to the UV5-R's, the UV5R's automatically go into transmit mode about 5 seconds after they restart if the programming cable is left connected to the radio. This seems to be a new issue that I had not previously experienced. Any suggestions on either problem will be greatly appreciated. -- John 73's de K9RSQ
On Mon, Mar 14, 2016 at 11:50 PM, John Randle john.randle@tds.net wrote:
I have been maintaining several UV5R's with Chirp for a couple of years without any issues. I am currently running Chirp Daily Build 20151126 on W10 to program several UV5R's. I have recently experienced two strange programming operation issues, with all the UV5R's, that I have not previously encountered. First problem: After downloading the current configuration of the UV5R's, I then proceeded to add some new memory channels that use Digital Coded Squelch settings. When programming the DCS settings, I first set "DTCS", then I set the individual T-DCS and R-DCS codes and then I set Cross to "Tone -> Tone" (as this is what the existing DCS memory channels reflect), but as soon as I set the offset direction, Chirp changes "DTCS" to "Cross" and changes "Tone -> Tone" to "DTCS->". As these settings are not what is required (or at least what is currently reflected in the older DCS memory channels), I then have to go back and reset "DTCS->" to "Tone -> Tone" and "Cross" to "DTCS". Is there any reason why my initial inputs are being over-ridden?
If you want to use 2 different DCS codes, then you must set the following in this order:
Tone Mode = Cross Cross Mode = DTCS->DTCS DTCS Code = {TX DCS code} DTCS RX Code = {RX DCS code}
When you set Cross Mode = Tone->Tone, you are programming CTCSS tones. If the existing channels reflect this, then it is the Tone and ToneSql columns are being used and the DTCS columns mean nothing.
This is the way it has always been. See the guides at section 6.1 and 6.2 of this page.
http://www.miklor.com/COM/UV_CHIRP.php#guides
Second problem: After successfully uploading a new configuration to the UV5-R's, the UV5R's automatically go into transmit mode about 5 seconds after they restart if the programming cable is left connected to the radio. This seems to be a new issue that I had not previously experienced.
You most likely have a programming cable with a Prolific type chip and the device driver got upgraded (perhaps during an in-place upgrade to Windows 10?). Since around 2008, the Prolific driver installed by Windows is (intentionally) incompatible with counterfeit Prolific type chips. You will have to downgrade to the Prolific v3.2.0.0 device driver that was available before the decision to make them incompatible (2007).
http://www.miklor.com/COM/UV_Drivers.php
Other solutions would be to... - get a programming cable with an FTDI chip - convert your programming cable to one with a CP2102 chip
http://www.miklor.com/COM/UV_ProgrCable.php
Any suggestions on either problem will be greatly appreciated.
John 73's de K9RSQ
Jim KC9HI
participants (2)
-
Jim Unroe -
John Randle