OpenCPN 5.2 Released

[monos1]

Sean and all dears, as we say in France : don't throw the baby with the bath water !
Please, wait till I'm down below to eradicate NMEA !
I don't like neither some aspects of the NMEA  ,  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.