Mac Serial to USB drivers?

333 views
Skip to first unread message

Edwin Hadi

unread,
Aug 12, 2017, 3:47:46 PM8/12/17
to golden-cheetah-users
Hi All - have a noob question... I'm trying to get a SRM PCV working with Golden Cheetah on a Mac, and I see the link to the Mac Prolific serial to usb drivers at this website:

however, the site appears to be down... is there another source for those changux.co drivers?

As an alternative, I found this website selling Mac serial to usb Prolific drivers:

...which appear to allow my Mac to recognize the SRM on the USB cable based on some of the suggested troubleshooting commands in the terminal, but am getting a cannot load a library error (libftd2xx.dylib.) in Golden Cheetah (both v3.4 and the 3.5dev) indicating no serial devices found. If I use the mac-usb-serial.com drivers, do I need to modify anything from the normal installation or do I perhaps not have that configured/set up correctly?

Many thanks!

Rainer Clasen

unread,
Aug 13, 2017, 2:25:05 AM8/13/17
to golden-cheetah-users
Edwin Hadi wrote:
> As an alternative, I found this website selling Mac serial to usb Prolific
> drivers:
> https://mac-usb-serial.com/docs/support/specifications-prolific-pl2303-driver.html

They seem to provide different names for the devices:
"Unix file-descriptor access (/dev/cu.Repleo-PL2303-xxx, /dev/tty.Repleo-PL2303-xxx)"

So, even if this driver works, GC won't recognize the name.

If you want to test this driver, create a symlink and GC will recognize
it:

- plugin the cable/converter
- get the name that was assigned by the driver (likely the last entry):
ls -lrt /dev/cu.* | tail
- create a symlink:
ln -s cu.<name> /dev/cu.usbserial
- start GC, try to download, ignore unrelated libftd2xx error ;)

If this works reliably, we can add the names used by this driver to GCs
whitelist (in FileIO/Serial.cpp:find_devices()).

Rainer

--
KeyID=759975BD fingerprint=887A 4BE3 6AB7 EE3C 4AE0 B0E1 0556 E25A 7599 75BD

Edwin Hadi

unread,
Aug 14, 2017, 10:15:24 AM8/14/17
to golden-cheetah-users
Thanks! I'll give it a try this evening...

Is there another source for those changux.co drivers you may know of? The site was down when I tried to access it...

Thanks again!

Edwin Hadi

unread,
Aug 14, 2017, 9:29:58 PM8/14/17
to golden-cheetah-users
Hi Rainer - if you have a few min, I could use a little more help!

"ls -lrt /dev/cu.* | tail" returned:

crw-rw-rw-  1 root  wheel    9,   3 Aug 12 10:09 /dev/cu.lpss-serial2

crw-rw-rw-  1 root  wheel    9,   1 Aug 12 10:09 /dev/cu.lpss-serial1

crw-rw-rw-  1 root  wheel    9,   5 Aug 12 10:09 /dev/cu.Bluetooth-Incoming-Port

crw-rw-rw-  1 root  wheel    9,  13 Aug 14 21:11 /dev/cu.Repleo-PL2303-00004014


but: "ln -s cu.Repleo-PL2303-00004014 /dev/cu.usbserial" returned an operation not permitted error: 
"ln: /dev/cu.usbserial: Operation not permitted"

Did I do something wrong? (entered with admin/su level access) or any other thoughts?

Thanks!

Rainer Clasen

unread,
Aug 15, 2017, 12:15:04 PM8/15/17
to golden-cheetah-users
Edwin Hadi wrote:
> but: "ln -s cu.Repleo-PL2303-00004014 /dev/cu.usbserial" returned an
> operation not permitted error:
> "ln: /dev/cu.usbserial: Operation not permitted"
>
> Did I do something wrong? (entered with admin/su level access) or any other
> thoughts?

Hm, does /dev/cu.usbserial exist? Use 'ls -l /dev/cu.usberial' to verify.
If it exists, try to get it out of the way (rm -f /dev/cu.usbserial)
before retrying to create teh symlink.

Though, presence of this device node should result in a different error.
So, a permission thingy is more likely...

Maybe somebody with more OSX skills can help... or prepare a test build
that recognizes the original device name (sorry, don't have the systems to
do that).

