Rpi crashes on OpenCPN 4.8.4 charts

[verkerkbr]

Originally Posted by CapnRon47

I have tried the OpenPlotter approach and it has worked for me in the past. But I prefer to set up the wifi on the RPi to act simultaneously as an AP and a client. The AP lets me connect to SignalK output for instruments and the client allows me to still connect to the internet. So I prefer to load my own OpenCPN and SignalK Server.

But I am having problems with the latest version of Raspbian 'stretch' in that there are dependencies I need and don't have (and don't know). I am using the synaptic package manager to load Opencpn. I can add the necessary repository, but it tells me it does not have the public key. And as I try to add the key (not sure it was the right one) it says I do not have 'dirmngr', so each time I end up finding out I am missing something.

I may just try to go back to the previous version of Raspbian (Jessie)

Upgrade to Stretch:

If you have a good running version of Raspian Jessy, you can simply do an update to Stretch with the following action:


To upgrade, first modify the files /etc/apt/sources.list and /etc/apt/sources.list.d/raspi.list. In both files, change every occurrence of the word ‘jessie’ to ‘stretch’. (Both files will require sudo to edit.)
Then open a terminal window and execute
sudo apt-get update sudo apt-get -y dist-upgradeAnswer ‘yes’ to any prompts. There may also be a point at which the install pauses while a page of information is shown on the screen – hold the ‘space’ key to scroll through all of this and then hit ‘q’ to continue.
Finally, if you are not using PulseAudio for anything other than Bluetooth audio, remove it from the image by entering
sudo apt-get -y purge "pulseaudio*"

It is quite a large update.
BTW my answers were no (mostly) default.

And in de end remove the no longer used files with:

sudo apt-get autoremove

All, including OpenCPN, are still working.

You can also upgrade to the latest kernel with:

sudo rpi-update (latest kernel is 4.14.39)

Bram

[seandepagnier]

Originally Posted by bdbcat

Ron...
We are finding that on rPI "stretch" with raster charts, non-GL mode is a lot more stable and cool running.

Dave

I find it strange, but actually disabling the opengl driver in raspi-config but enabling opengl in opencpn works best for me. I am tired of the hardware gl driver crashing the whole system.

The software opengl seems faster than software dc graphics. Try it! I think because on raspberry, there is very little 2d acceleration available, so dc mode is very slow.

It uses quite a bit of cpu as the software opengl makes use of the quad core raspberry, so for power consumption it's probably not great.

Ocassionally the software opengl does crash opencpn, but at least I can just restart the program, not the whole system.

[CapnRon47]

Thanks,
I finally got the charts downloaded and I will take your approach. turn on software (fake) OpenGL in Raspi-config and use the OpenGL in OpenCPN.

So far that seems to work well.

thanks,
Ron

[verkerkbr]

Originally Posted by boat_alexandra

I find it strange, but actually disabling the opengl driver in raspi-config but enabling opengl in opencpn works best for me. I am tired of the hardware gl driver crashing the whole system.

The software opengl seems faster than software dc graphics. Try it! I think because on raspberry, there is very little 2d acceleration available, so dc mode is very slow.

It uses quite a bit of cpu as the software opengl makes use of the quad core raspberry, so for power consumption it's probably not great.

Ocassionally the software opengl does crash opencpn, but at least I can just restart the program, not the whole system.

Here OpenCPN is running well and very fast with the OpenGL plugin activated and OpenGL on. Also with a low main processor load.

But use the latest updates en latest kernel 4.14.39-V7. (rpi-update)

Glxgears is running here at 850-900 FBS (Frames per second)

Regards,

Bram

[Andreas29]

Hi,

@CapnRon47: You wrote that you use a hdmi Monitor. What resolution you use? When I used the highest resolution I got crashes. When using a one step lower res. all is fine.

@verkerkbr: Bram, I tried different update methods but all ended with the Point that I got cpu usage up to 99% in idle mode. I think this is because I use a wifi dongle for building up a local wifi and for that I have made some configurations witch will not work with the update.
So I stay with jessie in the moment but with the latest kernel. Works good enough for me.

Regards

Andreas

[verkerkbr]

Originally Posted by Andreas29

Hi,

@CapnRon47: You wrote that you use a hdmi Monitor. What resolution you use? When I used the highest resolution I got crashes. When using a one step lower res. all is fine.

@verkerkbr: Bram, I tried different update methods but all ended with the Point that I got cpu usage up to 99% in idle mode. I think this is because I use a wifi dongle for building up a local wifi and for that I have made some configurations witch will not work with the update.
So I stay with jessie in the moment but with the latest kernel. Works good enough for me.

Regards

Andreas

Hi Andreas,

just did a test with my Stretch system on a Raspberry Pi3B+.

Extra usb wifi dongle added, the one from Pihut.

AP op Wlan0 and Wifi on Wlan 1. Wifi setting in network connections.

Works perfect with Wifi connection and AP OpenPlotter connected to another via VNC.

Processor load normal.

This how it works here, without any hickups.

Regards,

Bram

[CapnRon47]

I am running on a RPI 3 (about a year old). I am running just the default graphics setting for the HDMI monitor. I first loaded Stretch (using Etcher), then manually added OpenCPN (I was having issues with the public key on the Synaptic Package Manager, but I eventually figured that out). Then I added Signalk-Server and finally I set up the internal wifi adapter to run as both an AP and a Client. See here:
https://github.com/Mateus-Romera/rpi...ion-ap-stretch

I run htop in a terminal window in the background and moving the charts OPenCPN has one processor running at around 60%. Everything seems to be running smooth at this point.
thanks for your replies.
Ron

[NahanniV]

Originally Posted by bdbcat

....
the GL implementation does not provide any useful mechanism for texture compression, so high memory pressure is a fact of life when running OpenCPN on rPI in hardware GL mode with raster charts.

We are finding that on rPI "stretch" with raster charts, non-GL mode is a lot more stable and cool running.

Dave

Do you think it would it be possible for the developer (Eric Anholt) to add a "useful mechanism for texture compression" ? Perhaps if enough OpenCPN users asked....

Is there any way that OpenCPN users could help report problems with the OpenGL driver in a simple way ?

[bdbcat]

Nahanni....

I think an informative email to Eric from the rPI OCPN user base could be useful. But I'm not sure of a good mechanism to get results, or the release timing involved.

I'm definitely supportive of the idea...

Good Luck
Dave