Project

General

Profile

Actions

Bug #1799

closed

Yaesu VX-6R Upload to Radio Error

Added by Dennis Cooney over 10 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
08/01/2014
Due date:
% Done:

100%

Estimated time:
6:00 h
Chirp Version:
daily
Model affected:
Yaesu VX-6R
Platform:
MacOS
Debug Log:
I read the instructions above:

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 1 (0 open1 closed)

Has duplicate Bug #1791: Yaesu VX-6 Upload ErrorClosedJens Jensen07/26/2014

Actions
Actions #1

Updated by Jens Jensen over 10 years ago

  • Status changed from New to In Progress
  • Assignee set to Jens Jensen
Actions #2

Updated by Jens Jensen over 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.

Actions #3

Updated by Jens Jensen over 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.

Actions #4

Updated by Jens Jensen over 9 years ago

  • Status changed from Feedback to Closed
Actions

Also available in: Atom PDF