<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>I use FTB Commander in Windows for my FT60 and have to use the alternative write method. </div><div>Don't think it's the program but my old Radio Shack USB to DB9 cable. The drivers were for </div><div>Windows 2000 because the cable is so old circa 1998. But managed to get it to work in Windows 7.</div><div><br></div><div>I have no problems whatsoever with a genuine Prolific 2303 on Mac OS-X 10.8.3, Chirp 3.1 with</div><div>and 3 Chinese radios I have although the reads and writes are slow. </div><div><br></div><div>Don't know why I have to set FTB to alternative write, probably because the age of the drivers. </div><div>But I also use it with a Yaesu 8900 and FT8900 Commander software and read and write need</div><div>no special considerations. So it may be that the FT60 is a little picky, who knows but hop you</div><div>get it sorted. </div><br><div>
<div><b style="color: rgb(0, 86, 214); "><i><font style="font-size: 14px; ">Sent from my 15.4" MacBook Pro, i7 quad core</font></i> </b></div>
</div>
<br><div><div>On May 26, 2013, at 1:16 PM, Marcia Stockton <<a href="mailto:radio@frontier.com">radio@frontier.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<div bgcolor="#FFFFFF" text="#000000">
I could use some help figuring out how to make this work. I have
tried everything I could think of for 2 days before asking for
help. <br>
<br>
In summary, Chirp 0.3.1 and 0.1.12 will receive configuration data
from the Yaesu FT-60 radio, but will not send chirp image data back
to the radio to configure it. Permissions on the serial device
/dev/ttyS0 are correct: crw-rw---- allowing the dialout group to
read/write the serial port, and my userid is a member of the dialout
group. <br>
<br>
The steps I tried are listed below. (Pardon me for the length of
the problem-solving narrative but I decided to include a number of
false steps and time-consuming problems due to incomplete or
erroneous or confusing documentation, in case these are fixable
issues, so that others might avoid these troubles.)<br>
<br>
Thanks for any help you can give.<br>
<br>
73,<br>
Marcia NU6N<br>
<br>
----------------Tried to Solve the Problem Myself------------------<br>
<br>
OS = Linux Mint 12<br>
<br>
First, installed chirp package from Ubuntu ppa repository (Linux
Mint is a Ubuntu derivative and Ubuntu packages almost always work
fine): <code><br>
<br>
sudo apt-add-repository ppa:ubuntu-hams-updates/ppa
sudo apt-get update
sudo apt-get install chirp</code>
<blockquote> </blockquote>
What I got was a downlevel chirp 0.1.12. Tested it and chirp 0.1.12
successfully read from the radio. <br>
<br>
The problem occurs repeatably whenever I try to upload from chirp to
the radio. The cable should be OK because it was purchased from
Yaesu and has worked before in both directions with Yaesu-provided
rig programming software on the same laptop, back when we ran
Windows on this laptop. The serial port on the laptop works fine
when communicating with the HF rig. <br>
<br>
And one should try the latest version before asking for help, as the
Yaesu FT-60 support might be more complete in the current version,
based on differences in the test reports for the two versions ("Test
report for CHIRP version 0.1.12" (<a class="moz-txt-link-freetext" href="http://chirp.danplanet.com/download/0.1.12/Test_Report.html">http://chirp.danplanet.com/download/0.1.12/Test_Report.html</a>
shows all functions supported on FT-60 except "clone"; whereas clone
is listed as supported on the current beta release 0.3.1 <a class="moz-txt-link-freetext" href="http://chirp.danplanet.com/download/0.3.1/Model_Support.html">http://chirp.danplanet.com/download/0.3.1/Model_Support.html</a>).
<br>
<br>
I downloaded the 0.3.1 tarball and manually installed it (<code>sudo
python setup.py install)</code>. I presumed that the necessary
libraries were already present as a result of the previous
installation of chirp 0.1.12. The manual installation <code></code>produced
error messages and chirpw would not run (i.e. was not installed in a
way that allowed it to be run from any directory or menu.) <br>
<br>
However, per the instructions, running chirp 0.3.1 directly from the
directory it was unzipped to, via ./chirpw command, worked OK ...
except that upload to radio still didn't work. <br>
<br>
To rule out the possibility of a conflict with code that could have
been left over from the 0.1.12 install, I removed chirp 0.1.12 using
apt-get remove chirp. Then I manually deleted all files and
directories that had been created by the attempted manual install of
chirp 0.3.1. <code></code><br>
<br>
So at this point I am starting over attempting a clean manual
install of chirp 0.3.1 from the downloaded tarball. Following the
instructions at
<a class="moz-txt-link-freetext" href="http://chirp.danplanet.com/projects/chirp/wiki/Running_Under_Linux">http://chirp.danplanet.com/projects/chirp/wiki/Running_Under_Linux</a><br>
to ensure all prerequisite libraries are present, <br>
<br>
sudo apt-get install python-gtk python-serial python-libxml2<br>
<br>
produced an error message: Package 'python-gtk' has no installation
candidate. <br>
<br>
I ran apt-get update but still no python-gtk. I then ran a complete
sudo apt-get upgrade on my system to ensure all my
repository-provided software is up to date. <br>
<br>
After web research I learned there is no longer a python-gtk but
there is a python-gtk2, and it is already installed on my system,
and is the newest version. <br>
<br>
I unpacked chirp 0.3.1 and again ran chirp from inside the directory
where it was unpacked. (Did not attempt to run the python installer
this time.) <br>
<br>
Again chirp 0.3.1 ran, with the same results as before: Chirp can
receive data from the FT-60 radio, but when data from chirp cannot
be sent to the radio. <br>
<br>
Note that I carefully followed the special sequence instructions
required for Yaesu radios, always putting the receiving device into
receive mode first, before initiating transmit on the other device.
Thus, when attempting to send a couple of memories from chirp to the
radio, I did the following, which I believe was correct:<br>
<br>
a. Put the FT-60 into clone mode with the cable connected to the
mic/sp port, by powering on while holding the MONI button. Turn the
large knob until 'F8 CLONE' appears. Press F/W key. Radio restarts
displaying CLONE. Put radio into Rx mode by pressing MONI. Radio
displays ---Rx--- and waits to receive data from chirp. <br>
<br>
b. On Chirp, select Radio then Upload to Radio. The port, vendor
and model are set to the same values that work for receiving data
from the radio, i.e.: <br>
/dev/ttyS0, Yaesu, FT-60. Click OK to begin transmitting to the
radio. <br>
<br>
c. Chirp's prompt appears showing that Chirp is attempting to
transmit to the radio. After a short timeout, error message
appears:<br>
"An error has occurred. Failed to communicate with radio: Radio
did not respond." (Note that the radio still displays ---Rx--- ). <br>
<br>
Chirp Help, About shows the following: <br>
<br>
Chirp 0.3.1<br>
GTK 2.24.6<br>
PyGTK 2.24.0<br>
Python 2.7.2+<br>
<br>
---------------------------------------------------------------------------------------------------------<br>
<br>
<br>
<br>
<br>
<br>
<br>
</div>
_______________________________________________<br>chirp_users mailing list<br><a href="mailto:chirp_users@intrepid.danplanet.com">chirp_users@intrepid.danplanet.com</a><br>http://intrepid.danplanet.com/mailman/listinfo/chirp_users<br></blockquote></div><br></body></html>