OpenCPN on Raspberry PI2

[Schooner Chandlery]

Spart, This may be helpful to you. David and I have had problems in the past with the on-boat network and the Pi. He recalls:

We had problems making the Airmar data available to multiple users on the network. Early attempts just time-multiplexed the data when there were multiple listeners--sending one NMEA line to the first listener, the second NMEA line to the next listener and so forth. The only solution we found that supported multiple listeners and provided all data to all listeners was a commercial product called "remserial." The licence allows for "free" use depending on how it is used. Our usage qualifies for free, so we use remserial (LPC Computer Consulting - Linux).

Actually, we first take in the data using a bash script which tees the data into an archive stream stored on disk and sends the data to remserial using nc (netcat). Our applications use the remserial network port to access data. For some reason, with many listeners and using wifi on the Pi B+ we sometimes have the data stream crash (2 weeks to 3 months between crashes), but the problem may not be with remserial.

We wrote a cron watchdog to check the archive file for new writes and if too much time passes, the script automatically kills everything and restarts remserial and the bash script. Normal startup on our Raspberry Pi B+ running Rasbian is via a udev script and requires "at" scheduler so that the process isn't killed prematurely (before it can be made a daemon).

We are currently setting up a Raspberry Pi 2 running Debian Jessie. We do expect that the startup sequence may need to be changed due to new more strict udev script constraints.

Also, our QT application which displays the Airmar WX data needs to be recompiled for the new ARM architecture.

We hope our experience with our Pi B+ is helpful to you.
Best regards, Brenda and David

[Schooner Chandlery]

PS -- is there a generic Raspberry Pi thread around here somewhere? I'd love to be chatting Pi on a Pi thread rather than OpenCPN thread. Should I start a thread and link to these posts if there is not already a thread? Perhaps a moderator/admin can chime in/move or help! Thanks

[sparticle]

This thread is about opencpn on the Rpi2 so works for me. Don't know why we need another.

I type a long post but clearly it took me too long and then when I went post it had timed out and I had to start again. Can;t be bothered at this time.

TCALSS - long and frustrating testing day with the Rpi2

We have an seemingly intermittent issue with the serial to usb converter connection. We use it to get WMV from the wind instrument and as the standard output port to the repeater and AP.

Very simple wiring. Works perfectly with OpenCPN and PolarNav on the linux laptop.

Was working on the Rpi2 all morning then I started seeing these errors in the log and lost wind data and all output data to the repeater and AP. Literally hundreds of these messages:

Jul 4 18:13:14 pi kernel: [ 2027.067907] pl2303 ttyUSB1: usb_serial_generic_write_bulk_callback - urb stopped: -32

I think it means the USB device has crashed!

I though at first it was a faulty adaptor so plugged in the spare and cold booted everything inc. instruments. Same issue.

It seems to work intermittently. Have to disable and enable the port in OpenCPN but random on the amount of time it works for.

Without basic nmea in out this is a non starter for us. This is before we worry about any network connectivity!

Cheers
Spart

[Schooner Chandlery]

We sometimes have usb lockups that require a reboot (every 6mos). First thought is if the usb serial device is switching name midstream (e.g. ttyUSB0 becomes ttyUSB1) due to some glitch? If name is not changing, will have to ponder further on cause. The usb system on the rpi B B+ was very glitchy for a long time until drivers were improved. Could be we are in for a period of glitchy usb on the rpi 2.

This issue is not OpenCPN related, it is rpi - centered.

[sparticle]

Hi thanks for your note. No switching of ports.

And no issue with the AIS/GPS port, solid and reliable so far.

Cheers
Spart

[Schooner Chandlery]

So you're using the same USB device driver for both ttyUSB0 and ttyUSB1? e.g. the hardware devices are the same type?

[sparticle]

So you're using the same USB device driver for both ttyUSB0 and ttyUSB1? e.g. the hardware devices are the same type?

No, as I said previously.

