[chirp_users] Please post

Thu Sep 13 16:42:02 PDT 2012

thanks jay! yeah, i don't understand at all how a windows driver could work
with a cable, yet a mac driver fail with the same cable and then people
claim i have a bad cable. obviously the cable is not 'bad', the problem is
that certain software doesn't work well or at all with it. and if that's
the case, why not let me use the windows driver on my mac by just porting
that driver over? i know, i know--it's a lot of work, but whatever driver
works on linux should work on mac since it's unix underneath and should
take minimal porting effort.

and yeah, i did use sudo. the commands i pasted didn't show it because i
was still in the ?5-minute? authorized window where you don't actually have
to type in 'sudo' each time.

tks, /guy (73 de kg5vt)

On Thu, Sep 13, 2012 at 6:31 PM, Jay Moran, N2JCM <jay+CHIRP at tp.org> wrote:

> 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.
>
> 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.
>
> 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.
>
> Good luck!
> Jay
>
> On Thu, Sep 13, 2012 at 3:58 PM, Guy Teague <accts at gtweb.org> wrote:
>
>> 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.
>>
>> i'm using the latest daily build (2012_0912) of chirp on both mac and
>> windows, btw.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> tks, /guy (73 de kg5vt)
>>
>>
>> On Thu, Sep 13, 2012 at 5:38 PM, Dan Smith <dsmith at danplanet.com> wrote:
>>
>>> > and the mac version of chirp does not seem to have the /file/open stock
>>> > config and the /radio/import stock config modules although i'll be the
>>> > first to admit they are non-essential, although very useful in setting
>>> > up a new radio.
>>>
>>> The driver and base UI code is 100% the same on all platforms. Not sure
>>> which version you're using, but I'll let Tom comment on whether there's
>>> a bug in exposing the stock config menu items.
>>>
>>> > it seems to be a mixed bag as to whether it works or not for any
>>> > particular person.
>>>
>>> Well, the common thread there is that few people are using a cable from
>>> a known source. Sure, they all bought them from the same eBayer, or the
>>> same chinese importer. However, the cables are all sourced from the
>>> lowest bidder on a day-to-day basis. Further, if knock-off USB chips
>>> aren't a sure bet for sporadic issues, I don't know what would be :)
>>>
>>> I'm not sure if you're trying to suppose that CHIRP is at fault for it
>>> being flaky on the Mac. If you are, and knowing that the code
>>> responsible for talking to the radio is 100% the same for all three
>>> platforms, then I'm not sure I'm going to change your mind.
>>>
>>> >     Installing the kext file can be done in a few easy steps:
>>> >     download and extract
>>> >     cd /path/to/osx-pl2303.kext
>>> >     cp -R osx-pl2303.kext /System/Library/Extensions/
>>> >     next you need to fix permissions and execute bits:
>>> >     cd /System/Library/Extensions
>>> >     chmod -R 755 osx-pl2303.kext
>>> >     chown -R root:wheel osx-pl2303.kext
>>> >     cd /System/Library/Extensions
>>> >     kextload ./osx-pl2303.kext
>>> >     kextcache -system-cache
>>> >
>>> >
>>> > these commands fail at the 'kextload' command:
>>> >
>>> >     roma:Extensions sysop$ kextload ./osx-pl2303.kext
>>> >     /System/Library/Extensions/osx-pl2303.kext failed to load -
>>> >     (libkern/kext) not privileged; check the system/kernel logs for
>>> >     errors or try kextutil(8).
>>> >
>>> >
>>> > here's the kextlog entry:
>>> >
>>> >     Sep 13 16:28:32 roma kernel[0]:
>>> >
>>> nl_bjaelectronics_driver_PL2303(0xffffff803ff47000)::configureDevice
>>> >     - unable to open device for configuration
>>> >
>>>
>>> Man, this is rough. Were you the one complaining about Linux usability?
>>> :)
>>>
>>> > 2) i agree from long experience that seemingly random or erratic
>>> success
>>> > would usually indicate a short or flaky cable or hardware. but the fact
>>> > that it works perfectly with two radios and two cable using a windows7
>>> > emulator on the mac using the exact same usb port indicates (to me at
>>> > least) the problem is with the mac software--at least as it runs on my
>>> > particular system.
>>>
>>> You know that the driver has nothing to do with the pass-through
>>> scenario of running it within a Windows VM, right? In that case, the USB
>>> port (or the PCI device, depending on your configuration) is yanked from
>>> the host OS and given to the guest. In that case, it's 100% windows
>>> drivers talking to hardware, which is why things start to work. In fact,
>>> there is almost no more perfect test to rule out everything _except_ the
>>> MacOS driver. Bravo :)
>>>
>>> I'd bet you a beer that if you go out and get a KeySpan USB adapter and
>>> a 9-pin kenwood programming cable, that you'd have zero problems. That
>>> would eliminate the counterfeit USB chip and the odd driver issues
>>> (KeySpan is one of the only hardware providers that cares about your
>>> boutique platform). However, it would cost almost as much as your radio
>>> did in the first place :)
>>>
>>> --
>>> Dan Smith
>>> www.danplanet.com
>>> KK7DS
>>>
>>>
>>
>> _______________________________________________
>> chirp_users mailing list
>> chirp_users at intrepid.danplanet.com
>> http://intrepid.danplanet.com/mailman/listinfo/chirp_users
>>
>>
>
> _______________________________________________
> chirp_users mailing list
> chirp_users at intrepid.danplanet.com
> http://intrepid.danplanet.com/mailman/listinfo/chirp_users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_users/attachments/20120913/cda695c1/attachment.html 