Feature Requests

[nohal]

Originally Posted by 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

Nicholas...

I will gladly guide you and provide any help you or anybody else might need, but nothing changes on the fact that I will not write it myself for lack of time. Also of course you may use the code from https://bitbucket.org/nohal/ac_pi as whatever you consider relevant for your work.
You do have my contact info as we already were in contact.

Pavel

[Tehani]

Originally Posted by nohal

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.

I propose these extensions of the XDR statement so that OCPN can receive data from engines and fluid tanks to be able to visualize them in the dashboard.
I think it's a little invasive method ...
(I do not know how to send a "pull request", please, explain-me how to do it))

--------------------------------------------------------------------------------
NMEA0183 XDR format adaptation to translate N2K 127488 and 127489 pgn's
(More significative and frequent data extraction)

$YXXDR,T,x.x,R,ENGn,P,x.x,B,BSTn*hh<CR><LF> (1-2 times per second, 127488 PGN translation)
$YXXDR,C,x.x,C,OILn,R,x.x,l,FRTn*hh<CR><LF> (1 time every 2-3 seconds, 127489)

Set of 4 fiels per transducer, the 2nd field is the value (x.x)

Transducer name:
ENGn : Engine instance n
OILn : Oil temperature instance n
BSTn : Boost pressure instance n
FRTn : Fuel rate instance n

From NMEA0183 - Standard For Interfacing document rules:
Transducer Type:
T : Tachometer
C : Temperature
P : Pressure
R : Flow rate

Units Field:
R : RPM
C : Degrees Celsius
B : Bars
l : liters/second (Suggested: liters/hour to reduce significant digits)
-------------------------------------------------------------------------------

Fluid levels:
$YXXDR,V,x.x,M,TNKn*hh<CR><LF>

Transducer name:
TNKn : Tank instance n (To be assigned in dashboard: Identification)

Transducer Type:
V : Volume

Units Field:
M : cubic meters

-------------------------------------------------------------------------------
I think all gateway manufacturers will appreciate it and soon, we will add it to their products. The implementation is not difficult at all...

[nohal]

https://help.github.com/articles/cre...-pull-request/

[bcn]

There is a general question here: which data should be represented and processed by OpenCPN.
Being a Chart Plotter and Navigation system in my understanding just all the stuff that is needed for navigation and sailing.

A general "glass bridge" or "virtual instruments" approach would does not show up in my list of preferences. More, for me they don't belong into OpenCPN.

I don't care about the water tank or the temperature in the wine cooler for navigation. Or the light switches in the cabin. House bank voltage and temperature. Output of genny and solar. N2K does, as they want to cope with all data on the boat. SK is transport and transparent about the content.

Even engine data are very discussible here.

One might argue that OCPN has its built-in multiplexer and can be ignorant about the content pushed forward. Correct, but then don't expect that all data are getting represented at OpenCPN.

N2K is simple: take an Actisense--> NMEA gateway and you have the data in OpenCPN. More precise approach: create a plug-in for Actisense or its clones processing the N2K dat stream using the CanBoat library.

SK would require either an external gateway (in form of OpenPlotter/RasPi or something equivalent) or a SK client/server implemented as plug-in for OpenCPN.
The actual SK implementations based on Node JS are not acceptable as part of OpenCPN as they would add an important burden in form of packages and versions that are changing all the time. OpenPlotter reports a hard time to follow.
SK is still under some development. Implies permanent dedication to keep up with it.

Coming back to the beginning: the internal data model of OCPN restricts itself to the navigation data, based on those found in NMEA 0183. To implement a flexible abstract data model implies a big task. And has to be pondered in relation to what we would gain.
For example several instances of GPS can be handled already with the priorities of Communications. Using different incoming ports for the different instances.
Not very elegant, but working out of today's box. An OCPN N2K plug-in might deal with this option for example.
Keep it simple, please...

[Dockhead]

How about voice recognition for the Log plugin?


We were discussing it here:



Voice Recognition for Log? - Cruisers & Sailing Forums

[stevead]

N2K is simple: take an Actisense--> NMEA gateway and you have the data in OpenCPN. More precise approach: create a plug-in for Actisense or its clones processing the N2K dat stream using the CanBoat library.

Shameless plug: or the TwoCan plugin.
But as has been stated, irresepective of whether the data is delivered to OpenCPN via NMEA 0183, NMEA2000 or SignalK, if there are no instruments on the dashboard plugin for displaying engine data or tank capacity (or anything else for that matter), the question is moot, is it not ?

[Tehani]

Originally Posted by bcn

There is a general question here: which data should be represented and processed by OpenCPN.
Being a Chart Plotter and Navigation system in my understanding just all the stuff that is needed for navigation and sailing.

A general "glass bridge" or "virtual instruments" approach would does not show up in my list of preferences. More, for me they don't belong into OpenCPN.

