OpenCPN on Raspberry Pi2

[affinite]

Originally Posted by conachair

I could never get that git to work with opencpn - with opengl enabled in O there was just a white screen. Am I doing something wrong?

+1

[conachair]

Originally Posted by affinite

+1

Getting low 40's FPS with some home made raster charts though

[NahanniV]

Originally Posted by conachair

Getting low 40's FPS with some home made raster charts though

So, what were the parameters for 4-6 FPS ?

Screen size ?
Chart type ?
Compression cache built ?
Zoom level ?

Cheers,
JM.

[conachair]

Originally Posted by NahanniV

So, what were the parameters for 4-6 FPS ?

Screen size ?
Chart type ?
Compression cache built ?
Zoom level ?

Cheers,
JM.

Not sure of the screen resolution, CM93 V2 charts - compression cache? Dunno, that option is grayed out in the menu.

FPS seems to vary quite a bit, zoomed in, 3x with a few ais targets & own ship then 6-10FPS, zoomed out a bit with soundings off on a fairly empty area then more like 20FPS.
But most definitely very usable.

[seandepagnier]

So it is usable at 4-6fps. According to the logs posted, the new driver supports dxt1 compression so it should be possible to use the compressed cache. I have no way to download a pi image at the moment and play around but it sounds promising.

I can only say maybe my work to make the bcmhost driver working is wasted but it's no big deal. In any case, I was getting 25-30fps for zooming and panning at 1280x800. This is much more fluid than 4-6fps For vector charts cm93, is panning 15fps but zooming much slower.

There are also reports that the pi consumes lots of power using this new driver when it's working so much that they had to increase their voltage.

How much power does it use exactly when you are really panning or zooming? What about compared to without opengl? I can measure how much power my pi is using to compare it.

The new driver must do a lot of work on the cpu that was before offloaded to the video core. The driver makes use of the 3d cores, but not the video core which is wasted, and therefore this opensource driver will always be inferior in speed, resources and power consumption to the closed driver unless the video core can be used unfortunately.

As far as I know, only myself and dave have successfully run opencpn using the closed driver with success. There is an issue also for now with stability which will get solved automatically by other future changes.

[conachair]

Originally Posted by boat_alexandra

There are also reports that the pi consumes lots of power using this new driver when it's working so much that they had to increase their voltage.

How much power does it use exactly when you are really panning or zooming? What about compared to without opengl?

i just put a dc clamp meter on my Pi2 running OpenPlotter
- opengl enabled on the Pi & opencpn
approx 350mA - 400mA
Opengl driver turned off
Approx 325mA - 350mA

So not much in it, maybe the hardware is more sensitive to voltage drop running the hardware driver.

That's with a HMDI-VGA converter which takes some power as well so straight into a HDMI monitor would probably be a bit less.

Reminded me just what a massive difference there is running with the driver.

[verkerkbr]

Originally Posted by conachair

i just put a dc clamp meter on my Pi2 running OpenPlotter
- opengl enabled on the Pi & opencpn
approx 350mA - 400mA
Opengl driver turned off
Approx 325mA - 350mA

So not much in it, maybe the hardware is more sensitive to voltage drop running the hardware driver.

That's with a HMDI-VGA converter which takes some power as well so straight into a HDMI monitor would probably be a bit less.

Reminded me just what a massive difference there is running with the driver.

I think it is the voltage. If I enlarge the GPU memory I have the problem back.

Now it is standing on 192. That works.

Any idea what is the ideal setting of the GPU Memory ?

Wifi dongle and GPS mouse connected. RTSDR plug as an Ais receiver test on a hub.

Regards,


Bram

[NahanniV]

Originally Posted by verkerkbr

I think it is the voltage. If I enlarge the GPU memory I have the problem back.

Now it is standing on 192. That works.

Any idea what is the ideal setting of the GPU Memory ?

Wifi dongle and GPS mouse connected. RTSDR plug as an Ais receiver test on a hub.

Regards,


Bram

How are you supplying power to your Pi ?
It seems like you may be running near the maximum of what your power supply can handle, or perhaps you have a bad connection or cable (too long, too small).

Cheers,
JM.

[verkerkbr]

Because I'am not at the boat. I use at home an usb powersupply rating 2.4A.

I just bought an original Raspberry power supply. But I have not yet received this item.

I'am now also using a short usb cable.

But if I raises the GPU memory then I get the splash screen again. It seems very critical with voltage.

Using the OpenGL experimental driver. And this works.

It also works with my RTLSDR Dongle AIS reception on my Raspberry Pi 2

And ?....... I have now TV and radio with the same dongle on board with the small antenne and my Linux notebook.

Costs € 7,- including free freight from China. Takes about 3 weeks.

I have bought 2 sets. One for Ais en one for entertaiment.

[CarCode]

For people which likes electronics tinkering:
The FCC has certified a Raspberry Pi 3 with WLAN and Bluetooth on board:
https://fccid.io/2ABCB-RPI32

Gerhard

[verkerkbr]

Originally Posted by NahanniV

How are you supplying power to your Pi ?
It seems like you may be running near the maximum of what your power supply can handle, or perhaps you have a bad connection or cable (too long, too small).

Cheers,
JM.

Good morning JM,

The original Power supply for the Raspberry Pi 2 received. And now the Raspberry Pi 2 works without a Problem. Looks like the wire of this power supply has more thickness.

On board have installed a voltage regulator for 12/5 volt.

The OpenPlotter addition works excellent. It has all the functions you need.

It runs also a VNC Desktop. Ethernet or wireless NMEA and Ais reception with a simple Dongle and with GPS from a GPS mouse. And all of data is multiplexed available.

