Setting usb-serial adaptor baud rate on Macbook

[wiekeith]

A task for this weekend was to connect my Icom MA-500TR AIS to my Macbook Pro to provide GPS and AIS data for OpenCPN (v4.6.1) using a USB-serial adaptor (PL2303 chip) in conjunction with an RS232-RS422 converter.

As a first-off I configured it to run on a Windows version of OpenCPN (v4.6.1) running in a Parallels virtual environment on the Macbook. I installed the latest Prolific usbserial driver for Windows, configured it for 38,400 bps, selected it in OpenCPN, set it to 38,400 bps, and it worked straight off - no problems - and there are no errors showing in the NMEA debug window.

However, the Mac installation (v 10.12.4) did not go so well. Once again I downloaded the latest Prolific usbserial driver, but realised after installing it that there was no way (that I could see) of configuring its baud rate. I downloaded a third-party application that’s suggested by Prolific for doing so, but I’m not convinced it worked.

OpenCPN running in the Mac environment, which is configured the same as the Windows version, recognises and connects to it at 38,400, but it’s receiving rubbish - see screenshot of the NMEA debug window.

My guess is that the usbserial driver needs to be set to 38,400 bps, but I don’t know how to do that. In fact, I don’t even know how to check what it’s actually set to as default. So any suggestions or pointers would be welcome.

The one thing I do know is that the USB-serial adaptor is providing correct NMEA sentences at 38,400 bps, which OpenCPN can read in a Windows environment.

[Scott Berg]

Dump the prolific and get a Keyspan unit from Tripplite
They are very well supported in all OS's including Win*, Mac, Linux, etc

https://www.tripplite.com/keyspan-hi...apter~USA19HS/

[barnakiel]

Hmmm. Possibly you have any other adapter around? Have you tried it?

I did not know they are programmable in any other way than possibly(?) by the OS declaring the baud at connect.

Very interesting. All ears here too.

b.

[CarCode]

Originally Posted by wiekeith

A task for this weekend was to connect my Icom MA-500TR AIS to my Macbook Pro to provide GPS and AIS data for OpenCPN (v4.6.1) using a USB-serial adaptor (PL2303 chip) in conjunction with an RS232-RS422 converter.

As a first-off I configured it to run on a Windows version of OpenCPN (v4.6.1) running in a Parallels virtual environment on the Macbook. I installed the latest Prolific usbserial driver for Windows, configured it for 38,400 bps, selected it in OpenCPN, set it to 38,400 bps, and it worked straight off - no problems - and there are no errors showing in the NMEA debug window.

However, the Mac installation (v 10.12.4) did not go so well. Once again I downloaded the latest Prolific usbserial driver, but realised after installing it that there was no way (that I could see) of configuring its baud rate. I downloaded a third-party application that’s suggested by Prolific for doing so, but I’m not convinced it worked.

OpenCPN running in the Mac environment, which is configured the same as the Windows version, recognises and connects to it at 38,400, but it’s receiving rubbish - see screenshot of the NMEA debug window.

My guess is that the usbserial driver needs to be set to 38,400 bps, but I don’t know how to do that. In fact, I don’t even know how to check what it’s actually set to as default. So any suggestions or pointers would be welcome.

The one thing I do know is that the USB-serial adaptor is providing correct NMEA sentences at 38,400 bps, which OpenCPN can read in a Windows environment.

