<p dir="ltr">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. :)</p>
<p dir="ltr">Jay<br>
--<br>
Sent on a tiny touch screen device; apologies for errors.</p>
<div class="gmail_quote">On Sep 18, 2012 12:38 AM, "Guy Teague" <<a href="mailto:accts@gtweb.org">accts@gtweb.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
hi folks:<div><br></div><div>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.</div>
<div><br></div><div>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></div>
<div><br></div><div>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.</div>
<div><br></div><div>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: <a href="http://www.prolific.com.tw/US/CustomerLogin.aspx" target="_blank">http://www.prolific.com.tw/US/CustomerLogin.aspx</a> and 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).</div>
<div><br></div><div>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 ...</div>
<div><br></div><div>... 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!</div>
<div><br></div><div>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.</div>
<div><br></div><div>again, thanks to all!</div><div><br></div><div>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.</div>
<div><br></div><div>/guy (73 de kg5vt)<br><br><div class="gmail_quote">On Thu, Sep 13, 2012 at 7:02 PM, Guy Teague <span dir="ltr"><<a href="mailto:accts@gtweb.org" target="_blank">accts@gtweb.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">hi dan:<div><br></div><div>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.</div>
<div><br></div><div>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.<br>
<br>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>/guy (73 de kg5vt)<br><br><div class="gmail_quote"><div><div>On Thu, Sep 13, 2012 at 6:44 PM, Dan Smith <span dir="ltr"><<a href="mailto:dsmith@danplanet.com" target="_blank">dsmith@danplanet.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div>> you make some sense in places and some good points (although i don't<br>
> pretend to understand the plumbing of vmware and an 'emulated' system)<br>
> and some of your info is very useful. but i fail to understand how<br>
> windows can accept what you are calling a 'counterfeit' chip and mac<br>
> rejects it.<br>
<br>
</div>My point was that the MacOS driver is completely out of the loop when<br>
the device is passed through to Windows. The details of why the Windows<br>
driver is better than the MacOS driver stems from the fact that the<br>
former gets a lot more development attention and testing (as does the<br>
whole Windows USB stack, for that matter). By the way, lots of Windows<br>
folks have trouble with the drivers as well, but it seems like the last<br>
official version before Prolific started trying to exclude the<br>
counterfeit chips is an easy choice for most.<br>
<div><br>
> it seems to me that just because the code base is the same, it doesn't<br>
> mean that code interacts with the os's the same. that is what i meant by<br>
> my caveat ' ... on my particular system'. for example, there could be a<br>
> usb bus timing issue (my symptoms could easily indicate this) that<br>
> vmware/chirp//windows handles perfectly and mac/chirp doesn't tolerate<br>
> at all.<br>
<br>
</div>There are several layers between CHIRP and the OS dealing with the<br>
serial line communication that are there to make that a non-issue.<br>
Further, the timing in question (especially with your particular radio)<br>
is extremely lax and not something that would be affected by minor<br>
differences in otherwise high-speed hardware. If you were complaining<br>
about a Yaesu driver, I'd be considering other options (or hiding :)<br>
<br>
On MacOS, it's difficult because there's no native software to prove<br>
that the driver is to blame. On Windows, that's easy and clear, of course.<br>
<div><br>
> and yes, i own some of those clunky keyspan adaptors. this isn't my<br>
> first rodeo on connecting radios to computers! [g] also, i used to have<br>
> to have them to connect my macs to cisco console ports, so they are very<br>
> useful, but clunky and i don't think i should have to haul one out and<br>
> buy a serial cable to make this work.<br>
<br>
</div>Well, that's your call. You're on a platform that doesn't get nearly the<br>
attention of the other one. That means that not every combination of<br>
hardware is going to work flawlessly, as you have come to see. If you<br>
feel that you shouldn't have to use ugly hardware (as most Mac users<br>
seem to feel) then continuing to chase the driver issues is likely to be<br>
your preferred course. You could also try to find someone that makes a<br>
known-good programming cable with a USB hood on it (which is often<br>
difficult). However, the fact is, you're not going to get support for<br>
your chinese knock-off cable from the manufacturer, nor the manufacturer<br>
of the hardware they knocked off, nor your platform vendor.<br>
<br>
We are telling you that the problem is well-understood and we're trying<br>
to provide you with ways around it. As a Lexus owner will tell you, it's<br>
a different TCO equation than owning a Toyota, even though it's just a<br>
car, and is made in the same factory, with nearly the same parts.<br>
<div><br>
> i do appreciate you guys trying to help, but i'm getting a very<br>
> protective, defensive tone about the software here and i guess that's<br>
> understandable. if i put hours of work into a project and it worked for<br>
> most people and i was at the mercy of hardware and flaky installs, i'll<br>
> bet i'd be a little touchy too. i troubleshoot for a living, so i do<br>
> sympathize.<br>
<br>
</div>Yep, we're a little touchy. Mostly because we're well-aware of the<br>
issues, but really can't do much about them for you. You have, at times,<br>
sounded a little accusatory, and I can't really blame you for that.<br>
However, remember that we're all volunteers (as are the folks that<br>
attempt to write one of the MacOS drivers that tolerate counterfeit chips).<br>
<br>
So, sorry for sounding a bit short. All we can do is tell you what we<br>
know, ask you to treat us with respect, and ask you to trust us that<br>
we're not just brushing you off.<br>
<div><div><br>
--<br>
Dan Smith<br>
<a href="http://www.danplanet.com" target="_blank">www.danplanet.com</a><br>
KK7DS<br>
<br>
</div></div><br></div></div><div>_______________________________________________<br>
chirp_users mailing list<br>
<a href="mailto:chirp_users@intrepid.danplanet.com" target="_blank">chirp_users@intrepid.danplanet.com</a><br>
<a href="http://intrepid.danplanet.com/mailman/listinfo/chirp_users" target="_blank">http://intrepid.danplanet.com/mailman/listinfo/chirp_users</a><br>
<br></div></blockquote></div><br></div>
</blockquote></div><br></div>
<br>_______________________________________________<br>
chirp_users mailing list<br>
<a href="mailto:chirp_users@intrepid.danplanet.com">chirp_users@intrepid.danplanet.com</a><br>
<a href="http://intrepid.danplanet.com/mailman/listinfo/chirp_users" target="_blank">http://intrepid.danplanet.com/mailman/listinfo/chirp_users</a><br>
<br></blockquote></div>