[chirp_users] Yaesu FT-60 upload fails but download works
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.
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.
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.)
Thanks for any help you can give.
73, Marcia NU6N
----------------Tried to Solve the Problem Myself------------------
OS = Linux Mint 12
First, installed chirp package from Ubuntu ppa repository (Linux Mint is a Ubuntu derivative and Ubuntu packages almost always work fine): |
sudo apt-add-repository ppa:ubuntu-hams-updates/ppa sudo apt-get update sudo apt-get install chirp|
What I got was a downlevel chirp 0.1.12. Tested it and chirp 0.1.12 successfully read from the radio.
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.
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" (http://chirp.danplanet.com/download/0.1.12/Test_Report.html shows all functions supported on FT-60 except "clone"; whereas clone is listed as supported on the current beta release 0.3.1 http://chirp.danplanet.com/download/0.3.1/Model_Support.html).
I downloaded the 0.3.1 tarball and manually installed it (|sudo python setup.py install)|. I presumed that the necessary libraries were already present as a result of the previous installation of chirp 0.1.12. The manual installation ||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.)
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.
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. ||
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 http://chirp.danplanet.com/projects/chirp/wiki/Running_Under_Linux to ensure all prerequisite libraries are present,
sudo apt-get install python-gtk python-serial python-libxml2
produced an error message: Package 'python-gtk' has no installation candidate.
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.
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.
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.)
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.
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:
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.
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.: /dev/ttyS0, Yaesu, FT-60. Click OK to begin transmitting to the radio.
c. Chirp's prompt appears showing that Chirp is attempting to transmit to the radio. After a short timeout, error message appears: "An error has occurred. Failed to communicate with radio: Radio did not respond." (Note that the radio still displays ---Rx--- ).
Chirp Help, About shows the following:
Chirp 0.3.1 GTK 2.24.6 PyGTK 2.24.0 Python 2.7.2+
---------------------------------------------------------------------------------------------------------
On Sun, 26 May 2013 10:16:27 -0700 Marcia Stockton radio@frontier.com wrote:
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.
--------------------snip----------------
Chirp Help, About shows the following:
Chirp 0.3.1 GTK 2.24.6 PyGTK 2.24.0 Python 2.7.2+
Since none of the real experts have replied to your message, I'll offer a small suggestion that your message didn't say you'd tried.
Download the daily build - I just downloaded the latest called 'Chirp daily-20130524' - then unpack it to a folder and execute the chirpw file. It sounds like you've done everything else right. If I remember correctly, there have been changes in past weeks that may affect the Yaesu radio.
Chirp Help, About, shows the following on this system running on Fedora 18:
Chirp daily-20130524 GTK 2.24.16 PyGTK 2.24.0 Python 2.7.3
Fred KL7FE
Good idea, Fred. Tried it but no joy.
- Completely removed previous 0.3.1 install by deleting its files and directories
- Got "daily build" using sudo apt-add-repository ppa:dansmith/chirp_snapshots sudo apt-get update sudo apt-get install chirp-daily
This fetched 2 files:
python-suds from .../python_suds_0.4.1-2_all.deb chirp-daily from .../chirp-daily_20130315-oneiric~1_i386.deb (Note: is this really daily? Is the build date March 15, 2013?)
The install via apt appeared to be error free (no error messages).
But chirpw failed to start chirp and produced console error messages:
Traceback (most recent call last): File "/usr/bin/chirpw", line 20, in <module> from chirp import elib_intl Import Error: cannot import name elib_intl
No joy.
73 de NU6N Marcia
On 05/26/2013 12:44 PM, Fred Erickson wrote:
On Sun, 26 May 2013 10:16:27 -0700 Marcia Stockton radio@frontier.com wrote:
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.
--------------------snip----------------
Chirp Help, About shows the following:
Chirp 0.3.1 GTK 2.24.6 PyGTK 2.24.0 Python 2.7.2+
Since none of the real experts have replied to your message, I'll offer a small suggestion that your message didn't say you'd tried.
Download the daily build - I just downloaded the latest called 'Chirp daily-20130524' - then unpack it to a folder and execute the chirpw file. It sounds like you've done everything else right. If I remember correctly, there have been changes in past weeks that may affect the Yaesu radio.
Chirp Help, About, shows the following on this system running on Fedora 18:
Chirp daily-20130524 GTK 2.24.16 PyGTK 2.24.0 Python 2.7.3
Fred KL7FE _______________________________________________ chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
On Sun, 26 May 2013 13:53:04 -0700 Marcia Stockton radio@frontier.com wrote:
Good idea, Fred. Tried it but no joy.
- Completely removed previous 0.3.1 install by deleting its files and
directories
- Got "daily build" using sudo apt-add-repository ppa:dansmith/chirp_snapshots sudo apt-get update sudo apt-get install chirp-daily
This fetched 2 files:
python-suds from .../python_suds_0.4.1-2_all.deb chirp-daily from .../chirp-daily_20130315-oneiric~1_i386.deb (Note: is this really daily? Is the build date March 15, 2013?)
The install via apt appeared to be error free (no error messages).
But chirpw failed to start chirp and produced console error messages:
Traceback (most recent call last): File "/usr/bin/chirpw", line 20, in <module> from chirp import elib_intl Import Error: cannot import name elib_intl
No joy.
73 de NU6N Marcia
I see you are receiving the 15 March build when using apt-get. Don't use apt-get, go directly to this web page http://trac.chirp.danplanet.com/chirp_daily/LATEST/ and download the tar.gz file. That will get you the 24 May build - or later if it gets updated before you get around to downloading. Run the chirpw file from the directory created when you unpack the daily build, not the one in /usr/bin. If you still get a failure, at least you can say you've tried the latest build.
It would be interesting to see if the same console error messages come up...my only experience with Debian has been limited to the Raspberry Pi so I can't help you with that elib_intl error.
Fred
I see you are receiving the 15 March build when using apt-get. Don't use apt-get, go directly to this web page http://trac.chirp.danplanet.com/chirp_daily/LATEST/ and download the tar.gz file. That will get you the 24 May build - or later if it gets updated before you get around to downloading. Run the chirpw file from the directory created when you unpack the daily build, not the one in /usr/bin.
The reason she's getting the older build is because she's running an old and unsupported version of Ubuntu (Oneiric 11.10). Using the PPA (via apt-get) _is_ the proper and preferred way for Ubuntu users to receive the builds.
If you still get a failure, at least you can say you've tried the latest build.
Nothing has changed in the FT-60 driver or supporting code in a very long time, so I do not expect any difference by upgrading to the latest version. I expect that the problem is, as others have noted, related to the cable and/or USB hardware being used here.
On Mon, 27 May 2013 10:39:13 -0700 Dan Smith dsmith@danplanet.com wrote:
...............
The reason she's getting the older build is because she's running an old and unsupported version of Ubuntu (Oneiric 11.10). Using the PPA (via apt-get) _is_ the proper and preferred way for Ubuntu users to receive the builds.
If you still get a failure, at least you can say you've tried the latest build.
Nothing has changed in the FT-60 driver or supporting code in a very long time, so I do not expect any difference by upgrading to the latest version. I expect that the problem is, as others have noted, related to the cable and/or USB hardware being used here.
Thanks Dan, I, somehow, missed any replies that you or any of the usual experts had made to her. Thought her message yesterday was the first and no one else had replied. I'll go back in the wood work. Fred
As documented in my original post, the OS is LINUX MINT 12 -- not Ubuntu.
If the directions on the webpage that says how to get the daily build are incorrect, shouldn't they be updated?
The DB9 serial cable was purchased from Yaesu and is specifically made for this radio. This cable worked fine when programming the FT-60 using the same laptop, with Windows XP Professional and the 3rd party programming software supplied by Yaesu. The cable and rig have not changed in any way. I don't suspect any fault with the cable.
I will try the real daily build when I find the energy.
Thanks, Marcia NU6N
On 05/27/2013 10:39 AM, Dan Smith wrote:
I see you are receiving the 15 March build when using apt-get. Don't use apt-get, go directly to this web page http://trac.chirp.danplanet.com/chirp_daily/LATEST/ and download the tar.gz file. That will get you the 24 May build - or later if it gets updated before you get around to downloading. Run the chirpw file from the directory created when you unpack the daily build, not the one in /usr/bin.
The reason she's getting the older build is because she's running an old and unsupported version of Ubuntu (Oneiric 11.10). Using the PPA (via apt-get) _is_ the proper and preferred way for Ubuntu users to receive the builds.
If you still get a failure, at least you can say you've tried the latest build.
Nothing has changed in the FT-60 driver or supporting code in a very long time, so I do not expect any difference by upgrading to the latest version. I expect that the problem is, as others have noted, related to the cable and/or USB hardware being used here.
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
As documented in my original post, the OS is LINUX MINT 12 -- not Ubuntu.
Linux Mint 12 is a respin of Ubuntu 11.10. It's outdated by a large margin.
If the directions on the webpage that says how to get the daily build are incorrect, shouldn't they be updated?
The directions on the website are not incorrect. You're following them, as you should, but you're only getting old builds because your OS is far beyond the support envelope (that of your OS vendor and CHIRP's).
Thanks for the explanation.
73 Marcia
On 05/27/2013 02:01 PM, Dan Smith wrote:
As documented in my original post, the OS is LINUX MINT 12 -- not Ubuntu.
Linux Mint 12 is a respin of Ubuntu 11.10. It's outdated by a large margin.
If the directions on the webpage that says how to get the daily build are incorrect, shouldn't they be updated?
The directions on the website are not incorrect. You're following them, as you should, but you're only getting old builds because your OS is far beyond the support envelope (that of your OS vendor and CHIRP's).
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
Tried daily build; same symptom. Booted Mint 12 live CD, again downloaded daily build, repeated test, same result. I guess I'm done here for now.
Thanks everybody.
Marcia NU6N
On Mon, May 27, 2013 at 10:39 AM, Dan Smith dsmith@danplanet.com wrote:
Nothing has changed in the FT-60 driver or supporting code in a very long time, so I do not expect any difference by upgrading to the latest version. I expect that the problem is, as others have noted, related to the cable and/or USB hardware being used here.
On Tue, May 28, 2013 at 11:48 AM, Marcia Stockton radio@frontier.com wrote:
Tried daily build; same symptom.
No surprise here. Try a different cable.
Tom KD7LXL
I use FTB Commander in Windows for my FT60 and have to use the alternative write method. Don't think it's the program but my old Radio Shack USB to DB9 cable. The drivers were for Windows 2000 because the cable is so old circa 1998. But managed to get it to work in Windows 7.
I have no problems whatsoever with a genuine Prolific 2303 on Mac OS-X 10.8.3, Chirp 3.1 with and 3 Chinese radios I have although the reads and writes are slow.
Don't know why I have to set FTB to alternative write, probably because the age of the drivers. But I also use it with a Yaesu 8900 and FT8900 Commander software and read and write need no special considerations. So it may be that the FT60 is a little picky, who knows but hop you get it sorted.
Sent from my 15.4" MacBook Pro, i7 quad core
On May 26, 2013, at 1:16 PM, Marcia Stockton radio@frontier.com wrote:
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.
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.
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.)
Thanks for any help you can give.
73, Marcia NU6N
----------------Tried to Solve the Problem Myself------------------
OS = Linux Mint 12
First, installed chirp package from Ubuntu ppa repository (Linux Mint is a Ubuntu derivative and Ubuntu packages almost always work fine):
sudo apt-add-repository ppa:ubuntu-hams-updates/ppa sudo apt-get update sudo apt-get install chirp What I got was a downlevel chirp 0.1.12. Tested it and chirp 0.1.12 successfully read from the radio.
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.
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" (http://chirp.danplanet.com/download/0.1.12/Test_Report.html shows all functions supported on FT-60 except "clone"; whereas clone is listed as supported on the current beta release 0.3.1 http://chirp.danplanet.com/download/0.3.1/Model_Support.html).
I downloaded the 0.3.1 tarball and manually installed it (sudo python setup.py install). I presumed that the necessary libraries were already present as a result of the previous installation of chirp 0.1.12. The manual installation 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.)
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.
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.
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 http://chirp.danplanet.com/projects/chirp/wiki/Running_Under_Linux to ensure all prerequisite libraries are present,
sudo apt-get install python-gtk python-serial python-libxml2
produced an error message: Package 'python-gtk' has no installation candidate.
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.
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.
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.)
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.
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:
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.
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.: /dev/ttyS0, Yaesu, FT-60. Click OK to begin transmitting to the radio.
c. Chirp's prompt appears showing that Chirp is attempting to transmit to the radio. After a short timeout, error message appears: "An error has occurred. Failed to communicate with radio: Radio did not respond." (Note that the radio still displays ---Rx--- ).
Chirp Help, About shows the following:
Chirp 0.3.1 GTK 2.24.6 PyGTK 2.24.0 Python 2.7.2+
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
participants (5)
-
Dan Smith -
Fred Erickson -
Marcia Stockton -
Phaeton -
Tom Hayward