I guess you are using perhaps a wrong com port in macOS.
When your Prolific USB-Serial adapter is connected to the Mac (not to the virtual machine!) please check first which com ports are available. To do so open the Terminal app from Utilities folder and issue this command:
ls -l /dev/cu*
An example output of my MacBookPro is:
crw-rw-rw- 1 root wheel 19, 11 7 Mai 02:50 /dev/cu.Bluetooth-Incoming-Port
crw-rw-rw- 1 root wheel 19, 3 7 Mai 02:50 /dev/cu.HUAWEIMobile-Diag
crw-rw-rw- 1 root wheel 19, 1 7 Mai 02:50 /dev/cu.HUAWEIMobile-Pcui
crw-rw-rw- 1 root wheel 19, 7 7 Mai 02:50 /dev/cu.HeidiPhone-WirelessiAP
crw-rw-rw- 1 root wheel 19, 9 7 Mai 02:50 /dev/cu.Qstarz818XT-SPPslave
crw-rw-rw- 1 root wheel 19, 5 7 Mai 02:50 /dev/cu.RO4800-BT-DevB

So I get the AIS data from my VHF radio and have configured /dev/cu.RO4800-BT-DevB with 38400 baud in OpenCPN.

If you have problems to configure OpenCPN for com ports you may also check the serial connection with CoolTerm for Mac, see Roger Meier's Freeware

Gerhard

[smac999]

They are never set in drivers. Only in software that looks at it.

[wiekeith]

Thanks for the pointer Scott Berg. I took a look at the Tripp-lite, but their latest driver is only for OS 10.10.*, so it may not support 10.12.*?

Carcode. Yes, I had done as you suggested, thanks for the input though, and the com port was available. I also used CoolTerm, which was the third-part ap I referred to in the OP. Using this ap as a terminal, set to 38,400, the data was the same as that seen in the OpenCPN debug window. Hmm... looks like the baud rate issue was a red herring only part, as smac999 has pointed out.

Barnakiel. I'll have another one by tomorrow I've ordered an adaptor using the FTDI chipset this time, mainly because the latest driver for it is dated March of this year, so will hopefully support 10.12.*

Thanks for all the input folks, very much appreciated, especially as I'm relatively new to Macs (as you can probably tell...). Let's see what tomorrow brings when the new adaptor arrives - I'll keep you posted.

[wiekeith]

Success! The new USB-serial adaptor arrived, Mac driver install took less than 30 secs - no reboot required - it worked

The Windows driver install took a few minutes, and that worked too.

As for the original adaptor: I initially considered consigning it to the bin, but thinking about it, it worked fine with Windows, so I suspect the Mac driver is the issue. Out of curiosity, I'll wait for the next Prolific release of a Mac driver and give it another try. In the meantime it's a spare that I can at least use with Windows.

FYI, the new adaptor is a UGreen USB 2.0 RS232 Adaptor, part number 20218, which I used in conjunction with a Hexin RS232-RS422/RS485 converter, part number HXSP-09F69.

Once again, thanks for everyone's input.

[Scott Berg]

[QUOTE=wiekeith;2388409]Thanks for the pointer Scott Berg. I took a look at the Tripp-lite, but their latest driver is only for OS 10.10.*, so it may not support 10.12.*?

The current TrippLite Driver works fine with my 10.12.4 system; just tested it again
S

[barnakiel]

Great news. Very happy to hear it works now for you!

I looked up the cable and my spanish amazon website says ftdi in the header, prolific in the tech specs, UGreen homesite does not seem to say what chipset it is. Argghhh if they could not agree if once! ;-)

Cheers,
b.

[wiekeith]

Originally Posted by Scott Berg

The current TrippLite Driver works fine with my 10.12.4 system; just tested it again

Ah, that's useful to know, thanks. Considering Tripplite use the PL2303 chip, it may work with the adaptor I have? An experiment for another day I think

Edit: that's the Prolific adaptor I'm referring to, not the new UGreen one :-)

[wiekeith]

Originally Posted by barnakiel

I looked up the cable and my spanish amazon website says ftdi in the header, prolific in the tech specs, UGreen homesite does not seem to say what chipset it is.

I know, all a bit confusing, but I can confirm it is the FTDI chipset.

[CarCode]

Many people claimed about Prolific and PL2303. That is not new. They are well known to be buggy. Always use adapters with FTDI chip or the more expensive but far better Keyspan USA-19HS.

Gerhard