Bram

[Hakan]

Hi,
For Info:
Rpi: 2. OCPN 4.2 git fetch from yesterday
With the updated Jessie and: "apt-get install xcompmgr libgl1-mesa-dri" hardware OpenGl is working and the perfomance is much much better. For example is the CPU use now more efficient. Now it's using up to 80% compared to earlier 25-30%
From the log:

09:00:19 CET: Using PNG Icons
09:00:19 CET: Detected display size (horizontal): 212 mm
09:00:19 CET: System default Language:  en_US
09:00:19 CET: Opencpn language set to:  en_US
09:00:19 CET: Creating MyFrame...size(800, 460)  position(0, 49)
09:00:19 CET: Creating glChartCanvas
09:00:19 CET: Detected display size (horizontal): 212 mm
09:00:19 CET: Detected display size (horizontal): 212 mm
09:00:20 CET: OpenGL-> Renderer String: Gallium 0.4 on llvmpipe (LLVM 3.7, 128 bits)
09:00:20 CET: OpenGL-> Version reported:  3.0 Mesa 11.1.0
09:00:20 CET: OpenGL-> Texture rectangle format: de1
09:00:20 CET: OpenGL-> Using Vertexbuffer Objects
09:00:20 CET: OpenGL-> Using Framebuffer Objects
09:00:20 CET: OpenGL-> Using FBO Stencil buffer
09:00:20 CET: OpenGL-> Using Stencil buffer clipping
09:00:20 CET: OpenGL-> Using Scissor Clipping
09:00:20 CET: OpenGL-> Using s3tc dxt1 compression
09:00:20 CET: OpenGL-> Compressed tile size: 128kb (6:1)
09:00:20 CET: OpenGL-> Minimum cartographic line width:  1.0
09:00:20 CET: OpenGL-> Minimum symbol line width:  1.0
09:00:20 CET: ChartDB Cache policy:  Application target is 40 MBytes

But.......and this is not dependent of the mesa update:
The log is flooded with:

7:16:52 CET: Detected display size (horizontal): 212 mm
07:16:58 CET: Detected display size (horizontal): 212 mm
07:16:58 CET: Detected display size (horizontal): 212 mm
07:16:59 CET: Detected display size (horizontal): 212 mm
07:16:59 CET: Detected display size (horizontal): 212 mm
07:17:00 CET: Detected display size (horizontal): 212 mm
07:17:01 CET: Detected display size (horizontal): 212 mm
07:17:03 CET: Detected display size (horizontal): 212 mm
.... + another hundreds of the same

Anything I can do?
The screen is R_Pi 7" and it is around 154 mm. I've set it to manually 154 mm but that's not reflected in the log???

Håkan

[verkerkbr]

Good morning Hakan,

perhaps you must change the resolution in Linux. It can be done in:

/boot/config.txt

It looks if it can be done with the present settings, but it is better to search for the correct settings for your display.

Every resolution and dimension of the screen has a number.

I had the same problem with a touchscreen and now it working fine without the ovals I got first.

Bram

[NahanniV]

Originally Posted by Hakan

Hi,
For Info:
Rpi: 2. OCPN 4.2 git fetch from yesterday
With the updated Jessie and: "apt-get install xcompmgr libgl1-mesa-dri" hardware OpenGl is working and the perfomance is much much better. For example is the CPU use now more efficient. Now it's using up to 80% compared to earlier 25-30%
From the log:

09:00:19 CET: Using PNG Icons
09:00:19 CET: Detected display size (horizontal): 212 mm
09:00:19 CET: System default Language:  en_US
09:00:19 CET: Opencpn language set to:  en_US
09:00:19 CET: Creating MyFrame...size(800, 460)  position(0, 49)
09:00:19 CET: Creating glChartCanvas
09:00:19 CET: Detected display size (horizontal): 212 mm
09:00:19 CET: Detected display size (horizontal): 212 mm
09:00:20 CET: OpenGL-> Renderer String: Gallium 0.4 on llvmpipe (LLVM 3.7, 128 bits)
09:00:20 CET: OpenGL-> Version reported:  3.0 Mesa 11.1.0
09:00:20 CET: OpenGL-> Texture rectangle format: de1
09:00:20 CET: OpenGL-> Using Vertexbuffer Objects
09:00:20 CET: OpenGL-> Using Framebuffer Objects
09:00:20 CET: OpenGL-> Using FBO Stencil buffer
09:00:20 CET: OpenGL-> Using Stencil buffer clipping
09:00:20 CET: OpenGL-> Using Scissor Clipping
09:00:20 CET: OpenGL-> Using s3tc dxt1 compression
09:00:20 CET: OpenGL-> Compressed tile size: 128kb (6:1)
09:00:20 CET: OpenGL-> Minimum cartographic line width:  1.0
09:00:20 CET: OpenGL-> Minimum symbol line width:  1.0
09:00:20 CET: ChartDB Cache policy:  Application target is 40 MBytes

80% CPU usage is not good, I didn't realize this new driver relied so heavily on the CPU rather than the GPU.

I will be interested to hear how it works with your RADAR.

Perhaps Seans "Rpi fixes" pull request might be worthwhile implementing ?

Cheers,
JM.

[verkerkbr]

Here running at 75 %. OpenCPN 4.2 with the OpenPlotter add-ons like:

A GPS USB mouse
AIS reception with a DVB-T dongle
Wifi Access Point
Kplex multiplexer
SignalK server
VNC server

All this items running well and wireless NMEA and AIS on all other systems. VNC works also very well via other systems.

Waiting now for my Raspberry Pi 3.

Bram