Edwin Hadi

unread,
Aug 15, 2017, 7:57:52 PM8/15/17
to golden-cheetah-users
appreciate your help! 

unfortunately "ls -l /dev/cu.usbserial" returns:
"ls: /dev/cu.usbserial: No such file or directory"

so still stuck... any other ideas?!

thanks in advance!

Edwin Hadi

unread,
Aug 19, 2017, 11:13:24 AM8/19/17
to golden-cheetah-users
As an update, I was able to get GC (3.4 and 3.5) to recognize my PCV with the SRM PCV USB cable using the following drivers from Prolific:

(The changux.co site appears to be down permanently). I removed the mac-usb-serial.com drivers as i could not get the symlink to work...

As long as you push "mode" on the PCV and get away from the time/date screen before initiating the download, GC will reliably recognize the PCV and begin the download. 

Now, however, I'm running into another issue... it seems to always have a problem towards the last several blocks of the download saying that the data covers too much time. I read from another thread that this could be due to the time being set incorrectly on the PCV -I had a few files on the PCV that I had not been able to download so I erased everything through SRMWin, sync'd the PCV clock with the computer's and went for another ride... but i'm still having the same "data covers too much time" error. SRMWin has also not been able to save anything. Anyone have any ideas? 

Thanks!

Rainer Clasen

unread,
Aug 19, 2017, 2:15:07 PM8/19/17
to golden-cheetah-users
Hi,

Edwin Hadi wrote:
> As an update, I was able to get GC (3.4 and 3.5) to recognize my PCV with
> the SRM PCV USB cable using the following drivers from Prolific:
> http://www.prolific.com.tw/US/ShowProduct.aspx?p_id=229&pcid=41
>
> (The changux.co site appears to be down permanently). I removed the
> mac-usb-serial.com drivers as i could not get the symlink to work...
>
> As long as you push "mode" on the PCV and get away from the time/date
> screen before initiating the download, GC will reliably recognize the PCV
> and begin the download.
>
> Now, however, I'm running into another issue... it seems to always have a
> problem towards the last several blocks of the download saying that the
> data covers too much time. I read from another thread that this could be
> due to the time being set incorrectly on the PCV -I had a few files on the
> PCV that I had not been able to download so I erased everything through
> SRMWin, sync'd the PCV clock with the computer's and went for another
> ride... but i'm still having the same "data covers too much time" error.
> SRMWin has also not been able to save anything. Anyone have any ideas?

let me put it this way: finding a *reliable* prolific driver for windows
and especially Osx was by magnitudes the most tricky bit of porting the
SRM download code from linux to these systems. I think we tried all
drivers for Osx that were available at that time and only a single one
worked. Of course, the original prolific drivers were the first we
tried... and they were the worst as they seemed to work, but caused
consistenly corrupted data during the download. Your symptoms sound
exactly like the pain I was going through at that time.

I'm really sorry, I can't help with this. The Osx system I had access to
for testing the SRM download doesn't exist, anymore :(

Rainer

Mark Liversedge

unread,
Aug 23, 2017, 6:12:10 AM8/23/17
to golden-cheetah-users
I would concur. The prolific serial devices aren't great.
I ended up replacing mine with a keyspan, but that was for a computrainer.

Mark

Rainer Clasen

unread,
Aug 23, 2017, 10:21:48 AM8/23/17
to golden-cheetah-users

Mark Liversedge wrote:
> I would concur. The prolific serial devices aren't great.
> I ended up replacing mine with a keyspan, but that was for a computrainer.

which isn't that easy for the PCV ... as the prolific is integrated into
the cable with their funny plug.

I seem to remember, that srmwin is also looking at USB IDs to find the
PCV, but I'm not sure if you can bypass this. I'm also remembering people
talking about PCV cables without integrated USB2serial adapter... But I
have no idea if they built one their own or of SRM offered them.

So, you really end up with driver-roulette. Linux and FreeBSD work out of
the box. Windows needs the driver you can download from SRM (which
magically makes other prolific converters work, too).

I have no idea if there's still a working driver available for OSX... the
link Edwin posted does sound promising, but for testing, this would
require a GC build that recognizes the device names of this driver.

Rainer
Reply all
Reply to author
Forward
0 new messages