OpenCPN on RPi3 Latest Raspbian

[NahanniV]

I can not get it to work with HW OpenGL.
After running OpenCPN once the system hangs and the Pi will not boot again ?

Raspbian 2016-05-10

Anyone else tried this ?

Is it working for you ?

Thanks,
JM.

[verkerkbr]

Originally Posted by NahanniV

I can not get it to work with HW OpenGL.
After running OpenCPN once the system hangs and the Pi will not boot again ?

Raspbian 2016-05-10

Anyone else tried this ?

Is it working for you ?

Thanks,
JM.

Hi Jm,

I'am running the OpenPlotter version with Debian jessie. I suppose it is the same as the latest Raspian.

It does hardware acceleration. Processor is now running at around 30%.

I have upgraded the system with the latest update.

Updated the latest kernel to 4.4.10-V7+

It works perfect. But if I check the OpenGL to "on", then the system locks up. Most of the time I can cure the system by removing the ./opencpn folder and then renew the settings.

There seems to be no need to use the OpenGL setting. It is just the opposite.

The OpenPlotter additions are very usefull with an Wifi access point, VNC server, Kplex Multiplexer, SignalK server and now with Mqtt and settings for autostart and an SDR AIS dongle.

OpenCPN now running with wireless GPS and AIS data or via VNC on almost every computer system.

Bram

[NahanniV]

Originally Posted by verkerkbr

...
But if I check the OpenGL to "on", then the system locks up. Most of the time I cure the system by removing the ./opencpn map and renew the settings.

There seems to be no need to use the OpenGL setting. It is just the opposite.
...

Thanks Bram,

Do you mean check OpenGL to on in raspi-config ? or in OpenCPN ?

I need to have OpenGL support for the RADAR plugin to work.

Cheers,
JM.

[verkerkbr]

Originally Posted by NahanniV

Thanks Bram,

Do you mean check OpenGL to on in raspi-config ? or in OpenCPN ?

I need to have OpenGL support for the RADAR plugin to work.

Cheers,
JM.

In OpenCPN. If OpenGL checked to on then O does no longer start.

The latest Jessie version simple seems to work in combination with the graphics processor. Before the processor was running at around 80% and now 30% with fast movement of the screen.

In OpenPlotter there is the Radar plug allready added.

G radar 1.5. Scanner. Garmin Radar Plugin.
If I try to use the plug-in it gives: Scanner at 172.16.2.0 is not accessible for master control.

That seems to be right. Because I dont't have a radar !

Bram

[NahanniV]

Originally Posted by verkerkbr

In OpenCPN. If OpenGL checked to on then O does no longer start.

The latest Jessie version simple seems to work in combination with the graphics processor. Before the processor was running at around 80% and now 30% with fast movement of the screen.

In OpenPlotter there is the Radar plug allready added.

G radar 1.5. Scanner. Garmin Radar Plugin.
If I try to use the plug-in it gives: Scanner at 172.16.2.0 is not accessible for master control.

That seems to be right. Because I dont't have a radar !

Bram

Thanks Bram,

I need the BR24radar_pi and it must have openGL.

If I enable OpenGL in OpenCPN without enabling hardware OpenGL raspi-config CPU usage is 80-90% and everything slows to a crawl.

If I enable hardware OpenGL the system crashes.

Everything was working in an earlier version.

[verkerkbr]

Originally Posted by NahanniV

Thanks Bram,

I need the BR24radar_pi and it must have openGL.

If I enable OpenGL in OpenCPN without enabling hardware OpenGL raspi-config CPU usage is 80-90% and everything slows to a crawl.

If I enable hardware OpenGL the system crashes.

Everything was working in an earlier version.

Is it the latest kernel version ? Seems to be the previous software without the video acceleration.

Try the Debian Jessie version from OpenPlotter. Latest version 0.8 is now stable.

Is OpenGL probably allready build in ?

After installing I did:

rsi-upgrade

and apt-get dist-upgrade.

Now everything is the latest version.

The Raspy3 is now running perfect with the latest RC version of OpenCPN.

Wonderfull how the Raspy3 works with fast screen movements. And the processor around 30%.

Runs with wireless data on every system now. Windows, Linux, Android tablet and even an Android Smartphone.

And with the SignalK server.

And now also with MQTT. I don't know yet what can be done with the Mosquitto. But it must have a purpose. Instruments ?

Here in my office I receive the AIS data via the RTL-AIS dongle. This is the small system to have on board.

