This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.
OpenMarine › OpenPlotter › General discussion v
OpenCPN instability (Again ...)

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Threaded Mode
OpenCPN instability (Again ...)
Didier B Offline
Senior Member
****
Posts: 340
Threads: 72
Joined: Mar 2016
Reputation: 12
#1
2023-02-02, 04:45 PM
After a few days it happenned again ! CpU load exceed 25% (1 core fully occupied) and OpenCPN out of control.
I could visuatyze that thanks to a smartphone application Rapcontroler, very usefull indeed ! When things have calmed down, I de-activated in OpenCPN the connection to SignalK, and, as by a miracle, the troubles were gone : no more hangup, easy panning and zooming, and activating the options didn't freeze OpenCPN neither !
I know disconnecting from SignalK is not a respectable solution, but it give a good clue where to investigate more in deep , isn't it ?
Cordialement
Didier B
Pi4, SSD USB3, OP 3.0 Touch SK 3.2.1 OpenCPN  5.8.4 :  Thank you  Thank you  Thank you


Find
Reply
Opie91 Offline
Member
***
Posts: 172
Threads: 15
Joined: Jun 2017
Reputation: 6
#2
2023-02-02, 05:23 PM
Had the same problem and ended up going back to using the OP NMEA0183 port for data. It is easy to hook up and has all the information I am looking for.

SignalK and OpenCPN seem to have a love/hate relationship on the Raspberry Pi. Until it is worked out, this is a respectable solution as far as I am concerned.

I read a few days back somewhere (sorry, I couldn't find it) that the developers were aware of the issue and resolved it. Suspect the fix will be implemented in the next update.
Find
Reply
Sailoog Offline
Administrator
*******
Posts: 2,831
Threads: 60
Joined: Mar 2016
Reputation: 265
#3
2023-02-02, 07:11 PM
It seems that there is a problem with OpenCPN trying to digest the "null" values in signal K. OpenCPN developers made a fix but I have been tracking this fix and it seems than it never got published in OpenCPN 5.6.2 in debian backport but it was applied to OpenCPN 5.6.2 in flatpak.

could you try the flatpak installation and report please?
Find
Reply
Opie91 Offline
Member
***
Posts: 172
Threads: 15
Joined: Jun 2017
Reputation: 6
#4
2023-02-03, 06:17 PM
(2023-02-02, 07:11 PM)Sailoog Wrote: It seems that there is a problem with OpenCPN trying to digest the "null" values in signal K. OpenCPN developers made a fix but I have been tracking this fix and it seems than it never got published in OpenCPN 5.6.2 in debian backport but it was applied to OpenCPN 5.6.2 in flatpak.

could you try the flatpak installation and report please?

Hi Sailoog,

Flatpak has the same issue. Constantly freezes up after a few minutes. Once data is switched over to NMEA0183, there are no issues.

I have not yet been able to see the advantage in OP of having SignalK over NMEA0183.
Find
Reply
Sailoog Offline
Administrator
*******
Posts: 2,831
Threads: 60
Joined: Mar 2016
Reputation: 265
#5
2023-02-03, 06:26 PM (This post was last modified: 2023-02-03, 06:27 PM by Sailoog.)
For me OpenCPN backport is freezing with Signal k null values but OpenCPN flatpak is not.

The advantage is that you may not have data input in NMEA 0183 format. If you have input data in signal K, seatalk1 or NMEA 2000 formats you do not have to translate to NMEA 0183
Find
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)