[chirp_users] BAOFENG UV-5Rs acting strange when programming with Chirp

[Jim Unroe]

On Mon, Mar 14, 2016 at 11:50 PM, John Randle <john.randle at 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