I have no ties to Chirp other than as a user... I've had similar problems that you describe. The failures for me was that the official Prolific MacOSX Driver did not like my counterfeit USB cables (three different ones) for my Wouxon, iCOM, and Yaesu radios. Once I found the driver I pointed you to, all three of my cables started working perfectly.<br>
<br>As to why the Windows Driver would work with your cable, I can't help you there. I left Windows many years back and try to never go back. From what someone else said, sounds like Windows has many different versions of drivers that can work for you.<br>
<br>As to your specific failures above, you may want to try running the commands that failed with "sudo" in front of it and type your password to allow it to run as a superuser/admin.<br><br>Good luck!<br>Jay<br>
<br><div class="gmail_quote">On Thu, Sep 13, 2012 at 3:58 PM, Guy Teague <span dir="ltr"><<a href="mailto:accts@gtweb.org" target="_blank">accts@gtweb.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
you make some sense in places and some good points (although i don't pretend to understand the plumbing of vmware and an 'emulated' system) and some of your info is very useful. but i fail to understand how windows can accept what you are calling a 'counterfeit' chip and mac rejects it.<div>
<br></div><div>i'm using the latest daily build (2012_0912) of chirp on both mac and windows, btw.</div><div><br></div><div>it seems to me that just because the code base is the same, it doesn't mean that code interacts with the os's the same. that is what i meant by my caveat ' ... on my particular system'. for example, there could be a usb bus timing issue (my symptoms could easily indicate this) that vmware/chirp//windows handles perfectly and mac/chirp doesn't tolerate at all. bear in mind i'm no programmer--at least not since hp-basic and cobol decades ago.</div>
<div><br></div><div>and yes, i own some of those clunky keyspan adaptors. this isn't my first rodeo on connecting radios to computers! [g] also, i used to have to have them to connect my macs to cisco console ports, so they are very useful, but clunky and i don't think i should have to haul one out and buy a serial cable to make this work. for that matter, i could also shut down my vm's, unplug all my usb devices, and re-start in safe mode, but using chirp on the mac is not worth that much work since it works perfectly in windows emulation and doesn't seem to be very useful as a frequency management tool--just as a backup and repository. for example, i can't find a way to change all the power setting fields from 'high' to 'low' at once as you can do in an application like uv6d commander by clicking the column header. for some reason, both the uv5r and the uv6d default to high power and i spend a lot of time setting all the fields back to low.</div>
<div><br></div><div>i do appreciate you guys trying to help, but i'm getting a very protective, defensive tone about the software here and i guess that's understandable. if i put hours of work into a project and it worked for most people and i was at the mercy of hardware and flaky installs, i'll bet i'd be a little touchy too. i troubleshoot for a living, so i do sympathize.</div>
<div><br></div><div>tks, /guy (73 de kg5vt)<div><div class="h5"><br><br><div class="gmail_quote">On Thu, Sep 13, 2012 at 5:38 PM, Dan Smith <span dir="ltr"><<a href="mailto:dsmith@danplanet.com" target="_blank">dsmith@danplanet.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>> and the mac version of chirp does not seem to have the /file/open stock<br>
> config and the /radio/import stock config modules although i'll be the<br>
> first to admit they are non-essential, although very useful in setting<br>
> up a new radio.<br>
<br>
</div>The driver and base UI code is 100% the same on all platforms. Not sure<br>
which version you're using, but I'll let Tom comment on whether there's<br>
a bug in exposing the stock config menu items.<br>
<div><br>
> it seems to be a mixed bag as to whether it works or not for any<br>
> particular person.<br>
<br>
</div>Well, the common thread there is that few people are using a cable from<br>
a known source. Sure, they all bought them from the same eBayer, or the<br>
same chinese importer. However, the cables are all sourced from the<br>
lowest bidder on a day-to-day basis. Further, if knock-off USB chips<br>
aren't a sure bet for sporadic issues, I don't know what would be :)<br>
<br>
I'm not sure if you're trying to suppose that CHIRP is at fault for it<br>
being flaky on the Mac. If you are, and knowing that the code<br>
responsible for talking to the radio is 100% the same for all three<br>
platforms, then I'm not sure I'm going to change your mind.<br>
<div><br>
> Installing the kext file can be done in a few easy steps:<br>
> download and extract<br>
> cd /path/to/osx-pl2303.kext<br>
> cp -R osx-pl2303.kext /System/Library/Extensions/<br>
> next you need to fix permissions and execute bits:<br>
> cd /System/Library/Extensions<br>
> chmod -R 755 osx-pl2303.kext<br>
> chown -R root:wheel osx-pl2303.kext<br>
> cd /System/Library/Extensions<br>
> kextload ./osx-pl2303.kext<br>
> kextcache -system-cache<br>
><br>
><br>
> these commands fail at the 'kextload' command:<br>
><br>
> roma:Extensions sysop$ kextload ./osx-pl2303.kext<br>
> /System/Library/Extensions/osx-pl2303.kext failed to load -<br>
> (libkern/kext) not privileged; check the system/kernel logs for<br>
> errors or try kextutil(8).<br>
><br>
><br>
> here's the kextlog entry:<br>
><br>
> Sep 13 16:28:32 roma kernel[0]:<br>
> nl_bjaelectronics_driver_PL2303(0xffffff803ff47000)::configureDevice<br>
> - unable to open device for configuration<br>
><br>
<br>
</div>Man, this is rough. Were you the one complaining about Linux usability? :)<br>
<div><br>
> 2) i agree from long experience that seemingly random or erratic success<br>
> would usually indicate a short or flaky cable or hardware. but the fact<br>
> that it works perfectly with two radios and two cable using a windows7<br>
> emulator on the mac using the exact same usb port indicates (to me at<br>
> least) the problem is with the mac software--at least as it runs on my<br>
> particular system.<br>
<br>
</div>You know that the driver has nothing to do with the pass-through<br>
scenario of running it within a Windows VM, right? In that case, the USB<br>
port (or the PCI device, depending on your configuration) is yanked from<br>
the host OS and given to the guest. In that case, it's 100% windows<br>
drivers talking to hardware, which is why things start to work. In fact,<br>
there is almost no more perfect test to rule out everything _except_ the<br>
MacOS driver. Bravo :)<br>
<br>
I'd bet you a beer that if you go out and get a KeySpan USB adapter and<br>
a 9-pin kenwood programming cable, that you'd have zero problems. That<br>
would eliminate the counterfeit USB chip and the odd driver issues<br>
(KeySpan is one of the only hardware providers that cares about your<br>
boutique platform). However, it would cost almost as much as your radio<br>
did in the first place :)<br>
<span><font color="#888888"><br>
--<br>
Dan Smith<br>
<a href="http://www.danplanet.com" target="_blank">www.danplanet.com</a><br>
KK7DS<br>
<br>
</font></span></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
chirp_users mailing list<br>
<a href="mailto:chirp_users@intrepid.danplanet.com">chirp_users@intrepid.danplanet.com</a><br>
<a href="http://intrepid.danplanet.com/mailman/listinfo/chirp_users" target="_blank">http://intrepid.danplanet.com/mailman/listinfo/chirp_users</a><br>
<br></blockquote></div><br>