Bug #1799
closedYaesu VX-6R Upload to Radio Error
100%
Description
I'm having the same issue as reported by Ron Earl, Bug #1791 on 07/26/2014. I'm using an iMac v. OS 10.9.4 and Chirp V. 0.4.0. When I try to upload to the radio the cloning TX bar gets about 50% across the bar plane and the computer freezes and the radio displays ERROR. I'm using an RT Systems USB cable with the RT System USB Driver installed on my Mac. I have also installed the Python runtime as required by Chirp. Download from the radio seems to work fine so I think the cable and USB connection between the radio & computer is established. It's a puzzle why downloading seems to work fine and uploading does not? Any help with this problem would be appreciated.
Related issues
Updated by Jens Jensen almost 10 years ago
- Status changed from New to In Progress
- Assignee set to Jens Jensen
Updated by Jens Jensen almost 10 years ago
- % Done changed from 0 to 20
- Estimated time set to 4.00 h
- Chirp Version changed from 0.4.0 to daily
So ran a few tests with my VX-6 and latest chirp daily on my hackintosh w/ OSX 10.9.4
with generic prolific cable and the opensource pl2303 drivers, I can upload and download multiple times without issues.
With genuine rtsystems ftdi cable USB-57B, I can download without issues, but I also get an "upload hangs" scenario: somewhere in the upload (maybe 20-30%)
- the radio shows ERROR
- chirp upload progress seems stuck
- after terminating chirp upload (must be done with CTRL-C on commandline), I see: --- Exception Dialog: Failed to communicate with the radio: write failed: [Errno 9] Bad file descriptor ---
- radio will reset to default state (normal when upload fails I believe)
In console app I see the following interesting messages:
8/8/14 12:49:30.000 PM kernel[0]: FTDIUSBSerialDriver: 0 21009e52 start - ok
8/8/14 12:50:11.000 PM kernel[0]: USBF: 391588.848 AppleUSBEHCI::Found a transaction past the completion deadline on bus 0xfd, timing out! (Addr: 5, EP: 1)
8/8/14 12:52:52.000 PM kernel[0]: USBF: 391749.665 AppleUSBEHCI::DoControlTransfer sync request on workloop thread. Use async!
Now,
I am running drivers FTDI VCP 2.2.18 (I dont think this was downloaded from rtsystems - but cant be sure). I believe due to some issues, had to uninstall Apples FTDI driver (included with Mavericks).
hackpro:build jens$ kextstat | grep -i ftdi
517 0 0xffffff7f825f8000 0x8000 0x8000 com.FTDI.driver.FTDIUSBSerialDriver (2.2.18) <82 35 5 4 3 1>
When I used the same ftdi cable on my linux box (xubuntu 14.04) and daily chirp, I did not have any trouble uploading and downloading (except when using a flakey usb extension cable).
So where I'm at now is suspicious of the serial buffers getting overrun or something like that.
While I dont think this is a chirp problem per se, I'll play around with relaxed timings to see if we can find a happy medium on uploading.
Updated by Jens Jensen almost 10 years ago
- Status changed from In Progress to Feedback
- % Done changed from 20 to 100
- Estimated time changed from 4.00 h to 6.00 h
I think I have found the problem, and it seems to be some low-level issue with OEM FTDI driver.
The workaround is to disable oem driver, modify and load Apple FTDI driver.
I have documented the steps on this guide:
RTSystemsCablesAndMavericks
Please let me know if the guide is OK and if it solves your issue.
Updated by Jens Jensen almost 9 years ago
- Status changed from Feedback to Closed