Feature Requests

[nohal]

Originally Posted by Tehani

Nohal,
Well, OpenCPN will then have two options: Manage the ISO 11783-3 protocol completely with this device, or do what I say, include some small additions equivalent to the PGN's that I propose.

In my opinion, NMEA0183 over 4800/38400 baud is dead, but not over TCP / UDP.
On the other hand, I think that SignalK is operative on WAN networks, but at the moment it is not viable for microcontrollers to handle it in direct communication with transducers and pilot. It would be necessary to develop all that hardware and software from 0.
Or is there a pilot that is directly controlled by SignalK ?. (including buttons and navigation modes). I do not know...
I believe that things have to be done progressively, it is possible that transducers that "speak" directly in SignalK are appearing, but as far as I know, there are not any. That is, you do not get rid of a gateway anyway.
At physic level, I think that CAN BUS topology is, at the moment, the best choice for its connection simplicity. A Ethernet network requires switch devices (IP68) and a lot of long wires with also IP68 connectors. In other words, I dont't see a boat installation speaking in SignalK over Ethernet. may be throught radio, WiFi...
SignalK can´t work over CAN BUS because it does not have a simple message identification structure and low level implementable priority control. RS485 for SignalK as option?.
At the moment SignalK is used by instrumentation manufacturers, its "Open Source" concept may be jeopardized because that dependency would be created that we want to avoid. This topic is very delicate.

You always need a "gateway" to do any media conversion, it is irrelevant what two media types you are converting.
SignalK is a communication protocol, does not care about the transport layer. Could you elaborate a little about the modus operandi of the jeopardization of SignalK by a manufacturer a little? I can hardly imagine how an open communication protocol which does not care about the transport layer by design, whose main, and actually only, value is being open is a target for something like this, but maybe I missed your point.

[Tehani]

Hakan,
Then you agree with me. A small extension of the NMEA0183 would not affect any existing equipment because they will bypass those sentences even if they go out of the communication between the gateway and OpenCPN.

[Gypsylyon]

Originally Posted by Tehani

I would like to open a discussion on how to transfer the data of engines, gears and fluid levels from NMEA2000 to NMEA0183.
There are no sentences in NMEA0183 that contain that information, and I think it would be interesting for OpenCPN to be able to visualize it in its dashboard in future versions.
My proposal is to expand the sources in the XDR statement, although it may be more appropriate to establish one or two new proprietary sentences. For example IIENG, IILEV ..., with 2 or more instances each.
As example, Pitch (PTCH) and roll (ROLL) from the the Gyro are already implemented in XDR in the current version of OCPN.

Thanks

Thank you, Tehani.

I think it's a very good idea. I'm an OpenPlotter and OpenCPN user.
The electronics of my sailboat is Raymarine ST50, which works without problems.
To conver the Seatalk sentences I use the Ocenav converter that not only converts SeaTalk but also NMEA2000 and NMEA183. So what comes in through SeaTalk I also have in N2K and NMEA183 and the other way around

As long as this system works I don't plan to change it to N2K. On the other hand I am very happy with the combination Raspi, OpenPlotter and OpenCPN. OpenPlotter will open the possibility towards SignalK. In case one of the devices or sensors breaks down, I will replace it with another one that also has NMEA183 output.
The engine of my sailboat does not even have 500 hours. It is a simple diesel without NMEA2000 sensors. I've been thinking about adding sensors that can read them with the Raspi.
So I think Tehani's proposal would be a good solution. The OpenPlotter community has grown a lot and the OpenCPN user community is still much bigger.

[nohal]

Originally Posted by Gypsylyon

Thank you, Tehani.

I think it's a very good idea. I'm an OpenPlotter and OpenCPN user.
The electronics of my sailboat is Raymarine ST50, which works without problems.
To conver the Seatalk sentences I use the Ocenav converter that not only converts SeaTalk but also NMEA2000 and NMEA183. So what comes in through SeaTalk I also have in N2K and NMEA183 and the other way around

As long as this system works I don't plan to change it to N2K. On the other hand I am very happy with the combination Raspi, OpenPlotter and OpenCPN. OpenPlotter will open the possibility towards SignalK. In case one of the devices or sensors breaks down, I will replace it with another one that also has NMEA183 output.
The engine of my sailboat does not even have 500 hours. It is a simple diesel without NMEA2000 sensors. I've been thinking about adding sensors that can read them with the Raspi.
So I think Tehani's proposal would be a good solution. The OpenPlotter community has grown a lot and the OpenCPN user community is still much bigger.

This is a very good example of a system showing that we should not go the NMEA 0183 way as you have better options available immediately (Both N2K in canboat format and everything converted to SignalK)...

[Tehani]

Nohal,
It's possible that I'm wrong, but I think SignalK is essentially a data structure, it's not a protocol (please correct me if I'm wrong). Therefore it must be encapsulated on a transport and network layer.
For everyone to speak SignalK in the future, we would have to decide then, what kind of transport is the ideal to work in a wet place like a boat, and with the least complication in the wiring.
And that is the problem, a possible new manufacturer of transducers with output in SignalK, should decide a type of connection "in the real world" with what will condition their customers if their competing manufacturers do not accept that connection and protocol. And although all the manufacturers accept it, we will be with the eternal problem, because there will always be someone who "invents" a proprietary structure to do something that nobody does ...
Otherwise, this new standard can not be used extensively because the use of gateways will continue to be necessary.

And the story will be rewritten, since this has already happened with NMEA2000: The idea based on J1939 was fine, but in practice it has been a disaster of compatibility, physical and logical.

[Tehani]

