OpenCPN on Raspberry PI2

[rgleason]

@lve0200 I've made you a manager so you can edit the page.

[lve0200]

Hi,
I'm running the Pi headless; that's because I probably have no issues w/ v-sync on TV screens. 60 fps looks pretty much NTSC to me!
Be shure that you are on a newer Jessie kernel, at leat the Dec. 2016 version.
I am not so sure about having to switch ON OpenGL in the OpenCPN config menu... I observed some instability on high detailed & quilted charts, when zooming. I switched OFF OpenGL in OpenCPN, but left it ON in the Pi. The amazing result was, that the zoom and pan display speed was equally fast as before, but the instability was gone. The thing runs now since several days beton stable and I can do whatever I want w/out being able to crash it!
Check your power supply! measure directly at the Pi, not at the supply side. The Pi seems to create enormous current bursts, rather than a continuous current flow. My Amp meter shows an average flow of only 0.5A, but I know that the spikes will go up to 2-3 Amps! Zooming and heavy display activities cause these bursts, hence if your Pi crashs during such actions, it's most likely due to insufficient power or too thin cables.
Rgds
hk

[seandepagnier]

It should be able to run with less power consumption using opengl. Maybe the drivers are still unstable? How do you make it crash? Can you repeat it? Does opencpn crash or the kernel or what? Did it recover?

[LeaseOnLife]

Originally Posted by boat_alexandra

It should be able to run with less power consumption using opengl. Maybe the drivers are still unstable? How do you make it crash? Can you repeat it? Does opencpn crash or the kernel or what? Did it recover?

I did a few tests. Common for these tests is: I am using the latest Great Lakes chart 14500_1.kap, chart outlines are disabled, almost no waypoints or tracks. Latest kernel 4.9.8, latest from OpenCPN

• Not using any dtoverly: vblank_mode=0 glxgears" runs at ~130-150 fps. OpenCPN crashes when zooming out beyond a scale of ~0.5 lock the RPI hard. power cycle needed
• dtoverlay=vc4-kms-v3d: "vblank_mode=0 glxgears" runs at ~690 fps
• When not using opengl in OpenCPN, I can zoom out as far as I want.
• Turning OpenGL on causes a crash when zooming out beyond a Scale of ~1.0. The crash can be a wx crash causing opencpn to crash, or the whole RPI3 locks up and needs to be power cycled
• dtoverlay=vc4-fkms-v3d: "vblank_mode=0 glxgears" runs at ~770 fps,
• OpenCPN tests opengl on/off are identical to above

Remarks: Make sure the "fbturbo" driver is disabled, otherwise X uses the very limited ftbturbo despite an enabled real HW accelerated driver.


See http://www.cruisersforum.com/forums/...ml#post2315542
and http://www.cruisersforum.com/forums/...ml#post2314281


Dirk

[seandepagnier]

you probably chose the worst possible chart to test.

This is a known (to me) bug that in single chart mode, opencpn still tries to use the native chart projection (which is actually incorrect anyway in this case) rather than simply using mercator. This is a bug in opencpn at the moment... I didn't implement the projection support this way but it got changed back.

In quilting mode it should be ok.

Could you instead please test with a different chart, preferably in mercator projection and give power consumption with and without opengl?

[LeaseOnLife]

Originally Posted by boat_alexandra

you probably chose the worst possible chart to test.

I know, pet peeve = home waters

Originally Posted by boat_alexandra

Could you instead please test with a different chart, preferably in mercator projection and give power consumption with and without opengl?

OK!

This time I am zooming in and out around the Gulf of Mexico using the latest RNC charts. Common for these tests is: Quilting and chart outlines are enabled, almost no waypoints or tracks. Latest kernel 4.9.8, latest from OpenCPN. Current is measured at 13.1V (I am using a DC/DC converter to feed the 5V to the PI), while running glxgears and zooming in and out in OpenCPN

• Not using any dtoverly: vblank_mode=0 glxgears" runs at ~130-150 fps. OpenCPN does not crash zooming in or out. 0.4 - 0.45A (<6W)
• dtoverlay=vc4-kms-v3d: "vblank_mode=0 glxgears" runs at ~690 fps. OpenCPN does not crash zooming in or out. 0.38 0.42A (<6W)
• Turning OpenGL on: no change in power consumption, does not crash in this area zooming in/out
• dtoverlay=vc4-fkms-v3d: as with kms, no difference observed

Can you please help with the crashes using charts with projections like the Great Lakes Charts? I am willing to test...


Dirk

[lve0200]

Originally Posted by LeaseOnLife

Latest kernel 4.9.8,

Dirk

Hi Dirk,
Where did you get this Kernel version? I udated, dist-upgrade my Pi and I am still on: Linux 4.4.38-v7+ #938 SMP Thu Dec 15

Could you post the result of $uname -a from your Pi?

Some ideas about power consumption. When using the GPU for OpenGL calulations, the power consumption should go up, since the GPU AND 1 core are busy, while SW rendering is most likely not done in a new thread, which means that the same core is used and power consumption should stay within the max intake of 1 core. This could by coincidence end up in the same range, although the burst could be different.

