[chirp_users] Please post

[Guy Teague]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_users/attachments/20120913/baa4a060/attachment.html