And, for now, is it not easier to put a couple of new NMEA0183 sentences that do not hurt anyone?

[Gypsylyon]

Originally Posted by nohal

This is a very good example of a system showing that we should not go the NMEA 0183 way as you have better options available immediately (Both N2K in canboat format and everything converted to SignalK)...

I don't see it that way. OpenCPN only reads NMEA183. And I think in the new version 5 still doesn't read SignalK. This means that in the next 2 or 3 years is not going to change.
On the other hand sensors with NMEA183 output are cheaper than with N2K.
I have commented before, if I have to replace a sensor, I will buy the next one with NMEA183 output. I want compatibility with what I have installed. Imagine the investment I would have to make to modernize the electronics of my sailboat!
Signal K I find it fabulous, I'm not at all against it, it probably has a future. Signal K I have known it thanks to OpenPlotter. The battery voltage are read on the Raspi (with AD MCP3008 converter) and with OpenPlotter are translated to Signal K.
But the important sentences for the pilot come out of OpenCPN as NMEA183.
In the future these systems will disappear, but currently they still coexist with modern protocols. I have no idea how many people use NMEA183 systems. In my environment we are more than 90% that have NMEA183. I don't think it's very likely that all those people change their equipment to a more modern one as long as the one they have works for them. On the other hand many users still have no idea what signalK

[nohal]

Originally Posted by Gypsylyon

I don't see it that way. OpenCPN only reads NMEA183. And I think in the new version 5 still doesn't read SignalK. This means that in the next 2 or 3 years is not going to change.
On the other hand sensors with NMEA183 output are cheaper than with N2K.
I have commented before, if I have to replace a sensor, I will buy the next one with NMEA183 output. I want compatibility with what I have installed. Imagine the investment I would have to make to modernize the electronics of my sailboat!
Signal K I find it fabulous, I'm not at all against it, it probably has a future. Signal K I have known it thanks to OpenPlotter. The battery voltage are read on the Raspi (with AD MCP3008 converter) and with OpenPlotter are translated to Signal K.
But the important sentences for the pilot come out of OpenCPN as NMEA183.
In the future these systems will disappear, but currently they still coexist with modern protocols. I have no idea how many people use NMEA183 systems. In my environment we are more than 90% that have NMEA183. I don't think it's very likely that all those people change their equipment to a more modern one as long as the one they have works for them. On the other hand many users still have no idea what signalK

Why is there no SignalK in O5? Because we simply did not have enough resources to finish it. Should we really waste them to implement new extensions to NMEA 0183? I will certainly not do it with mine. Do it with yours if you think it is a good idea.

The people do not have to change any equipment, we are not going to drop support for NMEA 0183.

Do you have existing equipment producing NMEA0183 we do not support? Good, let's fix that.
But let the thing die it's very slow death and do not build your future on it by implementing extensions that anyway will never work well due to it's design llimitations.

[nohal]

Originally Posted by Tehani

And, for now, is it not easier to put a couple of new NMEA0183 sentences that do not hurt anyone?

In the long(er) run they will hurt the poor people that might do the mistake to implement them in their systems. But again, as long as you won't break the current stuff, send a pull request implementing more quadruplets in XDR. Inventing new sentences, not standardised by NMEA I personally consider a very bad idea, but if you must, at least follow the PXXX naming standard for vendor extensions.

You always need a "gateway" device to connect pretty much anything to a computer or mobile device.
Be it something as trivial as USB-serial adapter or something as sophisticated as an iKommunicate or whatever else.

We, as developers of OpenCPN, don't care about it at all though. We support as many communication protocols available as feasible, that's all. And we certainly do not want to get as low as Layer 1 or 2 (https://en.wikipedia.org/wiki/Network_layer), which is where CAN is, as there is absolutely no reason to do so, we don't even get to layer3 and 4 actually, besides using the open protocols available there.

[Ambler]

A moving map display around ones position placed anywhere on the screen rather than fixed to the centre (or back from the centre in look ahead mode) would be wonderful.

[Gypsylyon]

Originally Posted by nohal

Why is there no SignalK in O5? Because we simply did not have enough resources to finish it. Should we really waste them to implement new extensions to NMEA 0183? I will certainly not do it with mine. Do it with yours if you think it is a good idea.

The people do not have to change any equipment, we are not going to drop support for NMEA 0183.

Do you have existing equipment producing NMEA0183 we do not support? Good, let's fix that.
But let the thing die it's very slow death and do not build your future on it by implementing extensions that anyway will never work well due to it's design llimitations.

Thank you NOAHL for the explanation. And thank you very much also for your work dedicated to OpenCPN, is something fantastic
Concerning your last comment, for a small old sailboat that won't have many sensors, I don't think NMEA183 will work badly. I'll probably die before NMEA183. I'm not the youngest.

[nohal]

Originally Posted by Ambler

A moving map display around ones position placed anywhere on the screen rather than fixed to the centre (or back from the centre in look ahead mode) would be wonderful.

And is implemented in OpenCPN 5 beta.

[Ambler]

Originally Posted by nohal

And is implemented in OpenCPN 5 beta.

Fantastic! Thanks for the heads up Nohal. Will give it a try.

[Tehani]

Nohal,
Excuse me if I've bothered you, I'm sorry.
Thank you and good... (Good night in Spain)

José Luis

[Herreshoff]

Looking for some guidance/help for creating a plugin for Open CPN. I'm from Zulu Waterways which is a POI style service (zuluwaterways.com). Our API is nearly ready and I would like to give access to open CPN users. I would be interested in someone with the knowhow taking a look at creating the Zulu Plugin for Open CPN based off the API. Any interest would be great.
Nicholas Baillie Jackson