CHIRP

Can you confirm whether the FTDI company driver or the Apple driver is being loaded?

1) Open Terminal
2) type "kextstat | grep FTDI"

If the driver name is com.FTDI.driver.FTDIUSBSerialDriver, you are using the real FTDI-issued driver and I'm surprised it's not working. If you have com.apple.driver.AppleUSBFTDI (very likely) then you need to manually unload the apple driver and load the FTDI driver instead:

1) Return to terminal
2) type "sudo kextunload -b com.apple.driver.AppleUSBFTDI" (you will be prompted for your password the first time)
3) type "sudo kextload /Library/Extensions/FTDIUSBSerialDriver.kext/"

The FTDI cable port name may or may not change after this happens, but if you rerun the kextstat you should now see the com.FTDI driver loaded instead of Apple. Try CHIRP again.

Driver results seem fine, although it's not clear which driver was originally loaded. I think it was the com.FTDI driver. in any case, it didn't change anything.

I'm quickly running out of ideas, but let's try this:

1) After you plug the cable in but before launching CHIRP, open a Terminal
2) Run "stty sane /dev/cu.usbserial-A9030U84"
3) Launch CHIRP as normal

I don't have a cable to test, so I can't probe around to get exact details on what might be happening. If this doesn't work, you might be stuck hunting for a Windows or Linux system to try out. If the cable works there, then we know it's just an OS X software issue (driver or software settings) rather than something fundamentally wrong with the cable, which I kinda doubt anyway.

Oops. Here's the terminal window:

Last login: Sat Sep 3 21:52:33 on ttys000
JacksMacBookPro:~ jacksonp$ stty sane /dev/cu.usbserial-A9030U84
stty: illegal option -- /dev/cu.usbserial-A9030U84
usage: stty [-a|-e|-g] [-f file] [options]
JacksMacBookPro:~ jacksonp$

I assume you are trying to monitor traffic on the port so I spend 30 minutes looking for terminal commands that might do that but didn't find anything I dared try.

Not monitor, I'm just trying to get all the DTR/RTS pins set to normal rather than a messed-up default in the OS X driver. If set improperly, those flow control pins would leave the adapter in "output" mode, and not allow the computer/software to hear the radio sending bits.

I just had the syntax confused. Please try this, then run CHIRP:

stty -f /dev/tty.usbserial-A9030U84 sane

That command seemed to work OK. With the cable unplugged I got a no such device message, and with it plugged in only got the prompt for the next command.

No improvement on the data transfer however.

Hey, I found a cable I had purchased when I bought the FT-60R. It looks like this in the OS x system Profiler:¶

USB-Serial Controller:

Product ID: 0x2303
Vendor ID: 0x067b (Prolific Technology, Inc.)
Version: 3.00
Speed: Up to 12 Mb/sec
Manufacturer: Prolific Technology Inc.
Location ID: 0x1a200000 / 3
Current Available (mA): 1000
Current Required (mA): 100

Extra Operating Current (mA): 0¶

Seems like I have read some warning about Prolific??
Thanks for hanging in there on this!

Prolific has had a lot of counterfeit/cloning issues, but if your cable came from a reputable dealer then it should be fine. The OS X driver works similar to the FTDI one, you just need to install it first and then plug in.

http://www.prolific.com.tw/US/ShowProduct.aspx?p_id=229&pcid=41

Followed your link, downloaded the El Capitan compatible, installed, used your instructions with Terminal to verify installation, ran CHIRP got same result. Wondering if my FT-60 is sick. A nephew just bought one and I am expecting delivery of a clone cable soon so I'll do some more testing and see if I can find what component(s) are failing.

Thanks for all your help. If you know a way to monitor the serial traffic that might be useful - could see the requests from CHIRP to open the connection, etc??

Well, at least we know it's not a driver-specific problem.

CHIRP will log most of the necessary serial messages already anyway, you just need to turn it on so the messages go to a log file.

1) Navigate into your chirp daily app (right click the app and choose "show contents"), Contents/MacOS
2) Make a backup of the file "chirp", then open the file in an editor.
3) Edit the last line so that it includes a log argument and filename, such as this:

exec "$PYTHON" "${LOCATION}/../Resources/chirp/chirpw" --log /tmp/chirp.log

4) Save and close the file, run CHIRP as normal. After quitting CHIRP, view the logfile as specified in the edited line. It will include lots of extra debug info about what was done in the session.

Note you can also do this by cloning the daily repo and running chirp on the command line with the --log argument, but I assume you're launching the full app from the finder.

Trying to do this - the last line looks exactly like your text except the --log /tmp/.... arguments, which I added to the original Contents/MacOS/chirp, saved the file and ran CHIRP. Can't find the /tmp/chirp.log file anywhere. I assumed it would be at the volume root or within the contents/MacOS folder from "show contents" action. Sorry - I'm lost on this one.
I made the copy by using the command "D" keystrokes on the selected file and the editing the original with TextWrangler. Hope that was OK.

Sorry about that. /tmp is one of those magic folders that macOS likes to hide. You can show it from a Finder window by hit shift+cmd+g and typing "/tmp" into the go to folder box. The shift+cmd+g trick will also work from a TextWrangler "open" dialog box, to let you navigate straight there and open the logfile.

The log confirms the expectation; there is no data being received by CHIRP over the cable. This is probably because it's still in transmit mode and not switched over to receive. Have you had any luck trying this out on a Windows machine? I'm tempted to go write some debug code to try out on this thing, but it would be really interesting to confirm we're doing everything right on Windows. (edit: or Linux!)

This is really bazaar! The only problem I have had is not holding the PTT switch closed for a full second!! The chirp app does not say that!

Item 6 in the Radio download to the chirp desktop app says, "6. Afer clicking OK, press the [PTT] switch to send image.

I discovered what the problem was when I ordered a second FT-60R and tried to clone the new one from the old one. I looked up cloning in the FT-60R manual and it says, "Press and hold the PTT switch for one second on the source radio, ..." When I read that I had a classic "AHA" moment.

Thanks for all your help but nothing would have worked until I knew to hold the PTT switch for a second.

Please get the chirp app instruction fixed!