I don't care about the water tank or the temperature in the wine cooler for navigation. Or the light switches in the cabin. House bank voltage and temperature. Output of genny and solar. N2K does, as they want to cope with all data on the boat. SK is transport and transparent about the content.

Even engine data are very discussible here.

Of course I understand what you say. I am aware of OCPN has always been oriented to navigation, especially sailing.
Do not think that I am a truck driver or a motorist (I do not know how they call these specimens here ...). On the contrary, I am passionate about sailing, and I do not like the waves that these people produce.

You see, my analysis corresponds to the observation of the current plotters of all manufacturers. They have mainly incorporated the engine data and the autopilot management in their instrument panel. And I think it might be a good idea to offer something at that level, because many OCPN supporters are targeting the replacement of those commercial plotters.

NOTE: Please, do not give an example to the Actisense gateway, it has very limited features in connectivity and translation capacity...

[bcn]

Tehani...

"sailing" here in the generic sense - "navegando", soy "tractorista".

Actisense is the fast lane to get the relevant N2K data into OpenCPN.
A N2K plug-in based on CanBoat would be more capable for sure.
And a physical device to connect to CAN/J1939 we can't avoid in neither case.

Stevead...

yet another plug-in for virtual instruments would be my proposal. Or even better a stand-alone program listening to data multiplexed from OpenCPN for example.

Hubert

[Hakan]

Originally Posted by bcn

....
yet another plug-in for virtual instruments would be my proposal. Or even better a stand-alone program listening to data multiplexed from OpenCPN for example.

[transmitterdan]

Yes, a dedicated plug-in for engine data and other non-navigation related data sources (battery voltage, liquid levels, oil pressure, coolant temp, etc.) is the best idea.

[nohal]

Originally Posted by transmitterdan

Yes, a dedicated plug-in for engine data and other non-navigation related data sources (battery voltage, liquid levels, oil pressure, coolant temp, etc.) is the best idea.

Which IMHO changes nothing on the fact that building it on NMEA0183, worse a non standard extension of it, is not a good idea

[stevead]

OK, So this is where i can solicit some feedback to help prioritise features for the little used (if any) TwoCan plugin:


1. Linux support via SocketCAN (currently setting up my Linux build environment)

2. Finalise support for AIS an DSC PGN's (Difficult as I've little if any sample data to test against)
3. Refactor code to use the Canboat/Openskipper NMEA 2000 PGN xml or json definition files rather than hardcoding the NMEA 2000 PGN definitions in various plug-in functions.

4. Support write operations on the NMEA 2000 network. Means becoming an active device (ISO Address claim, ISO commands, NMEA product Information etc. of which I already have a .NET implementation) and then opens the pandora's box of what NMEA 183 to NMEA 2000 conversions to support.

ls a tad difficult because if the plug-in requests WANTS_NMEA_SENTENCES, OpenCPN returns all sentences, even those that the plug-in itself set.
5. Dashboard with engine and tank instrumentation derived from the NMEA 2000 PGN's

[rgleason]

I tend to agree with bcn about some of these nmea0183 extensions using the XDR, particularly when they are data from sensors that are not associated with OpenCPN's mission.

For example, I would support an XDR message for mast rotation angle since it could be used by Tactics_pi.

I believe the reason we need to be hard nosed about this is that we do not want to overtax the broadcast messaging system that OpenCPN uses.


Added after seeing stevead about TwoCan:

Of course I am no expert about this, but I am interested in keeping OpenCPN useful for its main tasks which are actually quite broad without adding all kinds of additional sensors. Perhaps there is a good way to do this without affecting the operation?

[Gypsylyon]

I'm very sorry that the developers of OpenCPN think it's not a good idea to implement more information.
In the new version of OpenCPN, where you can save different configurations would have been fantastic, to have a Plugin where you can view the engine data including fuel consumption.
I still think it would be an excellent improvement for OpenCPN.

[conachair]

Originally Posted by bcn

There is a general question here: which data should be represented and processed by OpenCPN.
Being a Chart Plotter and Navigation system in my understanding just all the stuff that is needed for navigation and sailing.

A general "glass bridge" or "virtual instruments" approach would does not show up in my list of preferences. More, for me they don't belong into OpenCPN.

I don't care about the water tank or the temperature in the wine cooler for navigation. Or the light switches in the cabin. House bank voltage and temperature. Output of genny and solar. N2K does, as they want to cope with all data on the boat. SK is transport and transparent about the content.

Even engine data are very discussible here.

With you to an extent, though as a tablet user in the cockpit some data is useful to have in the dashboard, on Openplotter I tweak signalk engine temperature into a water temperature NMEA message so it can be seen all the time. Battery voltage would be nice as well. All could be taken care of if someone from the clever club gets round to writing a dashboard which can read signalk...
SigK users must be still quite a small group though..