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">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>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> 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 class="im"><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 class="im"><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 class="im"><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 class="HOEnZb"><div class="h5"><br>
--<br>
Dan Smith<br>
<a href="http://www.danplanet.com" target="_blank">www.danplanet.com</a><br>
KK7DS<br>
<br>
</div></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><br></div>