The AIS/GPS feed is native USB so just plugs in and is configured as /dev/ttyUSB0 the unit is a Digital Yacht AIS PRO. (Which we can recommend to anyone as a serious bit of kit it only cost us 120GBP and it takes the NMEA out from the GPS and muxes it into the AIS data stream. So we get a single high speed connection with AIS and GPS data been rock solid since purchase 2 years ago).

The Serial to USB adaptor is connected on pin 2 to the wind Instrument which send us WMV and on pin 3 to the Repeater, On Board Garmin GPS 295 (for upload of and course data) and the AP and receives and sends out standard 4800 NMEA. This is seen and configured as:

Kernel: [ 2027.067907] pl2303 ttyUSB1:

If we substitute the Ubuntu Laptop all works fine.

Cheers
Spart

[CarCode]

Spart,
it doesn't matter which operating system, for each USB device a driver is needed to get a virtual com port. This driver depends only of the serial/USB chip used in the device. This seems to be a FTDI chip in your Digital Yacht device and a Prolific chip in your other USB adapter. So you need a FTDI driver and a Prolific driver. And if you have several devices with the same chip you will have only one driver for different ports.
Gerhard

[NahanniV]

Spart,

Get a Usb<->Serial converter with the FTDI chipset, they are not too expensive, the ones with the Prolific chipset are known to be problematic (Google it).

Cheers,
JM.

[sparticle]

Originally Posted by NahanniV

Spart,

Get a Usb<->Serial converter with the FTDI chipset, they are not too expensive, the ones with the Prolific chipset are known to be problematic (Google it).

Cheers,
JM.

Any specific products that are known to work?

Just wondering is we could hard wire into the Rpi2 GPIO pins. Anyone got any advice? All the listeners are powered independantly. So in theory I could set the /dev/ttyAMA0 port to 4800 and connect to Ground (06) RX (10) & TX (12) pins. Disable the boot messages on /dev/ttyAMA0 in cmdline.txt and in theory I should be able to use the native UART to do the simple 2 wire nmea......

Cheers
Spart

[CarCode]

Best product and of course most expensive is the Keyspan USA-19HS. Also available for 4 serials.

Gerhard

[Schooner Chandlery]

Originally Posted by nohal

Tell him to use the current master code of OpenCPN, it is using wx3.0 by default - exactly for this reason.

Just did the download and installing now. dri2 dev doesn't exist for the rpi. how to get around?

We have libxcb-dri2-0-dev and xproto-dir2-dev but we're getting error on compile stating it can't find -ldri2 ....

So, next trick the compiler using make arguments... using either one of the above -dev

but today's a sunny day and the boat's bottom is crying out to be cleaned... no more playing with the rpi2

PS this is using debian jessie not raspbian on the rpi2.

[Schooner Chandlery]

Originally Posted by NahanniV

Spart,

Get a Usb<->Serial converter with the FTDI chipset, they are not too expensive, the ones with the Prolific chipset are known to be problematic (Google it).

Cheers,
JM.

That's what I was getting at with asking about drivers.

[nohal]

SC...
You can probably replace "-ldri2" with "-lxcb-dri2" to make it link, but this is exactly the spot that needs the work of someone who actually knows how the acceleration stuff works on these ARM machines, it is not just about making it link somehow against some random library that happens to fit there, which is what this "fix" does...

Pavel

[mattkab]

Originally Posted by Schooner Chandlery

We sometimes have usb lockups that require a reboot (every 6mos). First thought is if the usb serial device is switching name midstream (e.g. ttyUSB0 becomes ttyUSB1) due to some glitch? If name is not changing, will have to ponder further on cause. The usb system on the rpi B B+ was very glitchy for a long time until drivers were improved. Could be we are in for a period of glitchy usb on the rpi 2.

This issue is not OpenCPN related, it is rpi - centered.

This is a RPI issue, you are absolutely correct.

I have had lots of struggles with USB and the Rpi, especially boards prior to the 2.

To test, get a POWERED USB hub, and run everything, as is, though that. I would put money down that this will fix the issue.

If it does, you have a few options:

1. Run the powered USB hub
2. Get a legit PSU for the Pi
3. Reduce power consumption through configuration, hardware, or programming
4. Live with the occasional reconfigure task (what I do)