<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I disagree with the recommendation for RT Systems cables. They employ FTDI USB to serial TTL chips which have been reprogrammed with <b class="">non-standard Vendor IDs and Product IDs</b>.<b class=""> </b>Their cables are no better or more reliable than any good quality cable using a standard (non-counterfeit) USB-to-serial chip. They are just a necessary evil in order to use RT Systems software and a poor choice for use with CHIRP.<div class=""><div class=""><br class=""></div><div class="">From <a href="http://chirp.danplanet.com/projects/chirp/wiki/CableGuide_FTDI_OEM_Cables" class="">http://chirp.danplanet.com/projects/chirp/wiki/CableGuide_FTDI_OEM_Cables</a> :</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><span style="font-size: 15px;" class="">Some cable vendors use the FTDI serial chip in their USB radio cables,
but have changed the chip's ID codes so that the cable will not be
recognized as a generic serial communications port. By default CHIRP
(and some other software) will not be able to use these cables because
CHIRP needs a serial port. Most notably RT Systems sells such cables. </span></blockquote></div><div class=""><br class=""></div><div class="">The article at the link shown above goes on to say:</div><div class=""><br class=""></div><div class=""></div><blockquote type="cite" class=""><div class=""><span style="font-size: 15px;" class="">[To] use such a cable with CHIRP there are two options. You can either
get your computer to recognize the OEM cable as a generic serial port
by tweaking the driver setup, or you can change the cable to use the
default FTDI codes, so the standard FTDI driver present in most
operating systems will recognize the cable and create a standard serial
port.</span></div></blockquote><div class=""><br class=""></div><div class="">The first option may “break” after an OS upgrade and the second option leaves the expensive cable unusable with RT Systems software, which was the whole reason why it cost more in the first place. It’s even uglier under some versions of Windows and OS X; those interested in learning more can read what’s on the official CHIRP website.</div><div class=""><br class=""></div><div class="">I spent $6.99 on a cable for my BaoFeng handheld, $8.99 on a cable for my Kenwood TM-281 mobile, and $14.99 on a cable for my Yaesu FT-2900R mobile, all from Amazon with free one or two day shipping. Total spent: $30.97. The first two use Prolific chips and the latter uses an FTDI chip. They have worked flawlessly under OS X and Windows 10, requiring no mucking around with drivers or reprogramming of the chips embedded in the cables. Buying RT Systems cables for those radios would have set me back $113.04 with equivalent 2-day shipping. That’s an $82 difference — and I can think of a lot of ham-related goodies to spend $82 on.</div><div class=""><br class=""></div><div class="">73,</div><div class=""> Fred Maxwell</div><div class=""> KM4QLB</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div><blockquote type="cite" class=""><div class="">On Mar 16, 2016, at 11:34 PM, kc6iih via chirp_users <<a href="mailto:chirp_users@intrepid.danplanet.com" class="">chirp_users@intrepid.danplanet.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class=""><div class=""><div class="">The best and most reliable cables come from <a href="http://www.rtsystems.com" class="">www.rtsystems.com</a></div><div class="">Yes they are not cheap but they work every time.</div><div class=""><br class=""></div><div class=""><br class=""></div><div style="font-size:10px" class="">Jock A. Soutar </div><div style="font-size:10px" class="">KC6IIH</div><div style="font-size:10px" class="">Sent via the Samsung Galaxy S™ III, an AT&T 4G LTE smartphone</div><br class=""><br class=""><div class="">-------- Original message --------</div><div class="">From: John Randle <john.randle@tds.net class=""> </john.randle@tds.net></div><div class="">Date:03/16/2016 7:03 PM (GMT-08:00) </div><div class="">To: <a href="mailto:chirp_users@intrepid.danplanet.com" class="">chirp_users@intrepid.danplanet.com</a> </div><div class="">Subject: Re: [chirp_users] BAOFENG UV-5Rs acting strange when programming
with Chirp </div><div class=""><br class=""></div>For what it is worth, I think I have isolated the second problem to a <br class="">"defective" USB cable. While the "defective"cable requires the older <br class="">driver (as do my other two "non-defective" cables) and does a download <br class="">and upload without issues, this is the only cable that then causes the <br class="">radio to go into transmit after uploading a configuration file ... <br class="">followed by the normal power off/power on of the radio. Disconnecting <br class="">the cable immediately after the power off seems to preclude the <br class="">erroneous transmit indication.<br class="">The first problem is still a puzzler. While the workaround of resetting <br class="">the fields is acceptable, I am still curious as to why/how this was <br class="">suddenly manifested as my UV5Rs are several years old.<br class="">--<br class="">John<br class="">73's de K9RSQ<br class=""><br class="">On 3/14/2016 11:50 PM, John Randle wrote:<br class="">> I have been maintaining several UV5R's with Chirp for a couple of <br class="">> years without any issues.<br class="">> I am currently running Chirp Daily Build 20151126 on W10 to program <br class="">> several UV5R's. I have recently experienced two strange programming <br class="">> operation issues, with all the UV5R's, that I have not previously <br class="">> encountered.<br class="">> First problem: After downloading the current configuration of the <br class="">> UV5R's, I then proceeded to add some new memory channels that use <br class="">> Digital Coded Squelch settings.<br class="">> When programming the DCS settings, I first set "DTCS", then I set the <br class="">> individual T-DCS and R-DCS codes and then I set Cross to "Tone -> <br class="">> Tone" (as this is what the existing DCS memory channels reflect), but <br class="">> as soon as I set the offset direction, Chirp changes "DTCS" to "Cross" <br class="">> and changes "Tone -> Tone" to "DTCS->". As these settings are not what <br class="">> is required (or at least what is currently reflected in the older DCS <br class="">> memory channels), I then have to go back and reset "DTCS->" to "Tone <br class="">> -> Tone" and "Cross" to "DTCS". Is there any reason why my initial <br class="">> inputs are being over-ridden?<br class="">> Second problem: After successfully uploading a new configuration to <br class="">> the UV5-R's, the UV5R's automatically go into transmit mode about 5 <br class="">> seconds after they restart if the programming cable is left connected <br class="">> to the radio. This seems to be a new issue that I had not previously <br class="">> experienced.<br class="">> Any suggestions on either problem will be greatly appreciated.<br class="">> -- <br class="">> John<br class="">> 73's de K9RSQ<br class="">><br class=""><br class="">_______________________________________________<br class="">chirp_users mailing list<br class=""><a href="mailto:chirp_users@intrepid.danplanet.com" class="">chirp_users@intrepid.danplanet.com</a><br class="">http://intrepid.danplanet.com/mailman/listinfo/chirp_users<br class="">This message was sent to Jock at kc6iih@aol.com<br class="">To unsubscribe, send an email to chirp_users-unsubscribe@intrepid.danplanet.com<br class=""></div>_______________________________________________<br class="">chirp_users mailing list<br class=""><a href="mailto:chirp_users@intrepid.danplanet.com" class="">chirp_users@intrepid.danplanet.com</a><br class="">http://intrepid.danplanet.com/mailman/listinfo/chirp_users<br class="">This message was sent to Fred at _chirp@mail2fm.com<br class="">To unsubscribe, send an email to chirp_users-unsubscribe@intrepid.danplanet.com</div></blockquote></div><br class=""></div></div></div></div></div></div></div></div></div></body></html>