Concerning your power supply using the DC/DC converter, probably that thing from the OpenPlotter web site ?? right?? This device is very good, has thick cables on the 5V side and using it @12V which is usually dimensioned for big currents, you should see no problems. Moreover, my own measurements show me, that the regulation of this thing is fast, hence it can perfectly deal with the current bursts of the Pi. I guess you measure the input at the 12V side, which gives you already an averaged out current, as compared to the 5V side. 6W is then around 5V/1A in average. Why am I so picky about bursts? Because in a normal computer, big capacitors are added and power supplies are fast regulators to deal with big power bursts. Mind you, the Intel 4 Core CPUs are rated up to 130W at 1,1V, means 120Amps or so, while in idle mode, actual power consumption is 30W or less. We should understand, that despite the small size of the Pi, the Quad-Core CPU in there is a high performance beast of burdon!! Due to the size of the Pi, they had no chances putting big capacitors onto the board, and they unloaded the burst problem to an external power supply, which is then by many users replaced by a simple Mobile wall plug, underestimating the untold power requirements of the Pi
Rgds
hk

[conachair]

Originally Posted by lve0200

Hi Dirk,
Where did you get this Kernel version? I udated, dist-upgrade my Pi and I am still on: Linux 4.4.38-v7+ #938 SMP Thu Dec 15

Could you post the result of $uname -a from your Pi?

Some ideas about power consumption. When using the GPU for OpenGL calulations, the power consumption should go up, since the GPU AND 1 core are busy, while SW rendering is most likely not done in a new thread, which means that the same core is used and power consumption should stay within the max intake of 1 core.

Concerning your power supply using the DC/DC converter, probably that thing from the OpenPlotter web site ?? right?? This device is very good, has thick cables on the 5V side and using it @12V which is usually dimensioned for big currents, you should see no problems. Moreover, my own measurements show me, that the regulation of this thing is fast, hence it can perfectly deal with the current bursts of the Pi. I guess you measure the input at the 12V side, which gives you already an averaged out current, as compared to the 5V side. 6W is then around 5V/1A in average.
Rgds
hk

The command to upgrade the kernal is - sudo BRANCH=next rpi-update

pi@openplotter:~ $ sudo BRANCH=next rpi-update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** Performing self-update
 *** Relaunching after update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** Your firmware is already up to date
pi@openplotter:~ $ uname -a
Linux openplotter 4.9.8-v7+ #960 SMP Sun Feb 5 15:03:59 GMT 2017 armv7l GNU/Linux

With the power, the Pi 3 seems to like running a bit high, I run mine from a buck converter at about 5.2v, very occasionally see the lighting bolt icon top right of the screen indicating low voltage. Volts/amps datalogger is on the cards so will be interesting to see just what's really going on.

[lve0200]

Ah, OK, I see,
1 more word concerning Power. You said a key thing! Most people overlook the Spec for the Pi, saying it should be supplied w/ 5.1V, you run 5.2! That's essential, because the Pi has at the entry a self healing fuse and a diode to protect it against power connections in the wrong sense (+/-). The price to pay for is that the self healing fuse has a significant internal resistance; that means that right at the power entry to the Pi there is a loss of 100-200 mV, variable with the current intake. Just running it at a Mobile charger, which are not so stable and go under heavy load even below 5V, the Pi is starving for Power.
Rgds
hk

[lve0200]

the lighting bolt icon top right of the screen indicating low voltage. Volts/amps datalogger is on the cards

what is this? OpenPlotter enhancement??

[conachair]

Originally Posted by lve0200

the lighting bolt icon top right of the screen indicating low voltage. Volts/amps datalogger is on the cards

what is this? OpenPlotter enhancement??

It's new in the raspbian Pixel desktop

https://www.raspberrypi.org/blog/introducing-pixel/

Finally on the subject of icons, in the past if your Pi was working particularly hard, you might have noticed some yellow and red squares appearing in the top-right corner of the screen, which were indications of overtemperature or undervoltage. These have now been replaced with some new symbols that make it a bit more obvious what’s actually happening; there’s a lightning bolt for undervoltage, and a thermometer for overtemperature.

[lve0200]

Form those, who want to amuse themselves a little bit more, look at this:

Raspberry Pi, Pi 2 and Pi 3 Benchmarks - Roy Longbottom's PC benchmark Collection

There you'll find all instruments of torture and since it is very simple SW, you can exclude SW bugs. If it fails, its just about performance!

hk

[LeaseOnLife]

Originally Posted by lve0200

Hi Dirk,
Where did you get this Kernel version? I udated, dist-upgrade my Pi and I am still on: Linux 4.4.38-v7+ #938 SMP Thu Dec 15

Could you post the result of $uname -a from your Pi?

Conachair answered this already, but here is mine:

pi@Can-A-Berry:~ $ uname -r
4.9.8-v7+
pi@Can-A-Berry:~ $

Concerning your power supply using the DC/DC converter, probably that thing from the OpenPlotter web site ?? right??

I bought this one, same 5V 3A output as the one available via OpenPlotter. I liked the micro USB connector better.

https://www.amazon.com/gp/product/B0...?ie=UTF8&psc=1

I have not had power problems with this device. Disclaimer: I have not yet tested it on the boat to know how much disturbance this DC/DC converter causes on the SSB or VHF.

Dirk

[LeaseOnLife]

Originally Posted by lve0200

Form those, who want to amuse themselves a little bit more, look at this:

Raspberry Pi, Pi 2 and Pi 3 Benchmarks - Roy Longbottom's PC benchmark Collection

There you'll find all instruments of torture and since it is very simple SW, you can exclude SW bugs. If it fails, its just about performance!

hk

Yummy!, 64bit promises quite a bit of improvements.

[lve0200]

Yep, I have the same, works absolutely fine @home and in my car.
Unfortunately, the torture instrument don't execute on my Pi. Need to compile them.