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
#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


Messages In This Thread
OpenCPN 5.2 Released - by tkurki - 2020-07-16, 08:21 AM
RE: OpenCPN 5.2 Released - by abarrow - 2020-07-16, 01:10 PM
RE: OpenCPN 5.2 Released - by Didier B - 2020-07-16, 04:49 PM
RE: OpenCPN 5.2 Released - by abarrow - 2020-07-16, 04:58 PM
RE: OpenCPN 5.2 Released - by Sailoog - 2020-07-16, 05:48 PM
RE: OpenCPN 5.2 Released - by monos1 - 2020-07-16, 10:27 PM
RE: OpenCPN 5.2 Released - by seandepagnier - 2020-07-17, 06:47 PM
RE: OpenCPN 5.2 Released - by Didier B - 2020-07-17, 07:16 PM
RE: OpenCPN 5.2 Released - by monos1 - 2020-07-17, 09:52 PM
RE: OpenCPN 5.2 Released - by Sailoog - 2020-08-08, 07:22 PM
RE: OpenCPN 5.2 Released - by fishy - 2020-08-19, 07:51 AM
RE: OpenCPN 5.2 Released - by abarrow - 2020-08-19, 01:12 PM
RE: OpenCPN 5.2 Released - by rastam4n - 2020-08-19, 01:33 PM
RE: OpenCPN 5.2 Released - by fishy - 2020-08-26, 09:34 AM
RE: OpenCPN 5.2 Released - by Sailoog - 2020-09-14, 06:28 PM

Forum Jump:


Users browsing this thread: 1 Guest(s)