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.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
OpenCPN 5.2 Released
#1
https://opencpn.org/OpenCPN/about/ver520.html

- new pluginmanager
- Signal K support

Once the dust has settled OP should consider changing the default setup from 0183 to Signal K, potentionally less hassle with conversions to 0183.


Sent from my iPhone using Tapatalk
Reply
#2
Just a minor annoyance: When it installs, or at least on my system, the OpenCPN shortcut in the OpenPlotter folder disappears, and the new OpenCPN is installed in the Education folder. That also breaks the shortcut on the panel bar.

It's easy to fix, but just a little annoying.
Reply
#3
Tried it, looks very good, here are my 1st impressions and remarks :
To Andy : I didn't notice any change in menu nor panel bar ...
  • I found it far too dark, until I understood OpenCPN started in night vision mode... Rolleyes
  • I tried but didn't succeeded to use the new 'Signal K' protocol available in the Option/connection panel Huh ,
    so I fold back to 'TCP'  protocol Smile ...
    (I guess the introduction of  signalK in OpenCPN will impact Openplotter, ... or not ! We will see Rolleyes )
  • Clearer display of depth sounding is a pure blessing for my eyes !  Cool
Altogether, it seems quite positive, I guess the most important is the adhesion to Signal K ! Big Grin Big Grin Big Grin
Cordialement
Didier B
Pi4, OP 2.3.0-stable




Reply
#4
Not sure what happened with me. It was probably because I installed the update using "apt install opencpn" instead of using the OpenCPN installer in OpenPlotter. Anyway, it's all fixed now. A little disappointed that there aren't more plugins - I'm a little unclear about how they get installed with the new plugin model.
Reply
#5
We have been worked with OpenCPN team to make easy the transition from debian package plugins to OpenCPN managed plugins and the coexistence with both of them, this will be applied to the next openplotter-opencpn-installer app update. Most plugins are not maintained by OpenCPN team so it will take some time until all plugins are migrated by developers.

About SK integration obviously is a great improvement but people have already problems understanding how the NMEA 0183 connection works and now we are adding a new SK connection that in some cases should coexists with the NMEA 0183 connection. This will involve lots of support requests, duplicated data and even data loops. We must write a clear entry in docs to make this easier and add extra checking actions.
Reply
#6
(2020-07-16, 05:48 PM)Sailoog Wrote: About SK integration obviously is a great improvement but people have already problems understanding how the NMEA 0183 connection works and now we are adding a new SK connection that in some cases should coexists with the NMEA 0183 connection. This will involve lots of support requests, duplicated data and even data loops. We must write a clear entry in docs to make this easier and add extra checking actions.

I don't think it's such a problem if we just use SK data. OpenCpn only reads data in SK format. For now it neither translates nor forwards them. So the possibility of problems related to loops and things like that is not so important.  
For example, even if we send RMB data to the pilot in NMEA 0183 format using OpenCpn and it goes into SK and is forwarded to OpenCpn again, nothing will happen because that loop will die there since it will not be translated to NMEA 0183 and forwarded to SK and the pilot again.


Even better.The SK entry we created in OpenCpn can be configured to look for a SK server on every startup regardless of what IP address has been assigned.  


I'm using for months just the SK connection and it's great. No problems with plugins to convert data to NMEA0183 or data loss. All alone and exclusively through SK and more simple than anything.For me the SK entry seems easier for dummies and I would put it by default eliminating the NMEA 0183.

After all, SK accepts all kind of input data, both NMEA 0183 and N2K as SK, either physical or network data or raw sensor data, and we don't need any kind of plugin or conversion so that all of them are read and displayed automatically by opencpn when we use a SK input. 

Of course, the output in NMEA0183 format through port 10110 will continue there for the rest of the outdated applications that only read outdated data like the classic Android applications. But I only feed OpenCpn with the new fresher and more powerful SK data.

Edited to add:

I just noticed that several of the Android applications I use to display navigation data have added Signal K support lately. The movement towards Signal K seems pretty clear. Only old dinosaurs like Navionics are reluctant to the new protocol but even for Navionics we already have the UDP data output plug-in.
Reply
#7
opencpn needs to output signalk if we are to eliminate nmea0183.

So for now opencpn can read signalk but still outputs nmea0183.
Reply
#8
Sean and all dears, as we say in France : don't throw the baby with the bath water ! Smile
Please, wait till I'm down below to eradicate NMEA ! Blush
Above all keep the read possibility, as it is the only language of my vintage electronics !
Also keep the possibility to send NMEA to my old pilot !

I have never been convinced by S/T, N2k and other "marketing departments" inventions designed to create stinking closed captive markets. Angry

I don't like neither some aspects of the NMEA  Dodgy ,  but don't kill my on-board electronics !
Cordialement
Didier B
Pi4, OP 2.3.0-stable




Reply
#9
(2020-07-17, 07:16 PM)Didier B Wrote: Sean and all dears, as we say in France : don't throw the baby with the bath water ! Smile
Please, wait till I'm down below to eradicate NMEA ! Blush
I don't like neither some aspects of the NMEA  Dodgy ,  but don't kill my on-board electronics !

Didier, there is no question whatsoever of killing NMEA0183 immediately or de facto replacing it with SK. In fact, that's totally impossible at the moment.

While most of our input devices are made by traditional manufacturers there is no choice but to use their proprietary NMEA0183 and N2K protocols with permission from seatalk translated into NMEA0183.

It is from now on that we start to deal with raw sensors - like magnetic compasses, accelerometers, temperature sensors and so on - that we start to be able to do without the old proprietary systems. Sean has already made available to us a pilot free of those systems and in time we are sure that wind systems and perhaps even depth sounders will appear totally free of proprietary protocols. By then we will be able to do without the old protocols, but for now it is not possible yet.

So what's the point?
The point is to try to make the complex simple. Make the difficult easier... if it can be done. And I think connecting Opencpn exclusively to the SK protocol is a good idea... now that we can do it.

The SK server has all the necessary capabilities to read all kind of data, both free and old proprietary ones. That's why I think it's a good idea to give him that role exclusively. Define well how the connections are made and make it the neuralgic center of navigation data collection whatever the protocol is.

Then SK pours all the data for the use of the other applications. In SK format mainly and in NMEA0183 -localhost:10110- only to support the obsolete tools.

Those data dumped by SK and in SK format can be shown in any web browser using the server applications and if opencpn also reads and understands them -as it is the case from now on- we will not need the use of plugins to go on converting and resending data. All this complicated the management of data and made it more difficult for dummies to understand how openplotter works.

Now we can manage connections with SK or kplex or opencpn which messes things up a bit. Which is better? Ahem... what if I use the canboat?? and what about the heel sensors or barometers?

Directing everything towards SK gives a firm structure to the project and a clear direction. All connections are defined in SK both those of NMEA0183 using SERIAL-USB converters and N2K as well as all types of sensors. Everything goes to SK and from the SK server are poured ready to use to the rest of applications or devices. A unique thread.

And meanwhile SK will still be able to read and send all NMEA data from our old devices. There is nothing to worry about. 

I guess Sean hopes that Opencpn will be able to send SK data to his pilot too, so he won't need conversions to NMEA0183 which I guess would improve his pilot's response and efficiency. But in the meantime SK can forward that data from opencpn to the old proprietary pilots as before.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)