[chirp_users] Help needed, can't write to Yaesu FT-60
Hi, I'm new to Chirp, and enthusiastic about the possibilities, but if it can't write to my radio, my enthusiasm will wane quickly. There has to be too many of these out there for it not to be a problem with my setup, but I'm not sure where to start.
Setup: New MacBook running OSX 10.8.2. Chirp is 0.2.3. Cable is from eBay, using a PL2303 chip, driver obtained from your pointer, I think. Fairly new Yaesu FT-60, 12 memories used. Trying to load another 100 for the local standardized CERT list, massaged from a spreadsheet into a .csv format that Chirp finally seems happy with, and which looks sane in the Chirp display.
I am able to read the FT60 into Chirp just fine, and repeatedly, no errors. What I see in Chirp is pretty much what I expected to see. After massaging, I tried to write it back. I think I've got the dance right: Put the FT60 in clone Rx mode and then hit the OK button in Chirp's Upload popup. [ Just for grins I tried it in the "wrong" order, that doesn't work either. ]
Nothing happens. The FT60 stays in Rx mode as though nobody has tried comm with it. No progress bar as with a radio/radio clone, and no error display. Just waiting in Rx, forever.
The Upload popup in Chirp disappears, there looks to be a flash of a small popup too fast to read, and nada. The radio, after power off/on, still has the original 12 memories programmed, but nothing else. No error messages I can see.
I tried a different FT60, same result. Reseated the cable several times. The cable is plausibly suspect (I don't have another), but I don't think it can read and not write, it needs both data directions for either, doesn't it?
I can't find any debug information within Chirp or the Mac console logs, but maybe I don't know where to look. The "raw data" in the developer tools just looked like a very short data structure, nothing that looked meaningful to me. Please advise how I can go about troubleshooting this, or what I might be doing wrong.
Thanks and regards,
-dan
might look over this thread '[chirp_users] Please post'.
i have chirp working on an imac running osx 10.7.4 (now 10.7.5). here is the driver i'm using:
unfortunately i can't link directly to the driver--that would be too easy by far. the main page is: http://www.prolific.com.tw/US/CustomerLogin.aspx and then you have to hit the support tab, then login using guest/guest. then you can get to the driver page and select the mac driver that matches your os version. i'm using 10.7.4 (lion).
if the installer works right, when you try to transfer from the radio to chirp you should see '/dev/cu.usbserial' as an option. i found a quirk where i couldn't upload to radio unless it was in vfo mode.
good luck,
/guy
On Fri, Sep 21, 2012 at 8:41 PM, chirp.cordless@xoxy.net wrote:
Thanks,
I can't see what thread you want me to look at, something in the path seems to have obfuscated it, see below.
I tried putting the radio in VFO mode, no help.
So I unloaded the Prolific driver I was using that was from some open source project, and loaded the one downloaded from the Prolific website you pointed me at, which at least claims to know about OS X 10.7, and I expect it likely is a better choice all around.
The good news is that I can still read my FT60, so I haven't lost anything. And maybe there's progress on write, but painful progress. I managed on one write attempt to completely erase the FT60, so I guess there's some indication that it's sending something. A read attempt failed with an error and no data returned, and operationally there are no memories in the radio.
Fortunately, I was able to clone it from our other FT60, or at least 10 of the memories; the other two were recently programmed just in one.
And after cloning, I can read it back into Chirp, so I'd say I'm no worse off.
A second teeth-gritting write attempt did nothing, as the previous behavior. The radio just displays --Rx-- forever. I did manage to see the little pop-up just long enough to read it, it says Cloning [Cancel] for maybe half a second, then disappears.
So, any more ideas?
-dan
On Sep 21, 2012, at 7:09 PM, Guy Teague - accts@gtweb.org +chirp+cordless+1d49abe5b1.accts#gtweb.org@spamgourmet.com wrote:
Download a live CD of Ubuntu, chirp works great in Linux.
You can boot into the live CD without injuring anything
http://cdimages.ubuntu.com/releases/precise/release/ubuntu-12.04.1-desktop-a...
DR
On Sat, Sep 22, 2012 at 12:25 AM, chirp.cordless@xoxy.net wrote:
When I uploaded my programming to a FT-8800 it only programmed the left side of the radio. Right side did not change. Any suggestions appreciated,
Jack W4GRJ
On Sat, Sep 22, 2012 at 12:25 AM, chirp.cordless@xoxy.net wrote:
Dan,
Actually the behavior you are describing seems to be pretty common. I've fought with the same thing for a while myself. The thread he was pointing to was one just from a week or two ago. In the end, this driver works (actually, worked, haven't tried since upgrading to 10.8.x yet) for me on 10.7 at least.
http://xbsd.nl/2011/07/pl2303-serial-usb-on-osx-lion.html
I will do my best to test it on 10.8.2 sometime today or tomorrow as I need to fix my wife's VX-7R with correct power levels since they are totally messed up from a bug. The source code is available so if it doesn't work, I'll look at recompiling with 10.8 and the latest XCode and see if that works... if that doesn't work... I'll see if I can figure out how to port it.
Hopefully it just works. If you download it and it works for you on 10.8, that'd be great.
BTW, the problem is that the official Prolific driver on MacOSX has some counterfit chip detection built in... or at least the counterfit chips aren't as tight with timing or something and the official driver stresses them and thus the failures. No matter what, the official driver unless you have an official chip on MacOSX is an iffy proposition.
Jay, WC3K
On Sat, Sep 22, 2012 at 8:25 AM, Jay Moran, WC3K jay+CHIRP@tp.org wrote:
http://xbsd.nl/2011/07/pl2303-serial-usb-on-osx-lion.html
Okay, tested with both my wife's Yaesu VX-7R with a counterfit prolific USB cable from KaWaMall, and my own Wouxun KG-UV3d with a counterfit Prolific Chip USB cable from some other reseller on eBay. Both work great with the driver above with MacOSX 10.8.2 on my June 2012 MacBook Air 11".
I downloaded it again and followed the installation steps. I used "sudo" at the start of every line/step they outline on that webpage, even though it didn't say to, better safe than sorry. The port shows up for me as: /dev/cu.PL2303-00002014.
Good luck, hope that works for you.
Jay
Jay,
My sincere thanks for the effort. Your mail came as I was just finishing up the unsuccessful testing. I got the driver that the link pointed to, uninstalled the official Prolific driver I installed yesterday, installed the new one per the instructions, and even did a system reset to make sure things were cleaned up, though the instructions seemed to load the extension live.
I have /dev/cu.PL2303-00402214 and this is what Chirp finds in the popup for radio comm, and what I'm using.
Symptoms are unchanged. I can read the FT60 just fine through this port. Write does nothing, not even trashing the ten memories in the radio. The radio just hangs in --Rx-- forever.
I know that the radio can be written to in clone mode after recovering from yesterday's mess. The cable works for read. The software seems to work for you in a very similar configuration. My MacBook is 2.9 GHz vice your Air looks to be 1.7 GHz - there wouldn't be any clock-counting timeouts in this software, would there?.
Is there anything reasonable I can do to troubleshoot this?
When Chirp decides it's done after half a second, are there any logs to look at, or any way to get visibility into what it thinks it's doing?
I'd suspect the cable, but it works for read, and I'm reluctant to spend the money and wait time to get another without some confidence that that's the problem, and it isn't feeling that way to me so far.
Thanks and regards,
-dan
On Sep 22, 2012, at 12:12 PM, "Jay Moran WC3K - jay+CHIRP@tp.org" +chirp+cordless+6937ac44de.jay+CHIRP#tp.org@spamgourmet.com wrote:
i'm just throwing this out there because you seem to be stuck, but i have one of the chinese uv5r radios and the other day i could not get chirp to write to it despite it having worked perfectly for the week previous. for some reason i changed it from channel/memory mode to vfo mode and it starting writing perfectly. i was so surprised i toggled it a couple of times and sure enough that was the key to a successful write. it would be amazing if the same applied to your japanese radio, but won't cost you anything to try changing some of the radio modes to see what happens.
good luck, /guy (73 de kg5vt)
On Sat, Sep 22, 2012 at 3:15 PM, chirp.cordless@xoxy.net wrote:
Thanks, I did see your mention of VFO mode in your post yesterday, and I've been carefully putting the FT60 in VFO mode before trying to write. I do note that it doesn't seem to need that to clone from another FT60, and I think the idea is that's what it thinks it's doing ...
But still, I've tried VFO mode. Not sure what other modes to try, but I may play around. Juju beads arranged carefully in a Yaesu logo ...
I'd really like to know what Chirp thinks is happening.
-dan
On Sep 22, 2012, at 4:40 PM, Guy Teague - accts@gtweb.org +chirp+cordless+1d49abe5b1.accts#gtweb.org@spamgourmet.com wrote:
i'm just throwing this out there because you seem to be stuck, but i have one of the chinese uv5r radios and the other day i could not get chirp to write to it despite it having worked perfectly for the week previous. for some reason i changed it from channel/memory mode to vfo mode and it starting writing perfectly. i was so surprised i toggled it a couple of times and sure enough that was the key to a successful write. it would be amazing if the same applied to your japanese radio, but won't cost you anything to try changing some of the radio modes to see what happens.
good luck, /guy (73 de kg5vt)
Right about now, I'd either use another computer in the household or as I mentioned before, use a Ubuntu Live CD which was written for Mac then install CHIRP to it and try that Operating System.
It's not CHIRP, it 'might be the driver' but that's looking "not so much", on Linux I would guess it would be permissions and user groups, but I suspect you have a bad cable. Low budget shops usually don't have the automated testing facilities they need to make sure stuff works and still sell it at a low price. They probably spot test a batch, not each one.
I'd go to a friend's house with radio, cable and load CHIRP onto their computer. Certainly a family member has a computer or a friend?
I bet a buck on "bad cable".
73
DR
On Sat, Sep 22, 2012 at 8:04 PM, chirp.cordless@xoxy.net wrote:
I think we're in agreement. After trying three different drivers, and at least two of them working for other folks, and no debug tools immediately available, I think another cable is the most reasonable / expeditious thing to try. Grumble...
Ordered one from Kawamall half an hour ago. I thought about getting one with a different (FTDI) chip, but everyone else seems to get Prolific cables to work, so I'll try this first.
Booting into linux to program my radio is not where I want to end up. If the cable doesn't fix it, I'll give it some further thought.
No $1 bet, I'm betting "bad cable" too. I will post results.
Thanks and regards,
-dan
On Sep 22, 2012, at 5:18 PM, D.J.J. Ring Jr. - n1ea@arrl.net +chirp+cordless+7d3f38247a.n1ea#arrl.net@spamgourmet.com wrote:
On Sat, Sep 22, 2012 at 4:15 PM, chirp.cordless@xoxy.net wrote:
My sincere thanks for the effort.
You're welcome!
2.0Ghz i7 here; but no clock speed should have zero impact on performance of the USB cable. There are separate clocking for each sub-system these days as well.
Is there anything reasonable I can do to troubleshoot this?
Reading the later emails, I think your best bet is to do what you've done and order a new cable... I'd recommend sticking with that driver first and see how it works. I have 4 different USB cables (and radios) all told and that driver worked for all of them. Hopefully you just had a bad cable.
When Chirp decides it's done after half a second, are there any logs
to look at, or any way to get visibility into what it thinks it's doing?
There is a debug.log... it is at: ~/.chirp/debug.log ... that said, I don't think it'll help, but might want to check the end of it and see what you see.
I'd suspect the cable, but it works for read, and I'm reluctant to
spend the money and wait time to get another without some confidence that that's the problem, and it isn't feeling that way to me so far.
I think trying a new cable is definitely the right next step. I hope it works for you!
Jay
Hi Jay,
Thank you again, the log does help a little: ... Traceback (most recent call last): File "/Applications/.../chirp-0.2.3.app/Contents/Resources/chirp/chirpui/clone.py", line 220, in run self.__radio.sync_out() File "/Applications/.../chirp-0.2.3.app/Contents/Resources/chirp/chirp/ft60.py", line 169, in sync_out upload(self) File "/Applications/.../chirp-0.2.3.app/Contents/Resources/chirp/chirp/ft60.py", line 64, in upload raise Exception("Radio did not respond") Exception: Radio did not respond
So at least I know Chirp knows there's something wrong. I couldn't tell that before. There is nothing in the Chirp window, or any popup, with that exception text; I'd say there's an opportunity for improvement there.
The log output is the same if the cable is connected but not the radio. Actually, as a result I feel better about the cable being the issue.
Some startup noise about a missing pangorc (something about internationalized fonts?) and a missing icon 'application-octet-stream'. I don't think that's my problem.
So, I'll wait for the new cable, I guess.
Thanks and regards,
-dan
On Sep 22, 2012, at 6:49 PM, Jay Moran WC3K - jay+CHIRP@tp.org +chirp+cordless+6937ac44de.jay+CHIRP#tp.org@spamgourmet.com wrote:
If it's a bad cable even Linux Live CD disk won't help, but seriously, I have a Live CD disk everywhere I work. When the boss demands that "his" computer work, I can take out the Linux CD pop it in and fix Windows.
Gparted has a newer module - gpart which is excellent for recovery of bad disks.
Of course there's more.
But it is a good thing to have - I also recommend www.vinuxproject.org if you want to see what is being done for visually impaired computer users - we have about 30% of our users are radio amateurs, so we are always interesting in accessible ham software.
73 David J. Ring, Jr., N1EA http://www.qsl.net/n1ea/ Radio-Officers Grouphttp://groups.google.com/group/radio-officers?hl=en-- Join CW email list http://mailman.qth.net/mailman/listinfo/cw%20 -- Historic Morse Recordings http://archive.org/search.php?query=n1ea *Gopher Hole:* gopher://sdf.org/1/users/djringjr/ (native or with Firefox's Overbite extension) or via http to gopher gatewayhttp://gopher.floodgap.com/gopher/gw?gopher://sdf.org/1/users/djringjr/ *C**hat* Skype: djringjr MSN: djringjr@msn.com AIM: N1EA icq: 27380609
=30=
On Sat, Sep 22, 2012 at 11:10 PM, chirp.cordless@xoxy.net wrote:
Thanks for the advice, I may need it for the new cable.
I just tried it with the one I have, an even dozen times, pressing the plug housing in various directions with one hand while hitting the OK button in Chirp. Sometimes easy, and sometimes about as hard as I feel comfortable pushing on this stuff.
No change in results, 12 identical no-response messages in the log.
The new cable has shipped.
-dan
Well, this is a real bummer. New cable from Kawamall arrived today, very fast USPS shipping.
Unfortunately, the result is the same, "Radio did not respond" on write. Radio displays --Rx-- forever. Reads fine when I try that.
Tried multiple times, applying lateral pressure to the plug in the FT60 as suggested by Dan Smith yesterday. Tried our other FT60 several times, similarly, no success.
Made sure the radio was in VFO mode, FWIW.
The Prolific driver is the one recently reported as working on Mountain Lion 10.8.2 by Jay Moran with a Kawamall Prolific cable (on a VX-7R), from xbsd.nl
So: - Two cables, both Prolific FWIW (and identical appearance down to the indentations on the USB connector molding). - Two different FT60s, both of which have recently worked as the receiver in a radio/radio clone operation. - The radios can be read into Chirp just fine. - They don't respond at all on write.
Since others can get this, or very similar, working, I feel like I must be doing something wrong, but I don't see what. I get the radio in clone mode displaying --Rx--, then hit the OK button in Chirp's "Upload to Radio" dialog, with the port set to /dev/cu.PL2303-00402214, which works for read.
What's next?
-dan
What's next?
Mac users hate to hear this, but the next step is to try it on a different OS. Either use a live CD as was suggested here and try it in Linux, or find a friend with a Windows or Linux machine and give it a go there. That's your quickest path to pointing at checking the radio and cable and pointing at a driver issue.
Hi,
You do know that you have to have http://www.d-rats.com/download/OSX_Runtime/KK7DS_Python_Runtime_R10.pkg installed for Mac, I'm sure you did that.
Now for Live CD, I'd recommend our stable Ubuntu based distro. Many of the files you need are already in there.
http://vinuxproject.org/downloads
Look for the Stable Distro. http://vinuxproject.org/Downloads/V3.0.2/Vinux-3.0.2-I386.iso
I don't know if Mac has dd but if it does you can download an img file for a USB stick and put Vinux on a USB stick - that's the best bet.
Otherwise just download the iso and burn it. Boot up into it, open a terminal window with control alternate plus the letter t
Then type:
sudo apt-get install python-serial python-libxml2
sudo apt-add-repository ppa:dansmith/chirp-snapshots sudo apt-get update sudo apt-get install chirp-daily
Linux info for chirp is here: http://chirp.danplanet.com/projects/chirp/wiki/Running_Under_Linux *IMPORTANT - * *Note that you may need to adjust permissions on the /dev/tty(something) device, or add your users who want to use Chirp to the "dialout" group in order to let non-privileged users access the serial device.* After you've booted up, email back if you have problem adding your username to the group dialout or for finding the /dev/tty mine was something like /dev/tty/USB00 as it was via USB connection. 73 David J. Ring, Jr., N1EA http://www.qsl.net/n1ea/ Radio-Officers Grouphttp://groups.google.com/group/radio-officers?hl=en-- Join CW email list http://mailman.qth.net/mailman/listinfo/cw%20 -- Historic Morse Recordings http://archive.org/search.php?query=n1ea *Gopher Hole:* gopher://sdf.org/1/users/djringjr/ (native or with Firefox's Overbite extension) or via http to gopher gatewayhttp://gopher.floodgap.com/gopher/gw?gopher://sdf.org/1/users/djringjr/ *C**hat* Skype: djringjr MSN: djringjr@msn.com AIM: N1EA icq: 27380609
=30=
On Wed, Sep 26, 2012 at 4:09 PM, Dan Smith dsmith@danplanet.com wrote:
Update 9/28/12: Summary: I have Chirp 0.2.3 working in OSX 10.8.2 with my FT60s using an RT Systems cable. I was able to write to both radios on the first attempt with each. - No jiggling/pressure on the plug required. - The radios were left in memory mode vice VFO. - The cable is in a second-level USB hub vice plugged directly into my MacBook. - No incense was burned, no chicken entrails arranged. It worked just like a piece of modern electronic gear, imagine that.
A bit more detail: I looked at the suggestion to use a linux live CD. I'll follow up in a separate post on that, but googling around, it's complicated on a Mac; there's going to be a substantial learning curve. I thought about where I prefer to end up, which is programming my radios under OS X, vice learning exactly what's wrong with my two Prolific cables or their driver, and decided that my best course of action was to buy an FTDI-based cable. Valley Enterprises, recommended on the Chirp site, has one for $28. And for an unrelated application, I already have an FDTI driver installed that I know works.
But given my recent experience with 3rd-party cables, and this comment from Dan Smith : "For what it's worth, I have always had trouble with the FT-60 and aftermarket cables. ... other than the one from Yaesu... ". and see that for ~ $10 more, I can buy the one both HRO and Universal Radio are selling as FT60 accessories, which I assumed was the official Yaesu cable. [ Comes with Windows software I have no use for, but whatever ]. And my local HRO has it in stock, I can have it today...
So here's where I make a couple of mistakes, and then get very lucky: I somewhere thought I read that the official Yaesu cable uses FTDI. And I thought the ADMS-1J being sold for this by two major Ham retailers was the official Yaesu product.
Get the box home, plug it in, and it's clearly some funky RT systems proprietary interface (I can see that in the USB device tree), and I don't have a serial port, so it's neither Prolific nor FTDI.
So I'm wondering if HRO will take it back, the software is still sealed. But I googled for an RT systems Mac driver, and this was the first hit: http://www.rtsystemsinc.com/kb_results.asp?ID=9 Turns out RT systems isn't interested in porting their software to the Mac, but they've decided to provide a driver!
So I install it, and sonofagun, I've got a serial port named /dev/cu.usbserial-xxxxxxxx where the xxxxxxxx is the serial number for the RT device I see in the USB tree. Start up Chirp, plug in the radio, start a download, and wham, there it is. Spot checking the 100 new memories in my FT60, looks like it's all accurate.
So, I've got a working solution. I might try troubleshooting my Prolific cables, but that has lost a great deal of its urgency and interest... It's possible that RT Systems won't keep their driver up to date for OSX 10.9 or 10.10, but I should have a working solution for a couple of years at least. If I'm still alive and still care when I can't still at least boot to 10.8 from my external clone backup, I'll deal with it then.
FWIW, neither I nor my micrometer can see any significant physical difference between the 3.5mm 4-conductor radio plugs on the RT cable vice the Kawamall / eBay cables. I'm guessing the most likely issue is bad Prolific chips or the assembly/connections to them, then driver issues, with a probably pretty small chance it's a Chirp problem.
Thanks for all the support. I hope my experience will help someone else navigate this a little more surely.
-dan
I don't see a big learning curve for Linux.
You can put up CHIRP in about five minutes from the LIVE CD. You add the PPA giving the command line - cut and paste - and you have CHIRP.
You do have to find out the correct usb device number if your connecting via usb.
I could help you with that. Mac and Linux are cousins except on Linux we still have much more functionality with command line which gives us some awesome raw power.
DR David J. Ring, Jr., N1EA http://www.qsl.net/n1ea/ Radio-Officers Grouphttp://groups.google.com/group/radio-officers?hl=en-- Join CW email list http://mailman.qth.net/mailman/listinfo/cw%20 -- Historic Morse Recordings http://archive.org/search.php?query=n1ea *Gopher Hole:* gopher://sdf.org/1/users/djringjr/ (native or with Firefox's Overbite extension) or via http to gopher gatewayhttp://gopher.floodgap.com/gopher/gw?gopher://sdf.org/1/users/djringjr/ *C**hat* Skype: djringjr MSN: djringjr@msn.com AIM: N1EA icq: 27380609
=30=
I don't see a big learning curve for Linux....
This response will turn into the followup I mentioned.
I've been hacking C on unix for a living since 1983. BSD, System V, and Solaris. Starting with a VT100 and csh on a VAX. I still use vi, out of preference, for small memo files. And older OSes longer than that. I retired from Sun Microsystems in 2006.
I'm very comfortable on the command line - one of the reasons I have a Mac. I'm not much on real sysadmin or network stuff, but I can follow instructions, and have a pretty good idea what they're doing.
And I've even created a canned live-CD and booted into linux on my Mac, for an unrelated issue where the vendor couldn't (yet) get something working under OSX.
The learning curve is with creating a USB or SD-Card live image. Google around, it seems that this is very hard to do on a Mac, a lot of people asking how, nobody providing a clear recipe. I get the feeling it's possible, but I don't see a clear path to get it done. Yes, there's a dd command. But it seems tough to convince the Mac EFI that the USB volume is bootable, although a CD or DVD is straightforward.
Since your instructions required installing other software (drivers and Chirp) besides the stock linux iso, how exactly do I do that when booted on a read-only filesystem? Particularly the drivers; I could *run* chirp from a mounted USB stick after downloading. I could figure out how to add stuff to a boot image and repackage an iso - like I said, learning curve. Or sort out the bootable USB stick problem. Maybe I'm missing something there, but I still see a lot of trial and error in front of me.
And I'll repeat this from my earlier mail: for what? Suppose I can get it working under linux. Then what? My preference is to program my FT60 within OS X. If buying a different cable is the best way to get there, why spend my time sorting out these live CD issues? If that were impossible, and my alternatives were linux or Windows, or debug why the Prolific cables don't work in the hopes of being able to fix that somehow, I'd be all over it. But I thought (apparently correctly) I just had a bad cable(s) issue.
Getting more into linux is on my long list; like others, I'm disquieted by some of the directions Apple has been going since the iPhone got bigger than Mac. I won't ever use Microsoft products (look at my employment history), so linux may be where I'm headed. Too bad, I liked having a system that both runs shrinkwrap software (think TurboTax) and gives me a unix shell on the same screen. And 90% of the time, the Mac gui and built-in apps is a pleasant place.
I know this isn't your day job, but If you really want to help Mac users with linux, then provide a live CD image with the other pieces already present. Or explain to me how I add software to a read-only filesystem, maybe I'm confused.
Thanks and regards,
-dan
On Sep 28, 2012, at 2:11 PM, D.J.J. Ring Jr. - n1ea@arrl.net +chirp+cordless+7d3f38247a.n1ea#arrl.net@spamgourmet.com wrote:
On Fri, Sep 28, 2012 at 2:58 PM, chirp.cordless@xoxy.net wrote: ...
Glad you got it working!
It sounds to me like you got bit by the Prolific drivers and possibly counterfeit Prolific chips (seems to be about 90% of the topics on this mailing list). Considering both your Kawamall cables exhibited the same symptoms, I doubt it was a manufacturing anomaly.
FWIW, I buy the serial version of cables for all my radios. This way I can use my proven FTDI USB-serial cable with all of them. Having just one type of USB cable means I only need one driver (serial cables don't need drivers). This means I don't have to mess with drivers when I buy a new cable.
Tom KD7LXL
On 9/28/2012 4:58 PM, chirp.cordless@xoxy.net wrote:> Update 9/28/12:
Summary: I have Chirp 0.2.3 working in OSX 10.8.2 with my FT60s using an RT Systems cable. I was able to write to both radios on the first attempt with each.
Glad to hear things are working for you. Basically using an FTDI based cable solved your problem.
The RT Systems cables I've seen are made with FTDI chips. However they install a custom USB Vendor ID and Product ID (VID & PID) on them, so they aren't recognized by the generic FTDI virtual com port drivers.
On windows this gives them the advantage that their software is reliably able to find their cable.The user doesn't have to figure out whatcom port got assigned. The disadvantage for the user is that other software like CHIRP work with the cable because it doesn't create a COM port.
I believe the Mac driver you installed, is the same FTDI serial driverjust with the RT Systems VID and PID instead of the generic ones.
There is a utility provided by FTDI, at least for windows that will let you change the VID/PID on the chip.So you can set it back to the FTDI default and not worry about needing a special driver if you are ever so inclined. (The downside is you won't be able to use the RT software on windows since it will only work with their cable with the custom VID/PID (and the ftdi direct driver). This was discussed on this list 6 months to a year ago.)
Cool info! Thank you very much, this clears up some of my confusion.
I remember seeing the custom VID/PID thing when I downloaded the FTDI driver a few months ago, but had no idea what it was for, and I didn't need it for that unrelated cable application, which presented as an FTDI device.
-dan
On Sep 28, 2012, at 2:41 PM, "Robert Terzi - rct@r-t.org" +chirp+cordless+a79d3bb79e.rct#r-t.org@spamgourmet.com wrote:
very glad you got that working. i think that's the same driver i found following a link from an emf meter manufacturer, of all things!
i'll be updating from 10.7.5 (lion) to mountain lion soon and i hope the driver survives the trip.
and yeah, not to get into fanboi territory here, but i've run a mac since 1996 when at a ham flea market i discovered a dos window running on a powerbook. i've been linux/unix useradmin as well, but that stuff wears you out and burns you out and you can run ubuntu(64) or indeed nearly and *nix and windows 7(64) on a mac using vmware anyway. i have to use a windows xp system for work and things that just won't install at all into a native window system will fire up right away on the virtual system running on my mac. it's a better windows than windows!
so i personally can deeply appreciate you wanting to run this on your mac.
/guy
On Fri, Sep 28, 2012 at 5:18 PM, chirp.cordless@xoxy.net wrote:
Thought I'd follow up on this for the benefit of any Mac users who want to use the RT Systems cables. Thanks for the hint about this being an FTDI chip and working with the oem driver. Further research confirms it, and I now have it working with the oem FTDI driver under OS X 10.8.2. I still appreciate RT Systems providing a driver for those (like I was two days ago) that don't know about this and just want it to work. Whatever their motivation, it helped in the short run.
But I'd rather know I have no further dependency on RT Systems for driver versions for OSX 10.9 etc, and I'd prefer not to waste space on a second copy of the same FTDI driver I already had.
FTDI has a technical note TN_105 "Adding Support for New FTDI Devices to MAC Serial Driver" available at http://www.ftdichip.com/Support/Documents/TechnicalNotes.htm
Essentially the process involves adding a dozen or so lines of cut-and-paste xml to the text file Info.plist within the driver package, to create another in the list of "IOKitPersonalities", which already had 398 of them. Just add an entry for this VID/PID.
It's now working just fine in Chirp with the RT Systems driver de-installed.
The shell command instructions in the note probably work if you copy them exactly; I found them a bit clumsy and did it a little differently. What's important is what goes in Info.plist.
Thanks again for the great support from this community,
-dan
On Sep 28, 2012, at 2:41 PM, Robert Terzi - rct@r-t.org +chirp+cordless+a79d3bb79e.rct#r-t.org@spamgourmet.com wrote:
On 9/28/2012 5:12 PM, Tom Hayward wrote:>
Unfortunately, it seems like it's almost every ham group that I read has this on-going saga.
In case it helps any one else, Valley Enterprises is in the process of converting all the cables they sell to be FTDI based. Their site generally mentions FTDI and Windows 7 in the description of the cable so you can tell what you are ordering. They are also available through Amazon.
I added a link to Chirp's Cable Guide on the Wiki: http://chirp.danplanet.com/projects/chirp/wiki/CableGuide
FWIW, I purchased my cable on Ebay item #290761244715
It's a prolific chipset, no issues at all with the driver or the dual jack connector for the UV-5R radio
-----Original Message----- From: chirp_users-bounces@intrepid.danplanet.com [mailto:chirp_users-bounces@intrepid.danplanet.com] On Behalf Of Robert Terzi Sent: Friday, September 28, 2012 3:56 PM To: Discussion of CHIRP Subject: [chirp_users] FTDI based USB cables.
On 9/28/2012 5:12 PM, Tom Hayward wrote:>
Unfortunately, it seems like it's almost every ham group that I read has this on-going saga.
In case it helps any one else, Valley Enterprises is in the process of converting all the cables they sell to be FTDI based. Their site generally mentions FTDI and Windows 7 in the description of the cable so you can tell what you are ordering. They are also available through Amazon.
I added a link to Chirp's Cable Guide on the Wiki: http://chirp.danplanet.com/projects/chirp/wiki/CableGuide
_______________________________________________ chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
This e-mail (and any attachments) is confidential and may be privileged. Any unauthorized use, copying, disclosure or dissemination of this communication is prohibited. If you are not the intended recipient, please notify the sender immediately and delete all copies of the message and its attachments.
Are there any cables or cable makers which sell cables that aren't bobby trapped?
I should have to right to buy cables and use whatever I want with it.
If they want to bugger the cables, they should give them away free to run with their software.
73 DR
I opened up my RT systems cable and found that it has a FTDI chip in it. It's a standard chip, but they programmed it with their own USB vendor ID codes so that it loads their custom driver. I doubt they did this to be mean spirited, but who knows for sure. This gives them the ability to make their software work in a plug-and-play fashion where you don't need to configure any port settings. Just plug in the USB cable and it will automatically find your radio.
However, because it is a standard chip, I was able to get their cable to work by downloading the regular FTDI Virtual Serial Port (VSP) driver and forcing it to be used instead of the default one.
On Fri, Sep 28, 2012 at 3:19 PM, D.J.J. Ring, Jr. n1ea@arrl.net wrote:
I opened up my RT systems cable and found that it has a FTDI chip in it. It's a standard chip, but they programmed it with their own USB vendor ID codes so that it loads their custom driver. I doubt they did this to be mean spirited, but who knows for sure. This gives them the ability to make their software works in a plug-and-play fashion where you don't need to configure any port settings. Just plug in the USB cable and it will automatically find your radio.
However, because it's a standard chip, I was able to get their cable to work by downloading the regular FTDI Virtual Serial Port (VSP) driver and forcing it to be used instead of the default one.
Here's what worked:
- Download the VCP driver zip file and expand it to a folder - http://www.ftdichip.com/FTDrivers.htm - Open up the device manager and update the driver for the RT cable device - Go though the "let me choose" and "have disk" options to point it at the folder where the files were unzipped. - Install the driver that shows up even if it warns about it not being compatible. - The device now shows up as "USB Serial Converter", go to its properties/advanced tab and check the box called "Load VCP". - Unplug the device and plug it back in - A new com port device will show up, but a driver will not load for it automatically. - Go thought the same process as before to install the driver from that unzipped folder.
On Fri, Sep 28, 2012 at 3:19 PM, D.J.J. Ring, Jr. n1ea@arrl.net wrote:
Just be careful not to put in the wrong vid and pids....you brick it. I was doing development on some USB products last year, and had some of their parts. There was a work around to unbrick, but I don't recall now what it was. Bricking...meaning that the drivers no longer can see it, so then you can't run the utility to put it back again. With XP you can sometimes fix it in the .inf file but don't do it with win7 or win8
From: chirp_users-bounces@intrepid.danplanet.com [mailto:chirp_users-bounces@intrepid.danplanet.com] On Behalf Of Cory (NQ1E) Sent: Friday, September 28, 2012 4:54 PM To: Discussion of CHIRP Subject: Re: [chirp_users] FTDI based USB cables.
I opened up my RT systems cable and found that it has a FTDI chip in it. It's a standard chip, but they programmed it with their own USB vendor ID codes so that it loads their custom driver. I doubt they did this to be mean spirited, but who knows for sure. This gives them the ability to make their software works in a plug-and-play fashion where you don't need to configure any port settings. Just plug in the USB cable and it will automatically find your radio.
However, because it's a standard chip, I was able to get their cable to work by downloading the regular FTDI Virtual Serial Port (VSP) driver and forcing it to be used instead of the default one.
Here's what worked:
- Download the VCP driver zip file and expand it to a folder - http://www.ftdichip.com/FTDrivers.htm - Open up the device manager and update the driver for the RT cable device - Go though the "let me choose" and "have disk" options to point it at the folder where the files were unzipped. - Install the driver that shows up even if it warns about it not being compatible. - The device now shows up as "USB Serial Converter", go to its properties/advanced tab and check the box called "Load VCP". - Unplug the device and plug it back in - A new com port device will show up, but a driver will not load for it automatically. - Go thought the same process as before to install the driver from that unzipped folder.
On Fri, Sep 28, 2012 at 3:19 PM, D.J.J. Ring, Jr. <n1ea@arrl.netmailto:n1ea@arrl.net> wrote: Are there any cables or cable makers which sell cables that aren't bobby trapped?
I should have to right to buy cables and use whatever I want with it.
If they want to bugger the cables, they should give them away free to run with their software.
73 DR
_______________________________________________ chirp_users mailing list chirp_users@intrepid.danplanet.commailto:chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
This e-mail (and any attachments) is confidential and may be privileged. Any unauthorized use, copying, disclosure or dissemination of this communication is prohibited. If you are not the intended recipient, please notify the sender immediately and delete all copies of the message and its attachments.
No, no... I'm not talking about reprogramming the chip to use the standard codes. I just forced it to use the standard driver (no risk of bricking). This allows it to show up as a standard serial port and work with CHIRP. However, since* *I didn't change the codes, it still works with the RT software as well.
On Fri, Sep 28, 2012 at 4:04 PM, Harrison Cooper HCooper@fusionio.comwrote:
Ahh that's very interesting. If I'm following what you did on some version of windows, what you did was to replace the driver that was associated with the RT VID/PID with the current FTDI driver, which let you then tell it to provide a Virtual COM Port (VCP) in addition to the FTDI Direct I/O interface.
(In other words you associated the FTDI drivers with the RT VID/PID without having to edit the .inf file.)
On 9/28/2012 6:54 PM, Cory (NQ1E) wrote:
That's exactly what happened. It's working for me perfectly on Windows 7 using the RT cable for my Yaesu VX-8R.
On Fri, Sep 28, 2012 at 4:13 PM, Robert Terzi rct@r-t.org wrote:
That is just pure mean spirited. Why should anyone sell a cable that is intentionally buggered so it doesn't work with other types of software.
That's almost evil.
DR David J. Ring, Jr., N1EA http://www.qsl.net/n1ea/ Radio-Officers Grouphttp://groups.google.com/group/radio-officers?hl=en-- Join CW email list http://mailman.qth.net/mailman/listinfo/cw%20 -- Historic Morse Recordings http://archive.org/search.php?query=n1ea *Gopher Hole:* gopher://sdf.org/1/users/djringjr/ (native or with Firefox's Overbite extension) or via http to gopher gatewayhttp://gopher.floodgap.com/gopher/gw?gopher://sdf.org/1/users/djringjr/ *C**hat* Skype: djringjr MSN: djringjr@msn.com AIM: N1EA icq: 27380609
=30=
On Fri, Sep 28, 2012 at 5:55 PM, Robert Terzi rct@r-t.org wrote:
On 9/26/2012 3:00 PM, chirp.cordless@xoxy.net wrote:
To me it sounds like it might be a signaling problem in the cable. Possibly the voltage on the TXD line is too low for the FT-60s to reliably read.
Check the cable with a meter or a scope. I don't know the FT-60 so I don't know if it's a 0-5 Vdc (TTL) interface or a 0-3.3 Vdc interface. If you measure the radio's TxD line (which will be the RxD line going into the computer, you should be able to see if the radio's holding it at 5 Volts or 3.3 Volts.
Also are you using a USB port on the actual computer or on a hub? I would try to use ports on the computer, or if you must use a hub try a powered hub to make sure the USB cable is getting enough power.
Hope This Helps, --Rob
I seem to recall that I could read the FT-60, but not write to it, if the keypad lock was ON.
I remember that it drove me nuts at the time. :-)
Apologies if you've already checked for this. Just thought I'd bring it up, just in case it might be the issue.
On 09/27/2012 08:48 AM, Robert Terzi wrote:
On 9/26/2012 3:00 PM, chirp.cordless@xoxy.net wrote:
What's next?
Another thing you could try is to do a loop back test of your cable with the cable disconnected from the radio.
IIRC some of the Yaesu cables share a pin for TxD and RxD so the computer will read back anything that it sends. I don't know the FT-60 so you'll need to look up the wiring of the cable.
If it isn't that type of cable, you can set up your own loop back test by shorting the cables TxD and RxD pins together. Of course be careful not to short anything else.
Once you've got TxD and RxD connected, you should be able to go into a terminal program and see anything you type echoed back.
Just a thought. --Rob
I think Rob has an EXCELLENT idea there.. having a "cable test" feature in Chirp just to do some testing (data integrity tests, etc) would probably help a LOT of people troubleshoot. If the test fails, Chirp could open a dialog box telling say Ubuntu people to make sure their username is in the dialout category, check the baud rates on their radio (list some common baud rates for some common manufacturers, etc). Give a URL to a FAQ on bad Prolific drivers (windows, Mac, etc.)
With all that, the user is more empowered to fix things themselves, get less of this stuff on the email list, etc.
--David
On Thu, Sep 27, 2012 at 11:26 AM, David Ranch chirp@trinnet.net wrote:
Patches are welcome! But I'm not sure how you're thinking of implementing this...
- A cable test as Rob suggested involves shorting two pins on the cable--not something Chirp can do for you. - This test will succeed regardless of baud rate. - Chirp already reports an error on Ubuntu if permissions don't allow opening the serial port (so nothing new needed here).
Feel free to add some Windows/OSX driver warnings to the FAQ: http://chirp.danplanet.com/projects/chirp/wiki/FAQ#Cables
Tom KD7LXL
Further, if (as Rob suggested) you have a 3.3v converter in your cable, then a loopback test will succeed, even though a clone may fail. Claiming that the cable is good in such a way would mislead users away from legitimate cable issues I think, without providing *too* much benefit.
I'd rather spend time making sure that the drivers that expect echoes properly report the case where echoes are not received as a separate error from a lack of response from the radio.
On 27/09/2012 20:09, Tom Hayward wrote:
But we have some radio, like the FT60 itself, that use cables with tx and rx shorted. Right now we simply throw away the echoed char in those drivers as far as I know.
Starting with them can be better than nothing ...
just my two cents ....
73 de IZ3GME Marco
Guess I'll step in (it) here as well
Seems to me there are a couple of issues going on
First, comm ports...ie....is the computer even talking to the cable. Cable meaning the USB UART, and in this case the drivers looking for the prolific chips. You can use a number of utilities available, at least on a PC (sorry Mac and Linux users..but im sure the Linux community has similar things) to go out and query a device on the USB to get its VID and PID. So if in the hardware manager, you have a banged (for win7) or unknown device connected, that simply means the driver is not loaded and then you can check the USB.org listing of VID numbers. For win7, those can also be found under the properties. Bottom line..you can identify what USB UART you have sitting there. Once you get the correct driver, it should work as the software simply says...push data in and out of com port N. Correct me if I'm wrong authors, but you could care less what device is there, just as long as the OS knows it's a com port and it can set it up. FYIW, the VID and PID are located in the driver .inf file, so you can open that up and check to see if your VID and PID are listed. That's typically why a driver wont work (or be found). Word of caution...DONT edit that file if your on win7, as then it will no longer be a signed driver...and win7 insists on that. XP...you ok to edit (why would you tho?).
So now you have a valid driver, and really what you have is a USB UART serial interface. USB one side, TTL (5V or 3.3V) serial on the other. I haven't looked close enough to see if the big pin is tx or rx, and polarity but the circuits are on the web.
Using a com program (putty, Xterm, etc) you can do two things.
First tie the tips together (assuming they are the hot signals) and you ought to have a loop back. Just type and it should come back on the screen.
Second, if someone who is an author can chime in...whats the typical baud rate, etc for the port setup and how do you put it into the command mode? You should be able to check it that way as well. FYIW, I have the UV5R, connecting to TeraTerm I didn't see anything coming out. Rather surprised, I would have thought it would have sent a string but since it's the mic connector as well...maybe you have to send it something first.
So that's my 2cents worth.
-----Original Message----- From: chirp_users-bounces@intrepid.danplanet.com [mailto:chirp_users-bounces@intrepid.danplanet.com] On Behalf Of IZ3GME Marco Sent: Thursday, September 27, 2012 12:24 PM To: Discussion of CHIRP Subject: Re: [chirp_users] Help needed, can't write to Yaesu FT-60
On 27/09/2012 20:09, Tom Hayward wrote:
But we have some radio, like the FT60 itself, that use cables with tx and rx shorted. Right now we simply throw away the echoed char in those drivers as far as I know.
Starting with them can be better than nothing ...
just my two cents ....
73 de IZ3GME Marco _______________________________________________ chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
This e-mail (and any attachments) is confidential and may be privileged. Any unauthorized use, copying, disclosure or dissemination of this communication is prohibited. If you are not the intended recipient, please notify the sender immediately and delete all copies of the message and its attachments.
So, I'll wait for the new cable, I guess.
For what it's worth, I have always had trouble with the FT-60 and aftermarket cables. The only way I'm ever able to get a reliable upload into the radio is by trial-and-error and exerting lateral force on the connector with one hand while starting the transfer with the other.
I'm not sure if the FT-60 has an odd jack or some construction detail that makes this necessary for cables other than the one from Yaesu, but I have seen it consistently over the several FT-60s I've used.
Try pushing on it from every which way and see if you can make some progress on the upload.
participants (13)
-
Aubrey Turner
-
chirp.cordless@xoxy.net
-
Cory (NQ1E)
-
D.J.J. Ring, Jr.
-
Dan Smith
-
David Ranch
-
Guy Teague
-
Harrison Cooper
-
IZ3GME Marco
-
Jay Moran, WC3K
-
Robert Terzi
-
Tom Hayward
-
W4GRJ