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