OpenCPN 5.6.0 Released

[leamas]

Georgetina: In our testing so far we have not seen any measurable performance hit on platforms which are not constrained by memory. Could you give some details about your platform and the performance hit you see?


As for licenses: are you referring to the fact that chart license keys generated for a native platform cannot be used in the flatpak version? This is indeed the case, the charts installed for a native system cannot be used in the Flatpak version.

[bdbcat]

Georgetina:

OK, let's try this a different way.
We can install and run OpenCPN(armhf) on a generic arm64 system running a 64bit kernel, like Ubuntu 20.04.
This is an advanced procedure for users who want to run a generic debian-compatible arm64 linux system, and who cannot run flatpak, for whatever reason. It is not officially supported, but does work for most plugins. And it makes sense for your particular situation.

1. Backup your critical OpenCPN data, especially the contents of ~/.opencpn directory.
2. Uninstall any version of OpenCPN currently installed, like:
"$ sudo apt-get remove opencpn"
3. $ sudo dpkg --add-architecture armhf
4. $ sudo apt update
5. $ sudo apt install opencpn:armhf
6. Start OpenCPN once, and close immediately. This will force creation of an initial config file.
7. Edit the config file (~/.opencpn/opencpn.conf). Add the following:

  [PlugIns]
  CatalogExpert=1

Save and exit editor.
8. Start OpenCPN normally.
9. Update the master plugin catalog.
10. Navigate to:
Settings->plugins->Settings->Select new flavor
Choose the entry: "raspbian-armhf:11"
11. Update the master plugin catalog again.
12. Install and enable plugins of your choice.

Good luck
Dave

[verkerkbr]

Originally Posted by leamas

Georgetina: In our testing so far we have not seen any measurable performance hit on platforms which are not constrained by memory. Could you give some details about your platform and the performance hit you see?


As for licenses: are you referring to the fact that chart license keys generated for a native platform cannot be used in the flatpak version? This is indeed the case, the charts installed for a native system cannot be used in the Flatpak version.

I'am running flatpak versions on my Raspberry PI in the arm64 mode.

It works on the RaspiOS64 (based on Debian Bullseye version), Ubuntu Groovy and now on the Ubuntu Jammy Jellyfish. With the Oesenc Charts plugin with the usb dongle.

I don't see a raison why this setup does not work on the Odroid ARM version.

I have here an installable plugin for the Oesenc charts. Not the latest one, but it works. It is possible to add this plugin to a message here.

But installing the plug-in from within OpenCPN flatpak is a better solution. But not so easy to do, at present.

Bram

[bdbcat]

Bram...


"But not so easy to do, at present."


Why not? What problems?


Thanks
Dave

[georgetina]

Hi Dave thanks again for the try. I am getting some errors eg. http://deb.odroid.in /c4 focal Inrelease' doesn't support architecture "armhf"
so opencpn does not load

[BlackSea]

Originally Posted by bdbcat

We presently do not support plugins on arm64 systems natively.
Your best solution is to use flatpak for OpenCPN, for which most plugins are available now.


Good Luck
Dave

is very sad to hear this.

I can understand that the OpenCPN developers want to spend as little time as possible on native maintenance. But unfortunately Flatpak, Snap & Co are not the yellow of egg. It is the mature packagemanagment of Linux distributions leveraged.

this also applies exactly to the new plugin management.

[bdbcat]

BlackSea, et al...
Here is the thinking/logic behind our present position regarding arm64 native for OpenCPN.


1. The arm64 linux user landscape is now very fragmented. The rPi Foundation has made it clear that there is no great push toward native 64bit support for the rPi platform. The Foundation is, however, responding to popular requests. There is currently something in Beta test. There may be an "official" arm64 Release of RaspiOS sometime in the future. No idea when. Here is some useful discussion regarding the state of RaspiOS/64:
https://pimylifeup.com/raspberry-pi-64-bit/
I call attention to the known deficiencies of the current Beta code, especially the graphics drivers, which are critical to OpenCPN performance.



2. This situation has motivated users to seek alternative solutions. There seems to be no common solution, so we see many different linux distros being installed by users.


3. OpenCPN is built and maintained by a relatively small volunteer group of developers. We are committed to a large matrix of cross-platform support. Adding an unknown (but increasing) number of additional platforms for arm64 support of OCPN core and plugins is simply not sustainable with our current volunteer staffing level.



4. Technically, OpenCPN does not use any specific features of the arm64 architecture. OpenCPN will not run "faster" when compiled for 64 bits native In fact, it may run slower in some cases, mainly due to the video driver interface.


So, bottom line:
5. When (if?) the arm64 landscape for popular ARM-based SBCs stabilizes, we will re-address the question of native arm64 support for OpenCPN.


6. Meanwhile, our "officially supported" solution for arm64 systems is flatpak.


7. For this who claim that OpenCPN/flatpak is "slower" than an equivalent native implementation on arm64, we invite quantitative backup to that claim. And we will investigate as reported. I gently suggest that for users committed to arm64, OpenCPN on flatpak is faster than no OpenCPN at all.

8. And finally, OpenCPN, and the plugin library, is all OpenSource (GPL). Users may always build from source for their particular situation. We welcome alternative packaging projects, adding to the ecosystem.


