OpenCPN baud rate > 115200

[codger]

I'm having issues setting the baud rate on a serial USB connection in OpenCPN (running on Ubuntu) to 460800, as required by the ShipModul MiniPlex3 series. I can set the baud rate manually in a terminal window and see the NMEA stream just fine, but OpenCPN does not seem to be able to do the same. (The only way I have successfully got NMEA data in via the serial USB is to set the port speed in minicom and keep the program running; this seems to be a workaround to let OpenCPN read the datastream on the serial port correctly.)

I have found a ticket for a recent OpenCPN version that claims the dropdown menu choices for baud rate do not work for > 115200, and proposes a simple fix that apparently works:

https://opencpn.org/flyspray/index.p...s&task_id=2371

Is there anything I can do to elevate this bug so that the devs can take a look and, if appropriate, implement the proposed fix?

Thanks!
Dave

[codger]

I opened a new ticket in FS:

https://opencpn.org/flyspray/index.p...s&task_id=2426

I hope I did this correctly...

[sy_gilana]

This is a total guess, but...



Try changing the settings in opencpn.conf which is in /home/[USER]/.opencpn


You must enable view of hidden files.
Make a backup copy of the .conf file.


Search for the string NMEAData, and it should look something like mine below...


Change the Baud Rate there.


(Unless the physical properties of your port cannot handle that (USB version))





[Settings/NMEADataSource]
DataConnections=0;2;;0;0;/dev/ttyUSB1;38400;1;0;0;AIVDM,AIVDO;0;;1;0;1;0;1|0;2;0 .0.0.0;0;0;/dev/ttyUSB2;4800;1;0;0;;0;;1;0;0;0;1|0;2;0.0.0.0;0;0;/dev/ttyUSB0;4800;1;0;0;AIVDM,AIVDO;0;;1;0;0;0;0

[rgleason]

Did you vote for this Tracker item?
Also get your friends and others to vote for it.
Get more than 7 votes and it gets moved to the higher priority "Vetted Feature Requests" List.


Also I've looked at the tracker item.
Please modify it to explain clearly why you want this capability!!
You need good reasons and examples, so the Development team can justify the necessary work and debugging required.

[codger]

Originally Posted by rgleason

Also get your friends and others to vote for it.

Hello friends and others... can you please vote for my tracker item?

It's right here: https://opencpn.org/flyspray/index.p...s&task_id=2426

Originally Posted by rgleason

Please modify it to explain clearly why you want this capability!!

I will do this, certainly. However, on the face of it, if the baudrate is right there in the dropdown list, shouldn't the application prima facie support it? If it's not intended that the app support baudrates faster than 115200, maybe the faster options should be removed from the dropdown list.

On the other hand, the OP in the previous tracker item reports that when he adds three lines of code to the source and compiles it, the faster speeds work. If this is the case, it would seem that this is one bug that would be easy to squish.

[codger]

Originally Posted by sy_gilana

Try changing the settings in opencpn.conf which is in /home/[USER]/.opencpn

OpenCPN is properly saving the serial port setups in opencpn.conf. If I create three serial port connections, as a random example: /dev/ttyUSB0, /dev/ttyUSB1, and /dev/ttyUSB2 in OpenCPN, and set one at 460800, the second at 9600, and the third at 115200, when I open opencpn.conf I see the three ports dutifully listed with their requested speeds. So the dropdown menu item is correctly adding data connections to NMEADataSource.

[BlackSea]

you are right... More than 115200 is currently not possible
https://github.com/OpenCPN/OpenCPN/b...hread.cpp#L829


Fix is trivial. Do you want to try it yourself and then pass the patch on to developers or should someone do it for you?

[transmitterdan]

I can submit a pull request to github adding these rates:

230400, 460800, 921600

Will that be good enough?

[BlackSea]

Yeah, do that.
the main thing is that it reflects this
https://github.com/OpenCPN/OpenCPN/b...ions.cpp#L1449

[transmitterdan]

Ok, I will make up a portable change and submit it to GitHub. Not all POSIX systems support those higher baud rates. So it will have to be dependent on whether the Linux driver supports the higher rates. There is nothing we can do about it if they don't support higher rates. I think nearly all modern systems support up to 921600.

[codger]

Originally Posted by BlackSea

Fix is trivial. Do you want to try it yourself and then pass the patch on to developers or should someone do it for you?

I'd be happy to, but looks like TransmitterDan is already on the case. Thanks TDan, much appreciated.

It seems at present that adding this baudrate will mainly help users trying to connect a ShipModul MiniPlex 3 multiplexer in Linux. In Windows, the ShipModul custom drivers fix the baudrate and ignore application settings, so users in Windows are never even aware that OpenCPN isn't actually changing the baud rate of the port; the mux works anyway, no matter what baud rate you specify in the application. In Linux though it's a different story. The ftdi_sio driver recognizes the device and sets up the port, but the application layer needs to correctly set the baud rate for communication with the serial port.

Until OpenCPN is fixed, I'm looking at running a kplex daemon to catch the incoming NMEA0183 from the serial port (kplex doesn't support 460800 in the stable distribution, but does in the dev branch) and broadcast it over UDP locally on my laptop. That might be a better setup anyway, as then the data are available to OpenCPN and any other application I might want at the same time.

[codger]

Originally Posted by transmitterdan

Ok, I will make up a portable change and submit it to GitHub. Not all POSIX systems support those higher baud rates. So it will have to be dependent on whether the Linux driver supports the higher rates. There is nothing we can do about it if they don't support higher rates. I think nearly all modern systems support up to 921600.

I think that's a perfectly okay situation. There are clearly users (myself among them) who would like higher speeds to be available, as there is popular and useful hardware out there for our boats that requires this speed. The onus should be on the user to determine whether their system / driver supports the baud rate requested of the serial port, it's not the application's responsibility.

The irony of it is, in my understanding, that ShipModul tried to get the maintainer of the linux ftdi_sio driver to fix the baudrate for their MiniPlex3 series to 460800 by hardcoding it in the driver (there are apparently other examples of this being done in the driver code) so that when their PID is detected the driver would fix the baudrate to 460800, akin to what they do with their windows drivers. The driver maintainers refused their request however, so the onus is still on the application to specify the port speed.

[transmitterdan]

I think this issue only affects POSIX (Linux, MAC and maybe Android) systems. POSIX uses a weird bit combination to set each specific baud rate. The code can’t be easily calculated so they use a series of named constants. That’s why there is that big case statement.

The Windows serial port code is completely different.