Raspberry Pi and OpenCPN 3.1.915

[NahanniV]

It seems unfortunate that OpenCPN runs slowly on this platform (even with overclocking).

What makes it so slow ?
Is there some way to optimize the code ?

I'd really like to see it working well on one of these low power platforms.

[bdbcat]

NahanniV...

OpenCPN performance is all about the graphics subsystem. Pushing around millions of 24 bit wide screen pixels is going to take some time unless a dedicated GPU is available, as with OpenGL.

Best suggestion for better performance: use a lower screen resolution.

Dave

[NahanniV]

Originally Posted by spillemw

OpenCPN is now a little slow, but workable.

Originally Posted by bdbcat

OpenCPN performance is all about the graphics subsystem. Pushing around millions of 24 bit wide screen pixels is going to take some time unless a dedicated GPU is available, as with OpenGL.

Best suggestion for better performance: use a lower screen resolution.

So what resolution are you using spillemw ?

[spillemw]

Originally Posted by NahanniV

So what resolution are you using spillemw ?

Indeed the Pi is very low on memory that is then shared as well.
I am using 1280x800.
I could go to less, but I don't really want to.
I think we will need to wait for a Model C that has 1 GB or RAM or dedicated video memory. My guess is that should not take too long given the prices of memory.
On my wishlist is to run vncserver on the pi and run OpenCPN on that (meaning i could use whichever tablet or smartphone in the boat to run OpenCPN). That will require a little more memory still.
CPU wise with the overclocking i think it is ok.

[Alisdair]

I had OpenCPN running satisfactorily over the weekend on my my pi using the latest Debian image

I intend putting up a web page that describes the process, but that will be a few weeks away due to other commitments, however, in a nutshell:

- I had to tweak some of the OpenCPN code and recompile it (see http://www.cruisersforum.com/forums/...ml#post1012681 )

- opencpn.conf MEMCacheLimit=30 NCacheLimit=10

- doesn't work with NOAA ENC charts

- overclocking set to medium (no/minimum overvoltage) was perfectly adequate

- changed the vector chart settings to Mariners standard because of some hiccups zooming out in standard mode (water showing green)

- no problems with chart quilting; I was using vector charts and Antares raster charts

- 'make package' creates a .deb, but it won't install and complains about the wrong architecture. I suspect it's because there's a line in the makefile that renames arm to armel, but this version of debian is armhf... I'm using 'make install', so it's not a high priority for me.

- I initially had a lot of trouble getting a GPS to talk to the Pi:
1.) the USB/Serial converter I was using was old and not supported; a newer cheap Chinese one from eBay sorted that out. (/dev/ttyUSB0 in OpenCPN)
2.) I also tried a GPIO serial/TTL converter. That worked as well (/dev/ttyAMA0 in OpenCPN)
3) I wasted a lot of time trying to get a Garmin eTrex to talk to the Pi.... until I discovered the eTrex only outputs NMEA at 4800baud but the Pi supports >= 9600.
4) I am using an old Garmin GPS48 with NMEA at 9600 baud and it's perfect via the serial/USB converter.
5) In future I'll probably use the GPIO connecter which frees up a USB port for a wifi dongle; the Pi doesn't seem to like multiple devices on USB hubs


I only encountered one problem with the system .. I don't recommend using a wireless mouse ... slide, bump, splash ... 'nuff said.

[Alisdair]

Originally Posted by spillemw

- i need to buy an 8 GB one if the Pi supports that).

I'm using a 16GB class 10 with no problems