Regards,


Bram

[verkerkbr]

This is what I have running now:

pi@openplotter:~ $ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 8.0 (jessie)
Release: 8.0
Codename: jessie
pi@openplotter:~ $ uname -r
4.4.10-v7+
pi@openplotter:~ $

[seandepagnier]

could someone tell me where I can get a rpi3 $35 without excessive shipping charges?

[verkerkbr]

https://thepihut.com/pages/delivery

Price of the RPI 3 is Sterling 30,-. Royal Mail Sterling 4 - 8. 5-7 days.

Perhaps they can supply one without VAT.

[verkerkbr]

Originally Posted by verkerkbr

This is what I have running now:

pi@openplotter:~ $ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 8.0 (jessie)
Release: 8.0
Codename: jessie
pi@openplotter:~ $ uname -r
4.4.10-v7+
pi@openplotter:~ $

Now kernel:

4.4.11-v7+

[duichan]

My experience with OpenCPN on an RPi3 with hardware OpenGL enabled is that the screen refresh rate is indeed much faster (10 to 20 times), but the system locks up from time to time (particularly after zooming in or out). This is with all the latest software and kernel versions, using OpenSeaMap raster charts. I'm sure the problem is with the video driver, not OpenCPN itself. So my verdict is that OpenGL holds a lot of promise for the future, but (as the RPi developers themselves state) it is still in an experimental state at the moment.

Regards

Andrew

[verkerkbr]

OpenGL now seems to work. Reaction on the movements on the screen is much slower then without the OpenGL setting to on.

Without OpenGL it works with fast movement on thje screen and with low processor load.

This is what it shows on the log with OpenGL to on:

05:54 CET: OpenGL-> Renderer String: Gallium 0.4 on llvmpipe (LLVM 3.7, 128 bits)
03:05:54 CET: OpenGL-> Version reported: 3.0 Mesa 11.1.0
03:05:54 CET: OpenGL-> Texture rectangle format: de1
03:05:54 CET: OpenGL-> Using Vertexbuffer Objects
03:05:54 CET: OpenGL-> Using Framebuffer Objects
03:05:54 CET: OpenGL-> Using FBO Stencil buffer
03:05:54 CET: OpenGL-> Using Stencil buffer clipping
03:05:54 CET: OpenGL-> Using Scissor Clipping
03:05:54 CET: OpenGL-> gebruikt s3tc dxt1 compressie
03:05:54 CET: OpenGL-> Compressed tile size: 128kb (6:1)
03:05:54 CET: OpenGL-> Minimum cartographic line width: 1.0
03:05:54 CET: OpenGL-> Minimum symbol line width: 1.0

[NahanniV]

Originally Posted by duichan

My experience with OpenCPN on an RPi3 with hardware OpenGL enabled is that the screen refresh rate is indeed much faster (10 to 20 times), but the system locks up from time to time (particularly after zooming in or out). This is with all the latest software and kernel versions, using OpenSeaMap raster charts. I'm sure the problem is with the video driver, not OpenCPN itself. So my verdict is that OpenGL holds a lot of promise for the future, but (as the RPi developers themselves state) it is still in an experimental state at the moment.

Regards

Andrew

I agree, most likely a problem with the new driver, but how do we report it and get them to fix it ?

Just waiting for a new version might work, but maybe not if the problems are specific to OpenCPNs usage of OpenGL.

Cheers,
JM.

[duichan]

Originally Posted by NahanniV

I agree, most likely a problem with the new driver, but how do we report it and get them to fix it ?

Just waiting for a new version might work, but maybe not if the problems are specific to OpenCPNs usage of OpenGL.

Cheers,
JM.

Unfortunately, I don't yet have enough data to be specific enough about where the problems with OpenGL lie. I'd need to do a lot more testing before I could make a meaningful report.

[verkerkbr]

Originally Posted by NahanniV

I agree, most likely a problem with the new driver, but how do we report it and get them to fix it ?

Just waiting for a new version might work, but maybe not if the problems are specific to OpenCPNs usage of OpenGL.

Cheers,
JM.

I now tried the latest version of Ubuntu for Raspberry and OpenCPN.

Using ENC Charts.

OpenGL to on and texture cache also to on.

OpenCPN 4.2.1724 with OpenGL works without lock-ups.

In the OpenCPN Log I see a small difference in the versions:

LLVM 3.8
3.0 Mesa 11.2.0