[chirp_users] Chirp VX-6 Clone Download Hangs?
Just installed Chirp 0.2.2 and python runtime on a Mac OSX 10.6 machine per standard instructions. Installed drivers for USB-Serial cable.
When I turn on my Yaesu VX-6 in Clone mode, start Chirp, then initiate the clone transmission on the radio, it appears to start, but hang immediately. Radio gives an error and Chirp waits until cancelled. Have full debug log, but the following appears to be the pertinent part.
Something obvious to any of you?
Thanks, Steve
------------ <snip> Registered Yaesu_VX-6 = VX6Radio
<snip>
Enabled OSX menubar integration /Applications/chirp-0.2.2.app/Contents/MacOS/../Resources/chirp/chirpw:124: PangoWarning: error opening config file '../Resources/etc/pango/pangorc': No such file or directory
a.show() User selected Yaesu VX-6 on port /dev/cu.usbserial Clone thread started 000: 41 48 30 32 31 00 e0 01 AH021... 008: 02 01 00 00 00 00 00 00 ........
-- Exception: -- Traceback (most recent call last): File "/Applications/chirp-0.2.2.app/Contents/Resources/chirp/chirpui/clone.py", line 222, in run self.__radio.sync_in() File "/Applications/chirp-0.2.2.app/Contents/Resources/chirp/chirp/yaesu_clone.py", line 177, in sync_in self._mmap = clone_in(self) File "/Applications/chirp-0.2.2.app/Contents/Resources/chirp/chirp/yaesu_clone.py", line 67, in clone_in data += chunk_read(pipe, block, radio.status_fn) File "/Applications/chirp-0.2.2.app/Contents/Resources/chirp/chirp/yaesu_clone.py", line 42, in chunk_read data += pipe.read(block) File "/opt/kk7ds/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/serial/serialposix.py", line 442, in read ready,_,_ = select.select([self.fd],[],[], self._timeout) error: (9, 'Bad file descriptor') ------ Clone failed: (9, 'Bad file descriptor') Clone thread ended
User selected Yaesu VX-6 on port /dev/cu.usbserial Clone thread started 000: 41 48 30 32 31 00 e0 01 AH021... 008: 02 01 00 00 00 00 00 00 ........
I'd have bet a dollar that it'd work after seeing this, which means we got the first block of identification from the radio. The fact that it gets no further means that the radio isn't seeing our ACK of this block.
What kind of cable are you using?
This cheap USB-serial cable from HappyHamShop: http://www.happyhamshop.com/usb-programming-data-cable-yaesu-vertex-radio-1 -pin-p-611.html
It uses a Prolific PL-2303 chip with drivers downloaded from direct from Prolific. Unless this is a known good one, got one to recommend? If I can get this working I'll send the VX6R bank image I see being discussed...
Thanks - Steve
On 4/17/12 4:02 PM, "Dan Smith" dsmith@danplanet.com wrote:
User selected Yaesu VX-6 on port /dev/cu.usbserial Clone thread started 000: 41 48 30 32 31 00 e0 01 AH021... 008: 02 01 00 00 00 00 00 00 ........
I'd have bet a dollar that it'd work after seeing this, which means we got the first block of identification from the radio. The fact that it gets no further means that the radio isn't seeing our ACK of this block.
What kind of cable are you using?
-- Dan Smith www.danplanet.com KK7DS
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
Thanks, Dan, but you can ignore this now. Screwing in the cable tighter to the radio fixed it. Strange that it should be so finicky - it was snug before. Loose wire or cheap cable...
Steve
On 4/17/12 4:02 PM, "Dan Smith" dsmith@danplanet.com wrote:
User selected Yaesu VX-6 on port /dev/cu.usbserial Clone thread started 000: 41 48 30 32 31 00 e0 01 AH021... 008: 02 01 00 00 00 00 00 00 ........
I'd have bet a dollar that it'd work after seeing this, which means we got the first block of identification from the radio. The fact that it gets no further means that the radio isn't seeing our ACK of this block.
What kind of cable are you using?
-- Dan Smith www.danplanet.com KK7DS
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
After getting my cable working so Chirp can download (clone) from my VX-6, now it hangs on the upload! This doesn't appear to be cable related – things start to go south in the debug log (below) with some file permission errors. But I installed this from an account with full admin privileges and run it from that same account. And is the eventual failure because of this? The clone/Tx progress bar indicates the transmission at least gets started before the hang…
Configuration: Chirp 0.2.2 and python runtime on a Mac OSX 10.6 machine.
Thanks, Steve
------------ Debug log after normal start…
<snip> Cross Mode supported: False Comment supported: False /Applications/chirp-0.2.2.app/Contents/MacOS/../Resources/chirp/chirpw:132: GtkWarning: Attempting to store changes into `/Users/scarter/.local/share/recently-used.xbel', but failed: Failed to create file '/Users/scarter/.local/share/recently-used.xbel.5Q6JCW': No such file or directory gtk.main() /Applications/chirp-0.2.2.app/Contents/MacOS/../Resources/chirp/chirpw:132: GtkWarning: Attempting to set the permissions of `/Users/scarter/.local/share/recently-used.xbel', but failed: No such file or directory gtk.main() /Applications/chirp-0.2.2.app/Contents/MacOS/../Resources/chirp/chirpw:132: GtkWarning: Attempting to store changes into `/Users/scarter/.local/share/recently-used.xbel', but failed: Failed to create file '/Users/scarter/.local/share/recently-used.xbel.VQ5JCW': No such file or directory gtk.main() Clone thread started -- Exception: -- Traceback (most recent call last): File "/Applications/chirp-0.2.2.app/Contents/Resources/chirp/chirpui/clone.py", line 220, in run self.__radio.sync_out() File "/Applications/chirp-0.2.2.app/Contents/Resources/chirp/chirp/yaesu_clone.py", line 183, in sync_out clone_out(self) File "/Applications/chirp-0.2.2.app/Contents/Resources/chirp/chirp/yaesu_clone.py", line 120, in clone_out radio.status_fn, radio._block_size) File "/Applications/chirp-0.2.2.app/Contents/Resources/chirp/chirp/yaesu_clone.py", line 81, in chunk_write pipe.write(chunk) File "/opt/kk7ds/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/serial/serialposix.py", line 485, in write raise SerialException('write failed: %s' % (v,)) SerialException: write failed: [Errno 9] Bad file descriptor ------ Clone failed: write failed: [Errno 9] Bad file descriptor Exception in thread Thread-3: Traceback (most recent call last): File "/opt/kk7ds/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 552, in __bootstrap_inner self.run() File "/Applications/chirp-0.2.2.app/Contents/Resources/chirp/chirpui/clone.py", line 233, in run self.__radio.pipe.close() File "/opt/kk7ds/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/serial/serialposix.py", line 419, in close os.close(self.fd) OSError: [Errno 9] Bad file descriptor
After getting my cable working so Chirp can download (clone) from my VX-6, now it hangs on the upload! This doesn't appear to be cable related – things start to go south in the debug log (below) with some file permission errors. But I installed this from an account with full admin privileges and run it from that same account. And is the eventual failure because of this?
No, those are just fallout from GTK trying to save stuff, unrelated to anything CHIRP is doing. As you can see, they're not permissions-related, but rather complaining that some directory doesn't exist (probably ~/.local). You can try to create that and see if they go away, but I doubt they're related to your issue.
The clone/Tx progress bar indicates the transmission at least gets started before the hang…
And what does the radio do? I assume it starts and then times out waiting for the computer? It's far enough that it's sent at least the header block to the radio and received the ACK.
Based on your stack trace, it's just in a dead-simple loop writing data out to the serial port. It's not even looking for a response from the radio. The number of things that could cause this all lie fairly low, such as the driver for your cable, your cable, etc. If you wait long enough for that to complete, then you should get another error about not getting a response from the radio. If you never get that, then CHIRP is blocked writing to the serial port against its will, which screams of a driver issue.
It seems like MacOS users always have lots of trouble finding stable/suitable drivers for their USB dongles. The ones that persevere eventually find one that works, and the ones that don't, well...don't.
Unfortunately, I don't even own a physical Mac so there's not a whole lot I can do to help. There are a lot of folks successfully using the MacOS build with a variety of radios.
Maybe someone else on this list that actually uses MacOS could chime in with some suggestions for you...
participants (2)
-
Carter, Steve -
Dan Smith