Kplex baud rate

[Justin Arundell]

I've finally connected a  Shipmodul miniplex-3USB-N2k to my Raspberry Pi with the intention of providing my NMEA data across the boat wifi network
using kplex.

Initially I am interested only in reading the data flow, however down the track I may set up opencpn or similar and wish to send some data to the instruments.

My problem is that Shipmodul in their wisdom have set the baud rate to 460800 and that kplex doesn't handle that baud rate. When I received their email I thought that the number was a typo, however I have configured a udev rule to set that baud rate when the miniplex is plugged in and have tested the input from /dev/ttyUSB0 at that baud rate and the data stream to the terminal appears to be valid NMEA sentences.

Questions

Can kplex be 'easily' reconfigured to allow the baud rate of 460800?
or
Can the output of ttyUSB0 be redirected to kplex in another way?

Regards
Justin Arundell
Hurtle Turtle
MMSI: 503028550

[Keith Young]

Can kplex be 'easily' reconfigured to allow the baud rate of 460800?

No.  It can't be configured for more than 115200 using the current configuration file/command line.  Moreover unlike the last time when I added additional baud rates (early versions of kplex only supported 4800, 9600 and 38400 which are "normal" boat serial line speeds) this isn't simply a question of adding in some extra symbols from terms.h.  460800, which my reading of the past 24 hours suggests is actually quite widely supported, isn't a standard unix baud rate. I've (educationally, thanks!) dug up some stuff on using completely custom baud rates, but 460800 may not be too difficult:

http://stackoverflow.com/questions/19440268/how-to-set-a-non-standard-baudrate-on-a-serial-port-device-on-linux

I'm always a little uncomfortable with doing anything which isn't generic/cross-platform though.  Having said that shipmodul produce enough units that, i this is mandated, I should look at supporting.

The question I'd ask though is, although I understand why they're doing it (so they can deliver data even if the N2K bus is running near capacity), it's quite unusual that they should have a non-configurable usb interface (I assume it's usb, yes?) with a default speed which many nav programs will doubtless not support.  Can you check that it isn't configurable?  If not I'll ping them a mail...

Can the output of ttyUSB0 be redirected to kplex in another way?

many ways.  you could cat the output into kplex's standard input.  If the device is already set up at the right baud rate etc. I'm wondering whether just treating it as a file interface might work (adding "eol=rn" to the config: haven't tried that myself, worth a try): that could be your simplest answer. Or interpose socat.

But I think it worth first checking back with shipmodul because having such a non-standard rate which couldn't be changed would be an interesting choice.

[Keith Young]

Got a very helpful and quick reply from Meindert Sprang at Shipmodul.

The 460800 is to support all inputs without data loss, hardware flow control supported but data is buffered, so it's not mandated.

On Windows and OS X the miniplex 3USB uses a patched driver which sets the baud rate at 460800.  Consequently even of your windows / OS X app doesn't support 460800, the maniple's driver will ignore what the app is trying to set and use 460800.  Your OpenCPN on windows and OS X should work fine with it.

On Linux it's a different story: Using the standard ftdi_sio driver you'd have to explicitly set 460800.

So where does this leave us?

Unlike some unixen (like OS X) Linux doesn't revert the settings on serial ports when they're closed so it could be worth a try to set up the serial port using stty: I haven't confirmed stty on Linux supports 460800 yet but I assume from Minder's reply that the diver does.  So first thing to try might be to set up the serial port with stty then treat it like a normal file interface (as above). That won't work for bi-directional though.

Mean time I'll look at adding support for 460800.  This might actually take longer than it otherwise would as I'm half way through a minor re-write which has started to get a bit more major than I intended....

[Keith Young]

Actually it seems it might be more trivial than I thought. B460800 seems to be supported on some lines at least...

--- serial.c 2016-12-12 08:48:08.000000000 +0000

+++ /tmp/serial.c 2016-12-23 20:25:40.000000000 +0000

@@ -518,6 +518,14 @@

                 baud=B57600;

             else if (!strcmp(opt->val,"115200"))

                 baud=B115200;

+#ifdef B230400

+            else if (!strcmp(opt->val,"230400"))

+                baud=B230400;

+#endif

+#ifdef B460800

+            else if (!strcmp(opt->val,"460800"))

+                baud=B460800;

+#endif

             else {

                 logerr(0,"Unsupported baud rate \'%s\'",opt->val);

                 return(NULL);

[Keith Young]

There's now experimental support on platforms that support it for 230400 and 460800 baud in the develop branch on github. Not even compiled on linux yet so might not work at all...

[Justin Arundell]

With a little bit of work I was able to compile, install and run this experimental code with success.
I am now able to read the /dev/ttyUSB0 at 460800 and export to UDP on port 2000 for Navionics on the Android tablets and tcp port 10110 for opencpn simultaneously on linux and windows pcs.

I will test bi-directional at a later stage and possibly set-up a roving marinetraffic upload.