Mac OS X 10.8.1 driver to program Wouxun KG-UV3D using Chirp
I am trying to program a Wouxun UV3D HT using Chirp software and my iMac, running on Mountain Lion (10.8.1). I've found a driver that loads fine on the iMac and is recognized by Chirp (/dev/cu.usbserial). This is the driver - md_PL2303_MacOSX10.6_dmg_v1.4.0. The problem is that when I attempt to download the Wouxun I get an error that a radio is not "responding." I'm using Wouxun's USB to radio cable.
What am I missing? Is there a secret Wouxun cloning mode? Any help would be greatly appreciated.
73, David KF4VCA
read the section reagarding the cable it will tell you how to fix that lproblem On Sep 13, 2012 11:42 AM, "David Henderson" dehenderson@mac.com wrote:
Mac OS X 10.8.1 driver to program Wouxun KG-UV3D using Chirp
I am trying to program a Wouxun UV3D HT using Chirp software and my iMac,
running on Mountain Lion (10.8.1). I've found a driver that loads fine on the iMac and is recognized by Chirp (/dev/cu.usbserial). This is the driver - md_PL2303_MacOSX10.6_dmg_v1.4.0. The problem is that when I attempt to download the Wouxun I get an error that a radio is not "responding." I'm using Wouxun's USB to radio cable.
What am I missing? Is there a secret Wouxun cloning mode? Any help would
be greatly appreciated.
73, David KF4VCA
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
read the section about the cable it will tell you how to fix it. it is not a software issue
there are evidently major problems on the mac. i have basically the same setup and with both the uv5r and the uv6d and two different cables i can only get the mac to recognize the radio perhaps once out of two dozen attempts--download or upload.
using windows7 64-bit via vmware on the same mac same usb port same cable succeeds every single time, so obviously there is no fault with the radio(s) or cable(s) or usb port conflict.
also, i noticed the mac version of chirp does not have all the functions of the windows version and requires yet more python modules to support radio reference db. i consider myself lucky to have the windows workaround because i think if you had a mac only and had to depend on the chirp port you would be very frustrated.
/guy (73 de kg5vt)
On Thu, Sep 13, 2012 at 10:47 AM, John Coleman colemantools@gmail.com wrote:
read the section reagarding the cable it will tell you how to fix that lproblem
On Sep 13, 2012 11:42 AM, "David Henderson" dehenderson@mac.com wrote:
Mac OS X 10.8.1 driver to program Wouxun KG-UV3D using Chirp
I am trying to program a Wouxun UV3D HT using Chirp software and my iMac, running on Mountain Lion (10.8.1). I've found a driver that loads fine on the iMac and is recognized by Chirp (/dev/cu.usbserial). This is the driver
- md_PL2303_MacOSX10.6_dmg_v1.4.0. The problem is that when I attempt to
download the Wouxun I get an error that a radio is not "responding." I'm using Wouxun's USB to radio cable.
What am I missing? Is there a secret Wouxun cloning mode? Any help would be greatly appreciated.
73, David KF4VCA
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
read the section about the cable it will tell you how to fix it. it is not a software issue
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
On Thu, Sep 13, 2012 at 2:15 PM, Guy Teague accts@gtweb.org wrote:
there are evidently major problems on the mac. i have basically the same setup and with both the uv5r and the uv6d and two different cables i can only get the mac to recognize the radio perhaps once out of two dozen attempts--download or upload.
using windows7 64-bit via vmware on the same mac same usb port same cable succeeds every single time, so obviously there is no fault with the radio(s) or cable(s) or usb port conflict.
also, i noticed the mac version of chirp does not have all the functions of the windows version and requires yet more python modules to support radio reference db. i consider myself lucky to have the windows workaround because i think if you had a mac only and had to depend on the chirp port you would be very frustrated.
/guy (73 de kg5vt)
Please quit spewing FUD. I use Chirp on my Mac and prefer it to Windows. All Chirp features are available on all operating systems. That's the whole point of Chirp. I wrote the Radio Reference support on my Mac and it works just fine.
The issue with your cable is undoubtedly with the OS X drivers. Avoid the counterfeit PL2303 cables; everything else works great.
Tom KD7LXL
I have to agree with Tom here. After finding the right driver for my counterfeit PL2303 USB adapters, everything has been great running on MacOSX.
I used this driver for 10.7... http://xbsd.nl/2011/07/pl2303-serial-usb-on-osx-lion.html
If you are using 10.8, not sure if it work or not. I'll be upgrading soon and will find out.
Jay
On Thu, Sep 13, 2012 at 1:19 PM, Tom Hayward esarfl@gmail.com wrote:
On Thu, Sep 13, 2012 at 2:15 PM, Guy Teague accts@gtweb.org wrote:
there are evidently major problems on the mac. i have basically the same setup and with both the uv5r and the uv6d and two different cables i can only get the mac to recognize the radio perhaps once out of two dozen attempts--download or upload.
using windows7 64-bit via vmware on the same mac same usb port same cable succeeds every single time, so obviously there is no fault with the radio(s) or cable(s) or usb port conflict.
also, i noticed the mac version of chirp does not have all the functions of the windows version and requires yet more python modules to support radio reference db. i consider myself lucky to have the windows workaround because i think if you had a mac only and had to depend on the chirp port you would be very frustrated.
/guy (73 de kg5vt)
Please quit spewing FUD. I use Chirp on my Mac and prefer it to Windows. All Chirp features are available on all operating systems. That's the whole point of Chirp. I wrote the Radio Reference support on my Mac and it works just fine.
The issue with your cable is undoubtedly with the OS X drivers. Avoid the counterfeit PL2303 cables; everything else works great.
Tom KD7LXL _______________________________________________ chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
perhaps you missed the part where i said chirp works flawlessly using windows7 on vmware running on the _same_ mac using _exactly the same_ hardware and usb port. and my wouxun cable came from an official wouxun dealer.
now i won't deny that perhaps i've gotten ahold of the wrong driver or haven't gotten it installed correctly on the mac. i went to at least a dozen, maybe two dozen, websites and tried everything i could find. if there was an authoritative source that had actual links to actual files that actually worked that might help. any links you can find point to pages where you have to mount new searches and choose between multiple options to the point where you end up completely confused. don't get me wrong--i am a grizzled veteran of such unix/linux scavenger hunts for drivers and software--it's a major factor in keeping linux off desktops, imo.
if you are actually able to help instead of trying to suppress constructive critcism, here is the output of my kextstat command:
161 0 0xffffff7f809bd000 0xb000 0xb000 nl.bjaelectronics.driver.PL2303 (1.0.0d1) <115 31 5 4 3>
is that the right driver?
/guy (73 de kg5vt)
On Thu, Sep 13, 2012 at 3:19 PM, Tom Hayward esarfl@gmail.com wrote:
On Thu, Sep 13, 2012 at 2:15 PM, Guy Teague accts@gtweb.org wrote:
there are evidently major problems on the mac. i have basically the same setup and with both the uv5r and the uv6d and two different cables i can only get the mac to recognize the radio perhaps once out of two dozen attempts--download or upload.
using windows7 64-bit via vmware on the same mac same usb port same cable succeeds every single time, so obviously there is no fault with the radio(s) or cable(s) or usb port conflict.
also, i noticed the mac version of chirp does not have all the functions of the windows version and requires yet more python modules to support radio reference db. i consider myself lucky to have the windows workaround because i think if you had a mac only and had to depend on the chirp port you would be very frustrated.
/guy (73 de kg5vt)
Please quit spewing FUD. I use Chirp on my Mac and prefer it to Windows. All Chirp features are available on all operating systems. That's the whole point of Chirp. I wrote the Radio Reference support on my Mac and it works just fine.
The issue with your cable is undoubtedly with the OS X drivers. Avoid the counterfeit PL2303 cables; everything else works great.
Tom KD7LXL _______________________________________________ chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
On Thu, Sep 13, 2012 at 2:45 PM, Guy Teague accts@gtweb.org wrote:
perhaps you missed the part where i said chirp works flawlessly using windows7 on vmware running on the _same_ mac using _exactly the same_ hardware and usb port. and my wouxun cable came from an official wouxun dealer.
That's exactly how I knew it was a driver problem. The Chirp code is exactly the same on Windows and OS X, so that's not a factor. You say the USB port is the same, so it's not the port. Must be the driver. I believe the official Wouxun cable contains a counterfeit PL2303 chip. Prolific has crippled their drivers so that only genuine Prolific chips work. When you buy cheap Chinese radios, they may come with some counterfeit chips. That's the cost of buying the cheapest thing available.
now i won't deny that perhaps i've gotten ahold of the wrong driver or haven't gotten it installed correctly on the mac. i went to at least a dozen, maybe two dozen, websites and tried everything i could find. if there was an authoritative source that had actual links to actual files that actually worked that might help. any links you can find point to pages where you have to mount new searches and choose between multiple options to the point where you end up completely confused. don't get me wrong--i am a grizzled veteran of such unix/linux scavenger hunts for drivers and software--it's a major factor in keeping linux off desktops, imo.
There's no authoritative source because there's no authority for counterfeit chips!
FYI, Linux desktops come preinstalled with virtually every driver available. Even these counterfeit chips work great. I just installed Windows 7 for the first time last weekend and it was a 3+ hour ordeal trying to catch up on all the updates and install the drivers. A moden Linux desktop install is 5-10 minutes and when it's done you'll be completely up to date with all drivers installed and working.
if you are actually able to help instead of trying to suppress constructive critcism, here is the output of my kextstat command:
161 0 0xffffff7f809bd000 0xb000 0xb000 nl.bjaelectronics.driver.PL2303 (1.0.0d1) <115 31 5 4 3>
is that the right driver?
/guy (73 de kg5vt)
Those numbers just looks like gibberish to me (I'm sure they do to you too!). I've never heard of bjaelectronics. I recommend you uninstall that driver and try the one that Jay suggested in a previous message.
Tom KD7LXL
yes, i'm running 10.7.4 on the latest imac.
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.
it seems to be a mixed bag as to whether it works or not for any particular person. for every person on the baofeng_uv5r list who has it working on mac there is another like me for whom it only works sporadically. so far no one who has it working has enough unix savvy to pass along the pertinent info so that i can compare my system against theirs, such as the kextstat i posted.
my driver is loaded by evidence of the kextstat command and i can access the driver using zterm and scrt and i get the driver in the dropdown menu when trying to upload/download the radio.
the instructions that accompany the driver at the link you posted fail towards the end. first, for some reason (maybe it doesn't matter to him) he fails to note that the kext 'file' is not really a file, it's a package. thus it appears in the terminal as a folder and none of the commands he lists really match up because a folder shows a trailing '/':
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 *
and that's where i get stuck not wanting to invest 4 hours in poring through system logs or learning how to use kextutil and working with kext files at all is not for the faint of heart and even i know enough not to push it to far. just one errant kext file can brick your osx system if things go wrong.
and if you look in the comments following the link at the page you posted you'll see references to the 'nl ...' file that is showing on my system. i think this is because the prolific driver (which all this is based on) is in the netherlands and the 'nl ...' is the name of the actual driver in the 'package'
so if anyone can tell me why 'kextload' doesn't work on my particular system, i might be able to get a little further along in troubleshooting this. but my troubleshooting table goes like this so far:
1) since this works every once in awhile, the driver or kext file is at least loaded and (sometimes) working. 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.
/guy (73 de kg5vt)
On Thu, Sep 13, 2012 at 4:00 PM, Tom Hayward esarfl@gmail.com wrote:
On Thu, Sep 13, 2012 at 2:45 PM, Guy Teague accts@gtweb.org wrote:
perhaps you missed the part where i said chirp works flawlessly using windows7 on vmware running on the _same_ mac using _exactly the same_ hardware and usb port. and my wouxun cable came from an official wouxun dealer.
That's exactly how I knew it was a driver problem. The Chirp code is exactly the same on Windows and OS X, so that's not a factor. You say the USB port is the same, so it's not the port. Must be the driver. I believe the official Wouxun cable contains a counterfeit PL2303 chip. Prolific has crippled their drivers so that only genuine Prolific chips work. When you buy cheap Chinese radios, they may come with some counterfeit chips. That's the cost of buying the cheapest thing available.
now i won't deny that perhaps i've gotten ahold of the wrong driver or haven't gotten it installed correctly on the mac. i went to at least a dozen, maybe two dozen, websites and tried everything i could find. if there was an authoritative source that had actual links to actual files that actually worked that might help. any links you can find point to pages where you have to mount new searches and choose between multiple options to the point where you end up completely confused. don't get me wrong--i am a grizzled veteran of such unix/linux scavenger hunts for drivers and software--it's a major factor in keeping linux off desktops, imo.
There's no authoritative source because there's no authority for counterfeit chips!
FYI, Linux desktops come preinstalled with virtually every driver available. Even these counterfeit chips work great. I just installed Windows 7 for the first time last weekend and it was a 3+ hour ordeal trying to catch up on all the updates and install the drivers. A moden Linux desktop install is 5-10 minutes and when it's done you'll be completely up to date with all drivers installed and working.
if you are actually able to help instead of trying to suppress constructive critcism, here is the output of my kextstat command:
161 0 0xffffff7f809bd000 0xb000 0xb000 nl.bjaelectronics.driver.PL2303 (1.0.0d1) <115 31 5 4 3>
is that the right driver?
/guy (73 de kg5vt)
Those numbers just looks like gibberish to me (I'm sure they do to you too!). I've never heard of bjaelectronics. I recommend you uninstall that driver and try the one that Jay suggested in a previous message.
Tom KD7LXL _______________________________________________ chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
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 :)
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@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-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 configurationMan, 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 :)
-- Dan Smith www.danplanet.com KK7DS
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@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@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-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 configurationMan, 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 :)
-- Dan Smith www.danplanet.com KK7DS
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
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@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@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@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-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 configurationMan, 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 :)
-- Dan Smith www.danplanet.com KK7DS
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
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.
Just a bit of education...
UNIX (POSIX) is a userland abstraction, not a kernel one. The Linux (or Windows) drivers live in the kernel have have nearly zero overlap from platform to platform. It's not a matter of porting it, it's a matter of (re-)writing one for the particular kernel. An entirely different process from 'porting' a userland application that you may be used to.
MacOS and Linux share a lot of userland POSIX API points (not ABI, note) which make them look similar from the user side of the fence, but they are wholly different on the kernel side (which is where the driver lives).
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.
My point was that the MacOS driver is completely out of the loop when the device is passed through to Windows. The details of why the Windows driver is better than the MacOS driver stems from the fact that the former gets a lot more development attention and testing (as does the whole Windows USB stack, for that matter). By the way, lots of Windows folks have trouble with the drivers as well, but it seems like the last official version before Prolific started trying to exclude the counterfeit chips is an easy choice for most.
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.
There are several layers between CHIRP and the OS dealing with the serial line communication that are there to make that a non-issue. Further, the timing in question (especially with your particular radio) is extremely lax and not something that would be affected by minor differences in otherwise high-speed hardware. If you were complaining about a Yaesu driver, I'd be considering other options (or hiding :)
On MacOS, it's difficult because there's no native software to prove that the driver is to blame. On Windows, that's easy and clear, of course.
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.
Well, that's your call. You're on a platform that doesn't get nearly the attention of the other one. That means that not every combination of hardware is going to work flawlessly, as you have come to see. If you feel that you shouldn't have to use ugly hardware (as most Mac users seem to feel) then continuing to chase the driver issues is likely to be your preferred course. You could also try to find someone that makes a known-good programming cable with a USB hood on it (which is often difficult). However, the fact is, you're not going to get support for your chinese knock-off cable from the manufacturer, nor the manufacturer of the hardware they knocked off, nor your platform vendor.
We are telling you that the problem is well-understood and we're trying to provide you with ways around it. As a Lexus owner will tell you, it's a different TCO equation than owning a Toyota, even though it's just a car, and is made in the same factory, with nearly the same parts.
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.
Yep, we're a little touchy. Mostly because we're well-aware of the issues, but really can't do much about them for you. You have, at times, sounded a little accusatory, and I can't really blame you for that. However, remember that we're all volunteers (as are the folks that attempt to write one of the MacOS drivers that tolerate counterfeit chips).
So, sorry for sounding a bit short. All we can do is tell you what we know, ask you to treat us with respect, and ask you to trust us that we're not just brushing you off.
hi dan:
yeah, after basically 3 days of trying to make this (mac/chirp) work off and on and after 20 failures in a row to connect and then going to my desktop with windows7/chirp running and having it work perfectly each and every time (i have not had a single failure to connect or pass data in well over a hundred trials with two different radio models--a tribute to the robustness of chirp running on windows7--a record i know even commercial software would be proud of), i probably did come here with a chip on my shoulder when i saw chirp mentioned as working well on the mac. i apologize if i came off as passive-aggressive. [g] and that robustness of windows/chirp makes it even more frustrating that i can't get it working on the mac.
i built the first pc from a kit and have working in the field since then, so i'm fairly platform agnostic and have been sysadmin for unix and unix-clone systems over the years. but as i get older i find myself less and less willing to do the work and maintenance to keep linux and windows running smoothly and protect windows from malware and viruses. thus i'm using a mac--and especially because it lets me run (via vmware) windows and ubuuntu in a window on my mac so i can somewhat keep up with the big three and, as in the case of these radios, have a way to support devices that the mac won't support. i'm not a gamer so i don't need the bootcamp option and, in any case, i like having the mac available all the time.
anyway, based on what you are saying, i guess i have to conclude now that either i have a bad driver, the driver is not installed correctly, or the driver doesn't like either one of my two differently-sourced cables. but what throws this theory under the bridge or at least makes it harder to troubleshoot is that if i persevere long enough, i can actually get the radio and chirp to talk and pass data native on the mac without changing anything from my windows setup.
again, i appreciate all efforts to help me out and as we were saying--you have to make a tradeoff as to whether the effort is worth it to me personally. in my case with the windows7 workaround which is as easy as moving to a different window and a couple of clicks, i have to say that it's not worth the effort to get mac/chirp working. but the fact is that i've been a tech troubleshooter all my life and i can rarely step back from a challenge and i got sucked into this one trying this and that here and there.
/guy (73 de kg5vt)
On Thu, Sep 13, 2012 at 6:44 PM, Dan Smith dsmith@danplanet.com 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.
My point was that the MacOS driver is completely out of the loop when the device is passed through to Windows. The details of why the Windows driver is better than the MacOS driver stems from the fact that the former gets a lot more development attention and testing (as does the whole Windows USB stack, for that matter). By the way, lots of Windows folks have trouble with the drivers as well, but it seems like the last official version before Prolific started trying to exclude the counterfeit chips is an easy choice for most.
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.
There are several layers between CHIRP and the OS dealing with the serial line communication that are there to make that a non-issue. Further, the timing in question (especially with your particular radio) is extremely lax and not something that would be affected by minor differences in otherwise high-speed hardware. If you were complaining about a Yaesu driver, I'd be considering other options (or hiding :)
On MacOS, it's difficult because there's no native software to prove that the driver is to blame. On Windows, that's easy and clear, of course.
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.
Well, that's your call. You're on a platform that doesn't get nearly the attention of the other one. That means that not every combination of hardware is going to work flawlessly, as you have come to see. If you feel that you shouldn't have to use ugly hardware (as most Mac users seem to feel) then continuing to chase the driver issues is likely to be your preferred course. You could also try to find someone that makes a known-good programming cable with a USB hood on it (which is often difficult). However, the fact is, you're not going to get support for your chinese knock-off cable from the manufacturer, nor the manufacturer of the hardware they knocked off, nor your platform vendor.
We are telling you that the problem is well-understood and we're trying to provide you with ways around it. As a Lexus owner will tell you, it's a different TCO equation than owning a Toyota, even though it's just a car, and is made in the same factory, with nearly the same parts.
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.
Yep, we're a little touchy. Mostly because we're well-aware of the issues, but really can't do much about them for you. You have, at times, sounded a little accusatory, and I can't really blame you for that. However, remember that we're all volunteers (as are the folks that attempt to write one of the MacOS drivers that tolerate counterfeit chips).
So, sorry for sounding a bit short. All we can do is tell you what we know, ask you to treat us with respect, and ask you to trust us that we're not just brushing you off.
-- Dan Smith www.danplanet.com KK7DS
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
hi folks:
off work today and thought i'd give this mac/chirp/driver thing another go. about a month ago i got an emf meter that does logging to a pc and it also uses the prolific pl2303 driver and the company that sold the radio (tenmars) offered a mac driver in a .dmg package, meaning no command line stuff if the installer works right.
after doing all the research trying to get this working i got the idea that the crux of the problem is that these radio manufacturers pirated some chips or code to put into the cables and prolific retaliated (dumbasses, say i) by making their drivers not work with the pirated chips. sort of like what panasonic tried to do by modifying their firmware to reject 3rd-party batteries--yeah, that got 'em so _great_ pr! </sarcasm>
so the solution for the radios seems to be to find a prolific driver that is older than the retaliation code and install it. why i'm having 100% success windows and not mac if this is the sole reason for problems is unclear--is it harder on the mac side to find an older driver and share it with others? i don't know.
so anyway, i decided to try the driver this meter company recommended. 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.aspxand 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).
in any event, now when i go into mac/chirp and select /download from radio/ i now have 3 pl2303 drivers to select from and this newest one doesn't even have 2303 in the name, it just says something like 'cu...' well, let me go see ...
... it says /dev/cu.usbserial. the first download from the uv5r worked fine and i wanted to copy channels from a uv6d into the uv5r so i switched the cable over and downloaded from the uv6d into a chirp tab--this also worked fine. i then figured out how to copy the channels from the 6d into the 5r window and tried to upload to the uv5r, but this operation failed again and again. i tried wiggling the cable, off/on, replugging usb, clearing caches. but then i remembered something i'd read somewhere and changed the uv5r from channel mode (where it had been all the time) to vfo mode. bambangboom and bobs your uncle!
so i much appreciate all the help and tips and info you guys gave me and i have no idea why i couldn't get anything to work until now. now i have some more hours of research ahead of me to figure out how to uninstall the other pl2303 drivers that are loaded and not working. it can't be good to have 3 drivers loaded into kext all for the same thing.
again, thanks to all!
oh, and if anyone who is running 10.7.4 needs this specific driver pkg i'll be more than happy to zip up the .dmg file and email it to them if their gateway will accept a 5mb file email attachment.
/guy (73 de kg5vt)
On Thu, Sep 13, 2012 at 7:02 PM, Guy Teague accts@gtweb.org wrote:
hi dan:
yeah, after basically 3 days of trying to make this (mac/chirp) work off and on and after 20 failures in a row to connect and then going to my desktop with windows7/chirp running and having it work perfectly each and every time (i have not had a single failure to connect or pass data in well over a hundred trials with two different radio models--a tribute to the robustness of chirp running on windows7--a record i know even commercial software would be proud of), i probably did come here with a chip on my shoulder when i saw chirp mentioned as working well on the mac. i apologize if i came off as passive-aggressive. [g] and that robustness of windows/chirp makes it even more frustrating that i can't get it working on the mac.
i built the first pc from a kit and have working in the field since then, so i'm fairly platform agnostic and have been sysadmin for unix and unix-clone systems over the years. but as i get older i find myself less and less willing to do the work and maintenance to keep linux and windows running smoothly and protect windows from malware and viruses. thus i'm using a mac--and especially because it lets me run (via vmware) windows and ubuuntu in a window on my mac so i can somewhat keep up with the big three and, as in the case of these radios, have a way to support devices that the mac won't support. i'm not a gamer so i don't need the bootcamp option and, in any case, i like having the mac available all the time.
anyway, based on what you are saying, i guess i have to conclude now that either i have a bad driver, the driver is not installed correctly, or the driver doesn't like either one of my two differently-sourced cables. but what throws this theory under the bridge or at least makes it harder to troubleshoot is that if i persevere long enough, i can actually get the radio and chirp to talk and pass data native on the mac without changing anything from my windows setup.
again, i appreciate all efforts to help me out and as we were saying--you have to make a tradeoff as to whether the effort is worth it to me personally. in my case with the windows7 workaround which is as easy as moving to a different window and a couple of clicks, i have to say that it's not worth the effort to get mac/chirp working. but the fact is that i've been a tech troubleshooter all my life and i can rarely step back from a challenge and i got sucked into this one trying this and that here and there.
/guy (73 de kg5vt)
On Thu, Sep 13, 2012 at 6:44 PM, Dan Smith dsmith@danplanet.com 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.
My point was that the MacOS driver is completely out of the loop when the device is passed through to Windows. The details of why the Windows driver is better than the MacOS driver stems from the fact that the former gets a lot more development attention and testing (as does the whole Windows USB stack, for that matter). By the way, lots of Windows folks have trouble with the drivers as well, but it seems like the last official version before Prolific started trying to exclude the counterfeit chips is an easy choice for most.
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.
There are several layers between CHIRP and the OS dealing with the serial line communication that are there to make that a non-issue. Further, the timing in question (especially with your particular radio) is extremely lax and not something that would be affected by minor differences in otherwise high-speed hardware. If you were complaining about a Yaesu driver, I'd be considering other options (or hiding :)
On MacOS, it's difficult because there's no native software to prove that the driver is to blame. On Windows, that's easy and clear, of course.
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.
Well, that's your call. You're on a platform that doesn't get nearly the attention of the other one. That means that not every combination of hardware is going to work flawlessly, as you have come to see. If you feel that you shouldn't have to use ugly hardware (as most Mac users seem to feel) then continuing to chase the driver issues is likely to be your preferred course. You could also try to find someone that makes a known-good programming cable with a USB hood on it (which is often difficult). However, the fact is, you're not going to get support for your chinese knock-off cable from the manufacturer, nor the manufacturer of the hardware they knocked off, nor your platform vendor.
We are telling you that the problem is well-understood and we're trying to provide you with ways around it. As a Lexus owner will tell you, it's a different TCO equation than owning a Toyota, even though it's just a car, and is made in the same factory, with nearly the same parts.
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.
Yep, we're a little touchy. Mostly because we're well-aware of the issues, but really can't do much about them for you. You have, at times, sounded a little accusatory, and I can't really blame you for that. However, remember that we're all volunteers (as are the folks that attempt to write one of the MacOS drivers that tolerate counterfeit chips).
So, sorry for sounding a bit short. All we can do is tell you what we know, ask you to treat us with respect, and ask you to trust us that we're not just brushing you off.
-- Dan Smith www.danplanet.com KK7DS
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
Great to hear Guy! I just upgraded to 10.8... will be fun to go through it all again if the old driver stopped working. :)
Jay -- Sent on a tiny touch screen device; apologies for errors. On Sep 18, 2012 12:38 AM, "Guy Teague" accts@gtweb.org wrote:
hi folks:
off work today and thought i'd give this mac/chirp/driver thing another go. about a month ago i got an emf meter that does logging to a pc and it also uses the prolific pl2303 driver and the company that sold the radio (tenmars) offered a mac driver in a .dmg package, meaning no command line stuff if the installer works right.
after doing all the research trying to get this working i got the idea that the crux of the problem is that these radio manufacturers pirated some chips or code to put into the cables and prolific retaliated (dumbasses, say i) by making their drivers not work with the pirated chips. sort of like what panasonic tried to do by modifying their firmware to reject 3rd-party batteries--yeah, that got 'em so _great_ pr! </sarcasm>
so the solution for the radios seems to be to find a prolific driver that is older than the retaliation code and install it. why i'm having 100% success windows and not mac if this is the sole reason for problems is unclear--is it harder on the mac side to find an older driver and share it with others? i don't know.
so anyway, i decided to try the driver this meter company recommended. 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.aspxand 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).
in any event, now when i go into mac/chirp and select /download from radio/ i now have 3 pl2303 drivers to select from and this newest one doesn't even have 2303 in the name, it just says something like 'cu...' well, let me go see ...
... it says /dev/cu.usbserial. the first download from the uv5r worked fine and i wanted to copy channels from a uv6d into the uv5r so i switched the cable over and downloaded from the uv6d into a chirp tab--this also worked fine. i then figured out how to copy the channels from the 6d into the 5r window and tried to upload to the uv5r, but this operation failed again and again. i tried wiggling the cable, off/on, replugging usb, clearing caches. but then i remembered something i'd read somewhere and changed the uv5r from channel mode (where it had been all the time) to vfo mode. bambangboom and bobs your uncle!
so i much appreciate all the help and tips and info you guys gave me and i have no idea why i couldn't get anything to work until now. now i have some more hours of research ahead of me to figure out how to uninstall the other pl2303 drivers that are loaded and not working. it can't be good to have 3 drivers loaded into kext all for the same thing.
again, thanks to all!
oh, and if anyone who is running 10.7.4 needs this specific driver pkg i'll be more than happy to zip up the .dmg file and email it to them if their gateway will accept a 5mb file email attachment.
/guy (73 de kg5vt)
On Thu, Sep 13, 2012 at 7:02 PM, Guy Teague accts@gtweb.org wrote:
hi dan:
yeah, after basically 3 days of trying to make this (mac/chirp) work off and on and after 20 failures in a row to connect and then going to my desktop with windows7/chirp running and having it work perfectly each and every time (i have not had a single failure to connect or pass data in well over a hundred trials with two different radio models--a tribute to the robustness of chirp running on windows7--a record i know even commercial software would be proud of), i probably did come here with a chip on my shoulder when i saw chirp mentioned as working well on the mac. i apologize if i came off as passive-aggressive. [g] and that robustness of windows/chirp makes it even more frustrating that i can't get it working on the mac.
i built the first pc from a kit and have working in the field since then, so i'm fairly platform agnostic and have been sysadmin for unix and unix-clone systems over the years. but as i get older i find myself less and less willing to do the work and maintenance to keep linux and windows running smoothly and protect windows from malware and viruses. thus i'm using a mac--and especially because it lets me run (via vmware) windows and ubuuntu in a window on my mac so i can somewhat keep up with the big three and, as in the case of these radios, have a way to support devices that the mac won't support. i'm not a gamer so i don't need the bootcamp option and, in any case, i like having the mac available all the time.
anyway, based on what you are saying, i guess i have to conclude now that either i have a bad driver, the driver is not installed correctly, or the driver doesn't like either one of my two differently-sourced cables. but what throws this theory under the bridge or at least makes it harder to troubleshoot is that if i persevere long enough, i can actually get the radio and chirp to talk and pass data native on the mac without changing anything from my windows setup.
again, i appreciate all efforts to help me out and as we were saying--you have to make a tradeoff as to whether the effort is worth it to me personally. in my case with the windows7 workaround which is as easy as moving to a different window and a couple of clicks, i have to say that it's not worth the effort to get mac/chirp working. but the fact is that i've been a tech troubleshooter all my life and i can rarely step back from a challenge and i got sucked into this one trying this and that here and there.
/guy (73 de kg5vt)
On Thu, Sep 13, 2012 at 6:44 PM, Dan Smith dsmith@danplanet.com 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.
My point was that the MacOS driver is completely out of the loop when the device is passed through to Windows. The details of why the Windows driver is better than the MacOS driver stems from the fact that the former gets a lot more development attention and testing (as does the whole Windows USB stack, for that matter). By the way, lots of Windows folks have trouble with the drivers as well, but it seems like the last official version before Prolific started trying to exclude the counterfeit chips is an easy choice for most.
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.
There are several layers between CHIRP and the OS dealing with the serial line communication that are there to make that a non-issue. Further, the timing in question (especially with your particular radio) is extremely lax and not something that would be affected by minor differences in otherwise high-speed hardware. If you were complaining about a Yaesu driver, I'd be considering other options (or hiding :)
On MacOS, it's difficult because there's no native software to prove that the driver is to blame. On Windows, that's easy and clear, of course.
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.
Well, that's your call. You're on a platform that doesn't get nearly the attention of the other one. That means that not every combination of hardware is going to work flawlessly, as you have come to see. If you feel that you shouldn't have to use ugly hardware (as most Mac users seem to feel) then continuing to chase the driver issues is likely to be your preferred course. You could also try to find someone that makes a known-good programming cable with a USB hood on it (which is often difficult). However, the fact is, you're not going to get support for your chinese knock-off cable from the manufacturer, nor the manufacturer of the hardware they knocked off, nor your platform vendor.
We are telling you that the problem is well-understood and we're trying to provide you with ways around it. As a Lexus owner will tell you, it's a different TCO equation than owning a Toyota, even though it's just a car, and is made in the same factory, with nearly the same parts.
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.
Yep, we're a little touchy. Mostly because we're well-aware of the issues, but really can't do much about them for you. You have, at times, sounded a little accusatory, and I can't really blame you for that. However, remember that we're all volunteers (as are the folks that attempt to write one of the MacOS drivers that tolerate counterfeit chips).
So, sorry for sounding a bit short. All we can do is tell you what we know, ask you to treat us with respect, and ask you to trust us that we're not just brushing you off.
-- Dan Smith www.danplanet.com KK7DS
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
Great to hear Guy! I just upgraded to 10.8, can't wait to start my new adventure if the old driver no longer works! :)
Jay -- Sent on a tiny touch screen device; apologies for errors. On Sep 18, 2012 12:38 AM, "Guy Teague" accts@gtweb.org wrote:
hi folks:
off work today and thought i'd give this mac/chirp/driver thing another go. about a month ago i got an emf meter that does logging to a pc and it also uses the prolific pl2303 driver and the company that sold the radio (tenmars) offered a mac driver in a .dmg package, meaning no command line stuff if the installer works right.
after doing all the research trying to get this working i got the idea that the crux of the problem is that these radio manufacturers pirated some chips or code to put into the cables and prolific retaliated (dumbasses, say i) by making their drivers not work with the pirated chips. sort of like what panasonic tried to do by modifying their firmware to reject 3rd-party batteries--yeah, that got 'em so _great_ pr! </sarcasm>
so the solution for the radios seems to be to find a prolific driver that is older than the retaliation code and install it. why i'm having 100% success windows and not mac if this is the sole reason for problems is unclear--is it harder on the mac side to find an older driver and share it with others? i don't know.
so anyway, i decided to try the driver this meter company recommended. 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.aspxand 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).
in any event, now when i go into mac/chirp and select /download from radio/ i now have 3 pl2303 drivers to select from and this newest one doesn't even have 2303 in the name, it just says something like 'cu...' well, let me go see ...
... it says /dev/cu.usbserial. the first download from the uv5r worked fine and i wanted to copy channels from a uv6d into the uv5r so i switched the cable over and downloaded from the uv6d into a chirp tab--this also worked fine. i then figured out how to copy the channels from the 6d into the 5r window and tried to upload to the uv5r, but this operation failed again and again. i tried wiggling the cable, off/on, replugging usb, clearing caches. but then i remembered something i'd read somewhere and changed the uv5r from channel mode (where it had been all the time) to vfo mode. bambangboom and bobs your uncle!
so i much appreciate all the help and tips and info you guys gave me and i have no idea why i couldn't get anything to work until now. now i have some more hours of research ahead of me to figure out how to uninstall the other pl2303 drivers that are loaded and not working. it can't be good to have 3 drivers loaded into kext all for the same thing.
again, thanks to all!
oh, and if anyone who is running 10.7.4 needs this specific driver pkg i'll be more than happy to zip up the .dmg file and email it to them if their gateway will accept a 5mb file email attachment.
/guy (73 de kg5vt)
On Thu, Sep 13, 2012 at 7:02 PM, Guy Teague accts@gtweb.org wrote:
hi dan:
yeah, after basically 3 days of trying to make this (mac/chirp) work off and on and after 20 failures in a row to connect and then going to my desktop with windows7/chirp running and having it work perfectly each and every time (i have not had a single failure to connect or pass data in well over a hundred trials with two different radio models--a tribute to the robustness of chirp running on windows7--a record i know even commercial software would be proud of), i probably did come here with a chip on my shoulder when i saw chirp mentioned as working well on the mac. i apologize if i came off as passive-aggressive. [g] and that robustness of windows/chirp makes it even more frustrating that i can't get it working on the mac.
i built the first pc from a kit and have working in the field since then, so i'm fairly platform agnostic and have been sysadmin for unix and unix-clone systems over the years. but as i get older i find myself less and less willing to do the work and maintenance to keep linux and windows running smoothly and protect windows from malware and viruses. thus i'm using a mac--and especially because it lets me run (via vmware) windows and ubuuntu in a window on my mac so i can somewhat keep up with the big three and, as in the case of these radios, have a way to support devices that the mac won't support. i'm not a gamer so i don't need the bootcamp option and, in any case, i like having the mac available all the time.
anyway, based on what you are saying, i guess i have to conclude now that either i have a bad driver, the driver is not installed correctly, or the driver doesn't like either one of my two differently-sourced cables. but what throws this theory under the bridge or at least makes it harder to troubleshoot is that if i persevere long enough, i can actually get the radio and chirp to talk and pass data native on the mac without changing anything from my windows setup.
again, i appreciate all efforts to help me out and as we were saying--you have to make a tradeoff as to whether the effort is worth it to me personally. in my case with the windows7 workaround which is as easy as moving to a different window and a couple of clicks, i have to say that it's not worth the effort to get mac/chirp working. but the fact is that i've been a tech troubleshooter all my life and i can rarely step back from a challenge and i got sucked into this one trying this and that here and there.
/guy (73 de kg5vt)
On Thu, Sep 13, 2012 at 6:44 PM, Dan Smith dsmith@danplanet.com 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.
My point was that the MacOS driver is completely out of the loop when the device is passed through to Windows. The details of why the Windows driver is better than the MacOS driver stems from the fact that the former gets a lot more development attention and testing (as does the whole Windows USB stack, for that matter). By the way, lots of Windows folks have trouble with the drivers as well, but it seems like the last official version before Prolific started trying to exclude the counterfeit chips is an easy choice for most.
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.
There are several layers between CHIRP and the OS dealing with the serial line communication that are there to make that a non-issue. Further, the timing in question (especially with your particular radio) is extremely lax and not something that would be affected by minor differences in otherwise high-speed hardware. If you were complaining about a Yaesu driver, I'd be considering other options (or hiding :)
On MacOS, it's difficult because there's no native software to prove that the driver is to blame. On Windows, that's easy and clear, of course.
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.
Well, that's your call. You're on a platform that doesn't get nearly the attention of the other one. That means that not every combination of hardware is going to work flawlessly, as you have come to see. If you feel that you shouldn't have to use ugly hardware (as most Mac users seem to feel) then continuing to chase the driver issues is likely to be your preferred course. You could also try to find someone that makes a known-good programming cable with a USB hood on it (which is often difficult). However, the fact is, you're not going to get support for your chinese knock-off cable from the manufacturer, nor the manufacturer of the hardware they knocked off, nor your platform vendor.
We are telling you that the problem is well-understood and we're trying to provide you with ways around it. As a Lexus owner will tell you, it's a different TCO equation than owning a Toyota, even though it's just a car, and is made in the same factory, with nearly the same parts.
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.
Yep, we're a little touchy. Mostly because we're well-aware of the issues, but really can't do much about them for you. You have, at times, sounded a little accusatory, and I can't really blame you for that. However, remember that we're all volunteers (as are the folks that attempt to write one of the MacOS drivers that tolerate counterfeit chips).
So, sorry for sounding a bit short. All we can do is tell you what we know, ask you to treat us with respect, and ask you to trust us that we're not just brushing you off.
-- Dan Smith www.danplanet.com KK7DS
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
participants (8)
-
Dan Smith -
David Henderson -
Guy Teague -
Jay Moran -
Jay Moran, N2JCM -
Jay Moran, WC3K
-
John Coleman -
Tom Hayward