[chirp_users] Please post

Jay Moran
Tue Sep 18 03:40:03 PDT 2012


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 at 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 at 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 at 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 at intrepid.danplanet.com
>>> http://intrepid.danplanet.com/mailman/listinfo/chirp_users
>>>
>>>
>>
>
> _______________________________________________
> chirp_users mailing list
> chirp_users at intrepid.danplanet.com
> http://intrepid.danplanet.com/mailman/listinfo/chirp_users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_users/attachments/20120918/f98ea2f1/attachment.html 


More information about the chirp_users mailing list