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-cachethese 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? :)
- 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 :)