Thanks for listening
Dave

[Sindbad2p0]

Originally Posted by bdbcat

Mark....
The ASSERT is probably happening in a plugin.
Please disable all plugins. Then re-enable one-by-one, until the error occurs. That way we can identify exactly which plugin is not playing nice.


Thanks
Dave

Hello Dave, team,


A few short sailing trips later I have some additional information about the issue which I reported earlier, regarding the following error message:
ASSERT INFO:
/usr/include/wx-3.0/wx/math.h(151): assert "x > INT_MIN - 0.5 && x < INT_MAX + 0.5" failed in wxRound(): argument out of supported range

BACKTRACE:
[1] PlugInManager::SendNMEASentenceToAllPlugIns(wxStri ng const&)
[2] Multiplexer::OnEvtStream(OCPN_DataStreamEvent&)
[3] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const
[4] wxEvtHandler::ProcessEventIfMatchesId(wxEventTable EntryBase const&, wxEvtHandler*, wxEvent&)
[5] wxEvtHandler::SearchDynamicEventTable(wxEvent&)
[6] wxEvtHandler::TryHereOnly(wxEvent&)
[7] wxEvtHandler::ProcessEventLocally(wxEvent&)
[8] wxEvtHandler::ProcessEvent(wxEvent&)
[9] wxEvtHandler::ProcessPendingEvents()
[10] wxAppConsoleBase::ProcessPendingEvents()
[11] wxApp:oIdle()


As Dave pointed out I found that this issue is caused by any tactics plugin (there are a few plugins which look very similar but al gave me the same issue).
Switching back to the plain old Dashboard seems to stop the problem. However, after a few hours in operation I suspect that also the default Dashboard plugin suffers from the same. Occassionally (think of once in half an hour or so) OCP just stops completely without any warning. I did not check any log files, but my theory is that some data which comes in via NMEA sentences causes the assert to raise. Other part of my theory is that the default Dashboard plugin is build without debug, and hence does not raise any assert but just quits right away. Just a theory, not sure if it makes sense.
Just to recall: I run the latest OCP 5.6 on latest 32bit Raspian, on a RPi 4 with 4G RAM.
I would be happy to assist in tracing the cause, however I experience a very steep learning curve. I am just able to succesfully compile the main tree of OCP 5.6, but trying to compile any plugin fails, probably due to dependencies issues and my lack of compiler knowledge.


Any help would be greatly appreciated,


Mark

[BlackSea]

Users may always build from source for their particular situation. We welcome alternative packaging projects, adding to the ecosystem.

this was possible until recently. unfortunately cmake rules have been modified (e.g. in oesenc and ocharts plugin) so that creation of debian packages is no longer possible and requires a lot of time investment to bring it back to the old state.

[bdbcat]

BlackSea....


True, the default CMake rules for e.g. oeSENC_PI no longer will build a debian package.
However, the rules will build a tarball package of the plugin, which may be imported to OpenCPN easily at run-time. Take a look at the oeSENC build script for linux. It is as simple as this:

$ mkdir  build
$ cd build
$ sudo mk-build-deps -ir ../build-deps/control
$ sudo apt-get -q --allow-unauthenticated install -f


$ cmake -DCMAKE_BUILD_TYPE=Release ..
$ cmake --build . --target tarball

Dave

[georgetina]

OK Dave an update. I have managed to get flatpak opencpn on my Odroid C4. Had to purchase a new map licence as the oesenc treated it as a new system. Anyway the system seems to run OK and as you said I cannot see any performance difference. I had to rebuild my system as all the attempts left me with lots of broken packages which I could not resolve. Needed to do it anyway as I had somehow used 5gb of software I have no idea as to what it is. So thank you for your efforts. I now understand (a little) the Flatpak requirement.
Regards George

[bcn]

Originally Posted by georgetina

OK Dave an update. I have managed to get flatpak opencpn on my Odroid C4. Had to purchase a new map licence as the oesenc treated it as a new system. ...


Regards George

First very pleased to hear that you managed to get it go on the Odroid C4.
With respect to the o-charts license, we really recommend the USB Key Dongle for systems that might require re-installs or are somehow experimental.
The chart licensors do limit the number of installs - two, system and back-up.


hubert

[Clem.Almarita]

I am having the same bug with CM93 and openGL activated on a Macbook Air m1.
When I slide the chart, all the area outside the window stays grey, and I have to unzoom, zoom to get it drawn.

Disabled openGL acceleration works, but is very slow, even on a Mac M1. So unusable... I will downgrade to 5.2 witch was working perfectly for me.


I tried on a fresh installation, no plugin, default options except CM93 charts path and enable chart quilting = on, otherwise it stays grey.

[bdbcat]

Clem...


Just to be clear, please confirm:
1. OpenGL ON
2. Quilting ON
3. cm93 ONLY.


What happens with normal ENC or RNC?


Thanks
Dave

[Clem.Almarita]

Yes, I confirm, Opengl ON, Quilting ON (otherwise nothing works, all grey), CM93 only. I don't have any ENC or RNC on that computer... I have downgrade back to 5.2.4 (not easy to find the file, by the way), and it works perfectly on this version.